ads.txt & sellers.json: Publisher Authorization Explained

Domain spoofing and unauthorized selling have plagued programmatic advertising since its inception. In response, the IAB Tech Lab introduced two complementary standards—ads.txt and sellers.json—that together create a transparent chain of authorization from publisher to buyer. Understanding these protocols is essential for any participant in the digital advertising supply chain.

What Is ads.txt?

Authorized Digital Sellers (ads.txt) is a simple, machine-readable text file that publishers host at the root of their domain. It declares which advertising systems are authorized to sell the publisher's inventory. The concept is analogous to robots.txt but for advertising authorization rather than crawler instructions.

When a publisher places an ads.txt file at https://example.com/ads.txt, they publicly declare which SSPs, exchanges, and ad networks have the right to sell their ad impressions. Any buyer-side system can crawl this file and verify that a bid request claiming to represent example.com actually comes from an authorized seller.

The ads.txt File Format

Each line in an ads.txt file represents one authorized seller record. The format follows a comma-separated structure with up to four fields:

# Example ads.txt file
google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0
rubiconproject.com, 12345, RESELLER, 0bfd66d529a55807
openx.com, 54321, RESELLER, a698e2ec-2f8a-4b88-b42f-2d09e35a576b
indexexchange.com, 67890, RESELLER, 50b235b64b5e4c1a

DIRECT vs. RESELLER Relationships

Understanding the distinction between these two relationship types is critical for both buyers and publishers.

• DIRECT indicates the publisher has a direct contractual relationship with the advertising system. The publisher itself operates the account on that platform.
• RESELLER indicates that the publisher has authorized a third party to sell inventory on their behalf. This includes SSPs, ad networks, and other intermediaries that have been granted reselling rights.

Buyers typically prefer to purchase through DIRECT relationships because they reduce the number of intermediaries in the supply chain, which lowers costs and increases transparency. This preference is the foundation of Supply Path Optimization (SPO) strategies.

How Buyers Verify ads.txt

DSPs and other buyer-side platforms implement ads.txt verification as a core part of their bid evaluation pipeline. The verification process follows these steps:

1. Crawl: The DSP periodically crawls the ads.txt file at the publisher's domain root. IAB recommends refreshing crawls at least every 24 hours, though many DSPs crawl more frequently for high-value domains.
2. Parse: The system parses each record, extracting the domain, account ID, relationship type, and certification authority ID.
3. Match: When a bid request arrives, the DSP checks whether the seller identified in the request appears in the crawled ads.txt file for the claimed publisher domain.
4. Decision: If the seller is not listed in ads.txt, the DSP can reject the bid request, protecting the advertiser from potentially fraudulent inventory.

Crawling Edge Cases

Several edge cases require careful handling during ads.txt crawls:

