Tales From The Ads.txt Trenches

The Sell Sider” is a column written for the sell side of the digital media community.

Today’s column is written by Ian Hewetson, vice president of client services at Eyereturn Marketing.

Forget this summer’s solar eclipse. We’re witnessing something far more unusual right now: the universal endorsement of a single system in the ad tech world, the adoption of Ads.txt.

Ads.txt truly is an elegantly simple, universally accessible solution to a problem that’s bedeviled the industry for far too long. But in the rollout excitement, a few subtle issues are emerging that may have outsize effects on buyers and sellers without the right level of oversight.

Ads.txt solves a single problem: domain spoofing. This is where someone creates a fraudulent site and passes the false domain to the supply-side platform (SSP), which sends the false domain to a demand-side platform (DSP), which bids on it.

Advertisers suffer because they’re not buying New York Times inventory. The New York Times suffers because the fake NYT inventory undercuts its pricing. And the reputation of ad tech suffers for allowing this to continue.

On the surface, Ads.txt is very simple. Publishers place a text file on their site, which only they can do. The text file states which sellers represent that site. DSPs create databases matching buyers and sellers. When a DSP sees an impression being offered by a seller not listed on the site’s Ads.txt file, it can reject that bid. If DSPs only buy Ads.txt inventory, they’re inoculating themselves against buying spoofed domains.

Though this is simple, the devil can be in the details. In the course of an Ads.txt rollout, it became clear that a lack of communication between publishers and SSPs could break the system. Critically, the only party that can really identify these breakdowns is the DSP.

For example, we saw one instance where a publisher had implemented its Ads.txt file for two major sellers. It contacted both sellers to ensure that it was done correctly so that its inventory would be surfaced by those sellers as Ads.txt-verified. Both sellers confirmed that all was good, which the publisher took at face value.

Except all was not good. In both cases, the publisher’s inventory was not being seen by buyers as Ads.txt-compliant.

For the first seller, the Ads.txt protocol was outside the general standard. This seller uses multiple legitimate paths to sale, and the Ads.txt setup is rather convoluted, requiring distinct domains for different types of inventory. Strike 1: The publisher failed to interpret the specs correctly and implemented Ads.txt incorrectly. Strike 2: The seller looked at the implementation and declared it to be valid when it was not.

In the case of the second seller, the Ads.txt setup was very straightforward, and the publisher implemented it correctly. But it appears the seller was not passing the publisher ID on the bid request, resulting in a mismatch, which stops any bidding on this inventory. In this case too, the publisher reached out to the seller, but the last I heard, the issue was still unresolved.

Both issues only came to light during Ads.txt testing of my company’s DSP when we checked Ads.txt compliance on our top 1,000 domains. Having a relationship with this publisher and not seeing its inventory as approved, we contacted it and helped with the investigation.

When we first raised the flag, the publisher initially assured us that its implementation was golden because both of its sellers had verified that it was. It took some actual investigation and collaboration to figure out the issue.

What we’ve taken away from the experience is that Ads.txt is a great solution to the problem of spoofed domains. What we’ve also discovered is that it’s subject to a wide variety of missteps on the implementation side, and these missteps can slip through multiple hands unless verification is done on the demand side.

If you’re a publisher reading this and you’ve noticed any decline in demand since implementing Ads.txt, you should check with your DSP to make sure your implementation is correct. And if you’re on the demand side and not seeing specific inventory sources, give those publishers a call.

We’re all in this together, and while it’s a programmatic world, sometimes it takes some real-world collaboration to get the job done right.

Follow Eyereturn (@EyereturnMktg) and AdExchanger (@adexchanger) on Twitter.

Enjoying this content?

Sign up to be an AdExchanger Member today and get unlimited access to articles like this, plus proprietary data and research, conference discounts, on-demand access to event content, and more!

Join Today!


  1. Great article Ian. Spot on. According to a production crawler of ads.txt there are now 100K domains with ads.txt posted. We’re at a point where DSPs are publicly announcing that they will be doing “negative selection” against unauthorized supply paths for domains posting ads.txt. I’m confident that we’ll all learn a ton from this process.

  2. Caveat. Ads.txt is a browser only/browser built solution, and as it stands today does not work for in app inventory (and likely not for OTT inventory). As a near majority of digital media experience now happen outside of the browser, Ads.txt is not a universally accepted solution for digital media – since it is currently a browser based solution.

  3. Anne, is there a universal solution for digital media ever? Brand safety and fraud are important topics, but as advertising and media evolve the ones who keep the customer in mind and quality will win.

  4. There are now numerous ads.txt validators available to help ensure ads.txt files are created correctly, and as adoption progresses the understanding of the ads.txt specification has improved on both the demand and supply sides. You may find https://adstxt.guru/ useful, this provides an ads.txt management and collaboration tool which automatically formats and validates ads.txt files, whilst allowing ad networks/SSPs to control their own records within publisher ads.txt files.