ads.txt, sellers.json & the Art of Faking the Right to Sell

Put a plain text file at yoursite.com/ads.txt listing every company allowed to sell your ad inventory, and a buyer can check that list before spending money. If a bid claims to be your inventory and the seller is not on it, the bid is not legitimate.

It is a good idea. It killed an entire class of crude domain spoofing, it cost the industry almost nothing to adopt, and it remains one of the more successful standards ad tech has produced.

It also answers exactly one question, and fraudsters worked out which one.

This piece is about the gap between what the files prove and what people assume they prove — which is where most of the remaining supply-chain fraud lives, and where a fair amount of legitimate publisher revenue quietly leaks for reasons nobody explains.

What the standard actually says

ads.txt — Authorized Digital Sellers, published by IAB Tech Lab in 2017 — was built to combat domain spoofing and unauthorised inventory sales. Each line names a seller, the publisher's account identifier with that seller, and the nature of the relationship.

That relationship field carries more meaning than most people give it:

• DIRECT — the publisher directly controls the account with that seller. It is their relationship, their contract, their money.
• RESELLER — the publisher has authorised another party to sell this inventory on their behalf. Legitimate, common, and one hop further from the source.

Version 1.1, published in 2022, added two fields that matter commercially more than they sound:

• OWNERDOMAIN — the domain of the ultimate owner of the inventory, which lets a buyer connect several properties to one business rather than treating each as an unrelated site.
• MANAGERDOMAIN — the entity that manages the file and the monetisation. This is how sales houses, networks and management partners declare themselves.

Alongside it, sellers.json works from the other direction: each seller publishes the identities of the publishers it represents. And the SupplyChain object — SChain — travels with the bid request, declaring every intermediary the request passed through.

Together the three are meant to make the path from publisher to buyer legible: who owns it, who may sell it, and who touched it on the way.

The problem they were built to solve

It is worth remembering how bad it was before 2017, because it explains why the standard was adopted so fast and why its limits get overlooked.

Domain spoofing at the time required no sophistication at all. A bid request carried a claim about which site the impression was on, and there was no mechanism to check it. Claim to be a major newspaper, collect the CPM a major newspaper commands, serve the ad on a blank page. The Methbot operation spoofed more than 6,000 domains on essentially this basis.

ads.txt closed that by making the claim checkable against something the real publisher controls. That is a genuine achievement and the crude version of the attack has not come back. What returned instead is everything in the rest of this article — the versions that work with the file rather than against it.

Why the manager fields are worth real money

MANAGERDOMAIN is the field most publishers ignore and some sales houses cannot afford to.

Under the 1.1 spec, an entity managing another publisher's monetisation labels itself as such. The consequence is commercial: a sales house selling on behalf of a publisher is, in the file's terms, a RESELLER — even when it is the only route to that inventory and functionally the most direct path a buyer can take.

That collides with supply-path optimisation. Buyers running SPO frequently prefer, and sometimes exclusively buy, paths marked DIRECT or the shortest available chain. A managed publisher whose file does not declare MANAGERDOMAIN correctly can find their inventory deprioritised — not for quality reasons, but because the declaration made the shortest real path look like a longer one.

This is the part worth checking on your own site today. An ads.txt assembled two years ago by copying a partner's suggested lines, never revisited, is a live commercial problem rather than a compliance box.

The line count problem

There is a second, quieter cost to a neglected file, and it is one publishers cause themselves.

Files grow. Every partner onboarded adds lines, often a dozen at a time, and almost nobody removes them when the relationship ends. A file with several hundred entries is common, and a large share of them typically authorise sellers the publisher no longer works with, has never heard of, or was told to add by a partner who has since gone.

Each stale line is a standing authorisation. It says to the entire market: this company may sell our inventory. If that company's own diligence is poor — or if it has been acquired, or has quietly become a reseller of other people's supply — the permission is still live and the publisher is still the one whose name is on it.

Cleaning the file is unglamorous work with no immediate revenue attached, which is exactly why it does not happen. It is also the single highest-value hour a publisher can spend on supply hygiene.

The spoofing that still works

Now the part the standard did not close.

In 2018, DoubleVerify documented operators who did something more elegant than forging an ads.txt file. They did not touch the file at all.

The technique: scrape legitimate publisher sites, construct spoofed URLs that appear to belong to those publishers, and then sell that fraudulent inventory through resellers that were genuinely listed in the real publishers' real ads.txt files.

Every check a buyer performed passed, because every check was true. The publisher was real. The file was real. The reseller was genuinely authorised. What nobody verified was whether that reseller was examining what it had been handed to represent.

The attack walked in through a side door that a legitimate participant had propped open — not maliciously, but by treating "we have an authorised relationship with this publisher" as the end of its diligence rather than the beginning.

The structural gap, stated plainly

ads.txt answers: is this seller authorised by this domain?

It does not answer: does the domain deserve to exist; did this bid request genuinely originate from that domain; was there a page; was anyone on it; is the reseller checking anything.

A fraudster who owns their ghost domain outright can publish a perfectly valid ads.txt authorising themselves, register as a seller, appear correctly in sellers.json, and be entirely compliant with the standard while selling impressions to nobody at all. Compliance and legitimacy are different properties, and only one of them is machine-checkable.

Why the reseller did not notice

It is tempting to read the 2018 case as a story about one negligent company. The more useful reading is about incentives.

A reseller earns on volume that clears. Inventory arriving through its pipes that sells well is, from the inside, indistinguishable from a good month — the requests validate, the demand buys, the revenue arrives. Investigating why volume is unexpectedly good is work that can only ever reduce revenue, performed against a signal that looks like success.

