A one-line text file became the ad industry's paper trail

The revenue mechanism

Programmatic advertising lets a buyer purchase an impression without ever speaking to the publisher who owns the page, which created an opening for sellers of counterfeit inventory: traffic falsely labelled as coming from a well-known site. IAB Tech Lab announced on 17 May 2017 a plan to fix this with ads.txt, and followed with the finalised Version 1.0 specification the following month. Ads.txt is a plain-text file a publisher's webmaster posts at its own domain root, the same trust model as robots.txt: only the domain owner can put a file there, so its contents are a first-party, public declaration. The revenue mechanism is straightforward once that file exists: a buyer can check it before bidding, and an exchange claiming to sell a publisher's inventory but missing from that file can be treated as unauthorized.

What the documents show

The ads.txt specification page, describing the standard as retrieved on 16 September 2026, states the goal is to make "it harder for bad actors to profit from selling counterfeit inventory" by creating "a public record of Authorized Digital Sellers." The current specification text confirms the document "was developed in the spring of 2017" and defines exactly four data fields per line: the seller's domain, the publisher's account ID with that seller, whether the relationship is direct or a reseller, and an optional certification authority ID. Nothing in either document claims ads.txt detects fraud on its own; both describe it as a declaration that other systems must choose to check.

The assumptions exposed

Ads.txt assumes three things a publisher should not take for granted: that buyers actually crawl and enforce the file rather than ignoring it, that the file itself is kept current as sales arrangements change, and that a correctly listed seller is also an honest one. The specification verifies domain ownership of the list, not the integrity of every company named on it. A network can be "ads.txt authorized" while still being a poor commercial partner on price or payment terms; authorization is a fraud-prevention control, not a quality signal. Being listed also does not stop a determined spoofer from targeting a domain that has no file at all, which is why enforcement depends on buyer-side systems, not the file itself.

What to check before you rely on it

This is an editorial checklist. A publisher should confirm its own ads.txt file is current after any change in monetization partners, since an outdated file can quietly cut off legitimate demand rather than just blocking fraud.

• Does your ads.txt file list every exchange and network currently authorized to sell your inventory?
• Are reseller relationships marked correctly, since a wrong DIRECT/RESELLER value can misrepresent who controls the account?
• Which of your buyers actually enforce ads.txt, versus simply hosting a copy without checking it?

Ads.txt did not end counterfeit inventory; it gave the market a shared, checkable record that had not existed before, and the burden of actually consulting it still sits with each buyer.