• Redirects: The spec allows up to five HTTP redirects, but crawlers must respect the final resolved URL's domain for record attribution.
• Subdomains: Crawlers should first check the exact subdomain. If no ads.txt exists there, they fall back to the apex domain. For example, news.example.com/ads.txt is checked first, then example.com/ads.txt.
• HTTP errors: A 404 response means no ads.txt exists, which the buyer may interpret as "no authorized sellers." Many DSPs treat domains without ads.txt as higher risk.
• Encoding: Files should be UTF-8 encoded. Crawlers should handle BOM markers and ignore blank lines and comment lines (starting with #).

sellers.json: Transparency in the Supply Chain

While ads.txt tells buyers who is authorized to sell a publisher's inventory, sellers.json provides information about the identity of the entities represented in bid requests. SSPs and exchanges host sellers.json files at their domain root to declare the identity of each publisher whose inventory they sell.

sellers.json Structure

{
  "schema_version": "1.0",
  "contact_email": "support@exchange.com",
  "contact_address": "123 Ad Street, New York, NY 10001",
  "version": "1.0",
  "last_updated": "2026-10-15",
  "sellers": [
    {
      "seller_id": "pub-12345",
      "seller_type": "PUBLISHER",
      "name": "Example Publisher Inc.",
      "domain": "example.com",
      "confidential": 0
    },
    {
      "seller_id": "reseller-67890",
      "seller_type": "INTERMEDIARY",
      "name": "Ad Network Corp.",
      "domain": "adnetwork.com",
      "confidential": 0
    }
  ]
}

How ads.txt and sellers.json Work Together

These two specifications form a bidirectional verification mechanism. Think of it as a two-key verification system: the publisher publishes ads.txt to declare authorized sellers, and the seller publishes sellers.json to declare which publishers they represent.

A buyer can verify the full chain: the bid request claims to sell inventory from Publisher X, the publisher's ads.txt authorizes Seller Y to sell it, and Seller Y's sellers.json confirms they represent Publisher X. When both files align, confidence in the transaction is significantly higher.

The Complete Verification Flow

1. Bid request arrives at DSP claiming domain example.com with seller ID pub-12345 on exchange exchange.com
2. DSP crawls example.com/ads.txt and confirms exchange.com, pub-12345 is listed
3. DSP crawls exchange.com/sellers.json and confirms seller pub-12345 maps to example.com
4. If both checks pass, the bid request is considered authenticated

Implementation Guide for Publishers

Creating Your ads.txt File

1. Identify all advertising systems authorized to sell your inventory, including direct partnerships and reseller agreements.
2. Obtain the correct account ID and certification authority ID from each partner.
3. Create a plain-text file with one record per line in the standard format.
4. Upload the file to the root of your domain: https://yourdomain.com/ads.txt
5. Verify the file is accessible and returns a 200 HTTP status with text/plain content type.
6. Update the file whenever you add or remove advertising partners.

Common Implementation Mistakes

• Incorrect account IDs: Using the wrong publisher ID will cause buyers to reject your legitimate inventory. Always verify IDs with your exchange partners.
• Missing partners: Forgetting to list an authorized SSP means that SSP's bid requests for your inventory may be filtered, reducing demand and revenue.
• Stale files: Not removing former partners from ads.txt creates security gaps. Regularly audit your file.
• Wrong file location: The file must be at the domain root, not in a subdirectory. https://example.com/resources/ads.txt will not be found by standard crawlers.
• CDN caching issues: Ensure your CDN does not serve stale versions of the file. Set appropriate cache headers (max-age of 86400 seconds is common).

Impact on Fraud Prevention

Since the IAB Tech Lab published the ads.txt specification in 2017, adoption has grown dramatically. By 2024, over 80% of programmatic impressions were covered by ads.txt. The impact on domain spoofing has been substantial:

• Reduced spoofed inventory: Fraudsters cannot easily sell fake impressions from a domain they don't control because buyers will check ads.txt and find no authorization.
• Supply chain transparency: Advertisers can now audit their supply paths and eliminate unauthorized resellers.
• Revenue protection for publishers: By explicitly listing authorized sellers, publishers prevent unauthorized parties from monetizing their brand name.
• Higher CPMs for compliant inventory: Many DSPs prioritize or require ads.txt-verified inventory, driving higher demand for compliant publishers.

Limitations and Considerations

While ads.txt and sellers.json are powerful tools, they are not a complete fraud prevention solution:

• They do not prevent creative-based fraud, click fraud, or bot traffic on legitimate inventory.
• They rely on voluntary adoption and enforcement. Not all exchanges enforce ads.txt checks.
• The RESELLER relationship type creates broad authorization that can be exploited if a reseller is compromised.
• They do not address the issue of ads.txt files hosted on hijacked or expired domains.

For comprehensive fraud protection, ads.txt should be used alongside other signals such as the OpenRTB SupplyChain object, device ID verification, viewability measurement, and behavioral analysis.

Looking Ahead

The IAB Tech Lab continues to evolve these standards. Discussions around ads.txt v2.0 include potential improvements such as structured file formats, machine-readable error reporting, and tighter integration with the SupplyChain object. As programmatic advertising matures, publisher authorization will remain a foundational trust mechanism in the ecosystem.