Ads.txt is a one-line-per-seller text file that publishers post at their domain root to declare who is authorized to sell their ad inventory — and nine years after IAB Tech Lab introduced it, it still leaves an opening that a documented fraud network exploited at scale, according to a May 2025 industry alert from ad-verification firm DoubleVerify. The file works exactly as designed; the gap is what it was never built to check.
The specification is narrow by design, and that narrowness is the whole point for a publisher's ad-ops team trying to understand what the file actually promises. For a media business running programmatic display alongside subscriptions or events, ads.txt sits underneath every ad dollar that comes through open exchanges: buyers and demand-side platforms increasingly refuse to bid on inventory that isn't declared, which makes the file a revenue gate as much as a fraud control.
What is ads.txt actually checking?
Ads.txt is a plain-text file hosted at a publisher's domain root (/ads.txt), specified by IAB Tech Lab, that lists every ad exchange, supply-side platform, or reseller a publisher has authorized to sell its inventory. IAB Tech Lab describes it as "a simple, flexible and secure method that publishers and distributors can use to publicly declare the companies they authorize to sell their digital inventory," built to make it harder for bad actors to profit from selling counterfeit inventory across the programmatic supply chain. The file does not verify a publisher's traffic, content, or audience — only which seller accounts that publisher has vouched for.
How does an exchange use the file during a live bid?
Under the current specification, version 1.0.2, published by IAB Tech Lab in March 2019, each line in the file carries four comma-separated fields. An exchange or demand-side platform is supposed to cross-check the domain in an OpenRTB bid request against the publisher's posted ads.txt file before treating the inventory as legitimate.
| Field | Required | What it declares |
|---|---|---|
| Exchange domain | Yes | The canonical domain of the SSP or exchange authorized to sell the inventory |
| Publisher account ID | Yes | The seller's account identifier inside that exchange, matched against live bid requests |
| Account type | Yes | DIRECT (publisher controls the account) or RESELLER (an authorized third party controls it) |
| Certification authority ID | No | An optional ID from a body such as the Trustworthy Accountability Group |
That matching step is what makes ads.txt effective against the fraud it was built for: an exchange selling a publisher's domain without appearing in that publisher's file is, by definition, unauthorized, and buyers using verification tools can decline the bid. It does nothing, however, to confirm that the domain making the bid request is the real publisher's domain in the first place.
What did the 2025 fraud alert show?
That second gap is what a May 2025 industry alert from ad-verification firm DoubleVerify flagged. The firm said bad actors are cloning legitimate publishers' authorized-seller lists onto fraudulent sites, then relying on look-alike domain names to get programmatic platforms to treat the traffic as genuine. It identified a network it named "Synthetic Echo" — more than 200 AI-generated sites using domains such as espn24.co.uk, nbcsportz.com, and cbsnewz.com — that copied real publishers' ads.txt entries nearly verbatim to appear authorized while diverting ad spend away from the outlets they were impersonating. DoubleVerify said it has documented more than 100 cases of this kind of ads.txt deception since the standard launched in 2017, with the pace increasing in recent years; its fraud-lab head said in the alert that "advertisers often have no idea it's happening." That is one vendor's fraud-detection network, disclosed in its own alert — a documented pattern, not an industry-wide census of every exchange's exposure, and DoubleVerify itself sells the tools that catch this kind of spoofing, a fact worth keeping in view when reading any vendor's own fraud numbers.
The mechanics of the trick are what make it hard to catch with ads.txt alone. Because the file is public by design — any buyer can fetch it — a fraud operation can copy a real publisher's exact seller list, line for line, onto a domain built to look like that publisher at a glance. An automated bid-matching check sees a technically valid ads.txt entry either way; it has no field for confirming that the domain requesting the bid is the one the audience actually typed in or clicked through to.
What generalizes to a publisher's checklist, and what doesn't?
What generalizes: maintaining an accurate, current ads.txt file is table stakes, not optional hygiene — buyers and verification vendors increasingly decline unlisted inventory outright, so an outdated or missing file is a direct, avoidable revenue leak. Cross-checking the account IDs listed against what a publisher's actual exchange partners report is a five-minute audit worth doing on a recurring basis, since a stale RESELLER line is exactly the kind of entry a spoofing operation can imitate.
What doesn't generalize: ads.txt alone does not stop a fraud ring from registering a look-alike domain and copying a legitimate seller list onto it, because the file authenticates seller accounts, not the domain making the request. Closing that gap depends on separate domain-monitoring and traffic-verification layers — the kind DoubleVerify and similar firms sell — sitting on top of, not instead of, the ads.txt declaration itself.
For a related creators perspective, read What Patreon, Substack, Ghost, and YouTube actually take from creator revenue.