That is the structural reason intermediaries under-investigate, and no amount of standards work fixes it. It is fixed, when it is fixed, by the parties above them making it commercially painful to be the hop where fraud entered — which is what supply-path optimisation actually does when buyers use it seriously.

app-ads.txt, and the CTV blind spot it half-closes

The mobile and connected-TV equivalent is app-ads.txt, and it works by indirection: an app store listing carries a developer website, and the file lives on that website's root. A buyer resolves app → developer domain → file.

That extra hop is where it gets weaker than the web version. A publisher who controls example.com obviously controls its ads.txt. An app's authorised sellers depend on the developer URL in a store listing being accurate and on that domain being controlled by the same party — two assumptions, both outside the buyer's ability to verify quickly, and both of which the CTV fraud in our timeline piece exploited repeatedly.

How buyers actually use these files

Worth knowing, because it explains why a stale file costs money quietly rather than loudly.

Buyers and verification vendors crawl these files at scale, frequently daily, and build a graph: every domain, every authorised seller, every seller's declared publishers from sellers.json, cross-referenced by seller ID. A bid arriving with a seller ID that does not match on both sides of that graph is a discrepancy, and discrepancies get discounted or dropped.

Nobody emails a publisher to say their file failed a cross-reference. The inventory simply becomes slightly less buyable, and the publisher sees a soft CPM they attribute to the market.

The AI escalation: Synthetic Echo

In January 2025 researchers documented a network of more than 200 mostly AI-generated content sites monetising across multiple exchanges with minimal human oversight.

Two details make it relevant here specifically.

First, the domains were built to be mistaken for real news brands — constructions in the shape of a known outlet with a suffix or a misspelling, the kind of name that survives a glance at a line item in a report.

Second, and more directly an attack on this standard: the sites cloned near-identical ads.txt files, replicating legitimate seller lists to appear correctly authorised across the whole network at once.

That is the escalation that matters. The earlier attack borrowed a real publisher's authorised reseller. This one mass-produces the appearance of authorisation itself, at a scale that generative tooling made trivial. A verification step that consists of "the file looks right" is now satisfied by a file that was generated to look right.

The part that applies to anyone running a wrapper

There is an obligation in this area that catches well-meaning technical operators, and it is worth stating precisely because the people it applies to often do not think of themselves as intermediaries at all.

If you manage Prebid wrappers for multiple publishers and handle their payments — you receive the revenue and distribute it — you are an intermediary in the supply chain. Prebid's own documentation is explicit that this position must be declared in the SupplyChain object.

Skip that declaration and you are, in the terms the industry uses, an undisclosed reseller. That is not a paperwork failure. Undisclosed intermediation is itself a fraud signal, and it is one that buyers actively filter on — so the practical consequence is that inventory passing through an undeclared hop can be discounted or dropped for reasons the publisher will never be told.

What would actually close the gap

The honest answer is that no file can, because the remaining question is not about authorisation at all. It is about whether the inventory is worth anything, and that is a judgement about content, audience and intent.

What the declaration layer can do, and is slowly moving toward, is make the chain short and attributable enough that somebody is accountable for the judgement. If a buyer can see every hop, and each hop is a named business with a reputation attached, then the question "who vouched for this" has an answer — and a party that repeatedly vouches for garbage becomes visible as such.

That is a slower and less satisfying mechanism than a filter. It is also the only one that has ever worked in any market with this shape: not verification, but attribution plus consequence.

What to actually do with all this

If you are a publisher

• Read your own ads.txt. Not skim — read it. Most publishers cannot say what every line in theirs is for, and lines accumulate from partners who came and went.
• Remove sellers you no longer work with. A stale authorisation is a standing permission for a relationship that has ended, and it is precisely the side door described above.
• Check OWNERDOMAIN and MANAGERDOMAIN are right. Especially if you are represented by anyone. Wrong entries cost money against SPO-driven buyers.
• Ask a prospective partner where they appear in your file and in SChain. A partner who cannot answer that immediately has not thought about the chain they are joining.

How to read a file you did not write

If you are evaluating a site — as a buyer, as a network considering representation, or as a publisher checking a competitor — the file itself tells you more than most people extract from it.

• Count the DIRECT lines. A site with genuine demand relationships has some. A file that is almost entirely RESELLER entries describes inventory that only ever reaches the market through other people, which is not disqualifying but is worth knowing.
• Look for the same seller listed many times with different account IDs. That usually means several partners were onboarded independently and nobody ever reconciled the file — a maintenance signal, not a fraud signal, but they correlate.
• Check whether OWNERDOMAIN points somewhere real. On a network of sites run by one operator, it will point at the same place from every property, which is exactly the connection it exists to make visible. On a network pretending to be unrelated publications, it is usually absent.
• Compare the file across sibling sites. Byte-identical files across several supposedly independent publications is the Synthetic Echo signature, and it is trivially checkable with a diff.

That last check costs about ninety seconds and would have caught a documented 200-site fraud network. It is worth doing on any set of properties offered to you as a portfolio.

If you are buying

• Treat ads.txt as necessary, not sufficient. It is a check against unauthorised selling, not against a worthless site.
• Shorten the chain. Supply-path optimisation is the single most effective control available, because every removed hop is a place a spoofed request cannot enter.
• Look at the domain, not only the declaration. Age, traffic composition, ad density and whether the content was written by anybody are all outside what these files can tell you — which is exactly why they are where the remaining fraud lives.

If you represent other publishers

The 2018 attack succeeded because a reseller did not examine what it was representing. That is the whole lesson, and it lands squarely on anyone in that position today. Being listed in a publisher's file is a statement to the entire market that you vouch for what flows through that relationship. Vouching without checking is how a legitimate business becomes somebody else's distribution channel.