In 2017, the Interactive Advertising Bureau (IAB) released a simple text file specification that would become a cornerstone of programmatic advertising transparency. The specification, known as ads.txt (Authorized Digital Sellers), was a direct response to a growing crisis: fake inventory, domain spoofing, and unauthorized reselling of ad impressions were costing the industry billions annually. The idea was deceptively simple—a plain-text file placed on a publisher’s root domain that lists every company explicitly authorized to sell that publisher’s digital inventory. By making this list publicly crawlable, buyers could verify that the impression they were bidding on came from a legitimate source.
Before ads.txt, programmatic advertising operated largely on trust. Ad exchanges aggregated inventory from thousands of sources, and a malicious actor could claim to represent a premium publisher like The New York Times or ESPN without any proof. Buyers paid for traffic that often never reached the intended site. The ads.txt standard gave buyers a lightweight, decentralized mechanism to check authorization. It did not require new infrastructure or heavy computational overhead—just a file that any HTTP client could fetch. For a community accustomed to complex machine learning models and signal processing pipelines, the elegance of a text-based solution was refreshing.
How ads.txt Works
The specification defines a simple record format. Each line contains three fields separated by commas: the publisher’s domain (or a subdomain), the seller’s account identifier (typically an exchange-specific ID), and a relationship type (DIRECT or RESELLER). Optionally, a fourth field can specify the certification authority ID. A DIRECT relationship means the seller is the publisher itself or its direct sales representative; RESELLER indicates an intermediary that has been authorized to resell the inventory.
When a demand-side platform (DSP) receives a bid request, it can fetch the publisher’s ads.txt file and cross-reference the seller ID in the bid with the list. If the seller is not listed, the DSP should reject the impression. This verification happens in real time, often within milliseconds. The file must be placed at the root of the domain (e.g., example.com/ads.txt) and must be publicly accessible without authentication. The IAB also provides a separate specification, sellers.json, for exchanges to list their own authorized publishers, creating a two-way verification loop.
The Historical Context: Why Mid-2000s Research Spilled Over
While ads.txt itself emerged in 2017, its conceptual roots trace back to earlier work in web security, digital watermarking, and content authentication. In the mid-2000s, academic groups studying document processing and image forensics had developed methods to verify the provenance of digital assets. Techniques such as robust hashing, digital signatures, and trusted third-party registries were being explored for medical images and legal documents. The programmatic advertising industry, however, lacked a unified provenance layer. The ads.txt specification borrowed from these earlier ideas but stripped them down to minimal overhead—no cryptographic signatures, no hash chains, just a plain-text whitelist.
The timing was right. By 2017, the ad tech ecosystem had matured enough that major exchanges (Google AdX, AppNexus, Index Exchange) could enforce the standard. The IAB Tech Lab, which also oversaw standards for OpenRTB and VAST, had the institutional weight to drive adoption. Within a year, most top-tier publishers had implemented ads.txt, and DSPs began rejecting bids from unauthorized sellers. The effect on ad fraud was measurable: domain spoofing rates dropped significantly for compliant inventory.
Implementation Checklist for Publishers
Setting up ads.txt is straightforward, but mistakes are common. A well-structured file should follow these rules:
- Place the file at the root (e.g.,
). Do not use subdirectories or redirects. - Use only authorized sellers that have a contractual relationship with you. Adding every exchange you have ever worked with dilutes the purpose.
- Keep the file updated whenever you add or remove a partner. Stale entries can lead to false positives or missed revenue.
- Validate syntax with the IAB’s ads.txt validator tool. A single misplaced comma or extra space can break parsing.
- Include both DIRECT and RESELLER entries for completeness. If you sell directly through an ad server, list it as DIRECT; for programmatic partners, use RESELLER.
Common Pitfalls
Even experienced publishers trip over a few recurring issues. One is mixing up account IDs across exchanges. For example, the ID for Google AdX (pub-xxxxxxxx) is different from the ID for Amazon Publisher Services (a2z-xxxxxxxx). Copying the wrong string renders the entry useless. Another pitfall is forgetting to include all subdomains. If your site uses separate subdomains for different sections (e.g., sports.example.com, news.example.com), each subdomain may need its own ads.txt file, or you can use a wildcard entry if the same sellers serve all subdomains. The specification allows wildcards only for the domain field, not for the seller ID.
Verification and Monitoring
Once the file is live, verification is not a one-time task. Buyers and third-party verification services (such as DoubleVerify, IAS, or Pixalate) continuously scan ads.txt files and report discrepancies. Publishers should monitor their file’s accessibility—a server error (500, 404) or a change in hosting can cause all bids to be rejected. Some DSPs cache the file for up to 24 hours, so updates may not take effect immediately. It is wise to check logs for frequent requests to /ads.txt; a sudden spike may indicate a bot scraping the file for competitive intelligence.
For smaller publishers with limited resources, there are hosted solutions that generate and serve the file automatically based on the ad partners configured in their ad stack. However, relying on third-party generators introduces a trust dependency—you must ensure the generator does not add unauthorized sellers. The safest approach is to maintain the file manually or via a version-controlled repository.
Limitations and the Evolution to app-ads.txt and sellers.json
ads.txt was designed for web inventory. As mobile app advertising grew, the IAB released app-ads.txt in 2019, which works similarly but is placed in the app developer’s website root. The same verification logic applies, with the app’s bundle identifier replacing the domain. Additionally, sellers.json (for supply-side platforms) and OpenRTB’s publisher object allow buyers to cross-reference both sides. These complementary standards form a trust framework that reduces but does not eliminate fraud. Sophisticated attackers still exploit gaps—for example, by registering lookalike domains or using misconfigured servers that serve a different ads.txt file than intended.
Another limitation is that ads.txt only verifies the seller identity, not the quality of the impression. A legitimate seller can still deliver low-quality or bot-driven traffic. The standard addresses only one vector of fraud: inventory misrepresentation. It does not stop click fraud, viewability fraud, or ad stacking. For those, additional detection methods—such as client-side measurement, behavioral analysis, and machine learning classifiers—remain necessary. The academic community that had worked on anomaly detection in the mid-2000s for medical imaging and speech recognition later adapted those techniques to ad fraud, but that is a separate story.
Practical Advice for Auditing a Publisher’s ads.txt
If you are a buyer or an ad operations professional, auditing a publisher’s ads.txt file can reveal red flags. Look for entries with obviously fake domains or misspelled publisher names. Check whether the file includes sellers that are not recognized by any major exchange. A file with dozens of RESELLER entries but no DIRECT entry may indicate a publisher that has lost control of its inventory. Conversely, a file that lists only DIRECT entries may be too restrictive and cause missed programmatic demand. When auditing, always compare the file against the publisher’s actual ad placements—if you see an ad from a seller not in the file, that is a violation.
The ads.txt specification has a provision for multiple entries with the same seller ID but different relationship types. This is allowed; a publisher may sell directly to an exchange and also authorize the exchange to resell to other buyers. However, having the same seller ID listed as both DIRECT and RESELLER in separate lines is redundant and can cause confusion in parsing. The recommended practice is to use a single line with the most appropriate relationship.
One final concrete detail: when a publisher migrates to a new content management system or changes DNS, the ads.txt file must be re-verified. A common oversight during site redesigns is forgetting to copy the file to the new server. A missing ads.txt file will cause all programmatic demand from compliant DSPs to drop to zero, often without immediate notification. Setting up an automated uptime check for the file path is a simple preventive measure that many operations teams overlook.