The IAB Tech Lab released the ads.txt specification in May 2017 with a straightforward premise: if publishers publicly declare which ad technology companies are authorized to sell their inventory, buyers can verify those declarations before bidding. The mechanism is simple. The implications are significant. And for once in this industry’s ongoing fraud conversation, we have a technical solution that might actually work — if adoption moves fast enough to matter.
Domain spoofing is the fraud pattern ads.txt addresses. In a domain spoofing attack, a fraudulent inventory seller represents a low-quality or outright fake website as a premium publisher in bid requests. The DSP sees a bid request claiming to be inventory from the Wall Street Journal or the New York Times. The buyer’s system bids accordingly. The impression is delivered on a content farm or a bot-traffic generator. The buyer paid premium CPM for garbage.
The ANA/White Ops bot fraud report from 2014 identified domain spoofing as a significant source of advertiser losses. Subsequent research has consistently confirmed that domain spoofing is not a marginal problem — it affects budget at material scale. Until ads.txt, buyers had no reliable, publisher-side mechanism to verify that the party selling them inventory was actually authorized to do so.
How Ads.txt Works Technically
The implementation is deliberately simple, which is part of why it has a realistic chance of achieving broad adoption.
A publisher creates a plain text file named ads.txt and places it at the root of their domain — visible at, for example, nytimes.com/ads.txt. The file contains records listing each ad tech company authorized to sell the publisher’s inventory. Each record includes the domain of the advertising system (the SSP or exchange), the publisher’s account ID on that system, the type of relationship (DIRECT for direct relationships, RESELLER for authorized resellers), and optionally the Seller ID from the exchange’s certification authority.
An example record: appnexus.com, 1000001, DIRECT, f08c47fec0942fa0
This single line declares that AppNexus (appnexus.com) is authorized to sell inventory for this publisher, under account ID 1000001, as a direct relationship. The optional fourth field is the TAG-ID from the Trustworthy Accountability Group, providing additional verification.
A buyer’s DSP crawls ads.txt files from publishers and maintains a database of authorized seller relationships. When a bid request arrives claiming to be inventory from a specific publisher, the DSP checks whether the selling exchange and seller ID in the bid request matches an authorized entry in that publisher’s ads.txt file. If the match exists, the inventory is legitimate. If the bid request is claiming to be inventory from a publisher but the exchange and seller ID don’t appear in the publisher’s ads.txt, the bid request is potentially spoofed.
The IAB Tech Lab’s ads.txt specification provides the full specification, including the file format requirements, record syntax, and recommended implementation guidelines for both publishers and buyers.
Publisher Implementation Steps
For publishers, the implementation is straightforward but requires coordination with ad operations teams who understand all existing inventory monetization relationships.
Start by inventorying every ad technology company that is authorized to sell your inventory. This includes direct SSP relationships, networks with direct access to your inventory, and any reseller arrangements where another party is authorized to license your inventory to others. This inventory step is often more complex than it sounds — large publishers may have dozens of authorized relationships across direct monetization partners, AMP inventory deals, video monetization platforms, and regional network arrangements.
Once the inventory is complete, create the ads.txt file in the correct format, including all authorized relationships. DIRECT entries cover SSPs and exchanges where your account is directly managed. RESELLER entries cover parties who are authorized to resell your inventory but are not your direct account manager — for example, if an exchange can resell your inventory to downstream networks.
Place the file at the domain root (yourdomain.com/ads.txt), ensuring it is accessible via HTTP without authentication and with correct MIME type. Update the file whenever authorized relationships change — new exchange partnerships, discontinued relationships, account ID changes. A stale ads.txt file that doesn’t include active authorized sellers will cause legitimate inventory to fail validation checks once buyers begin enforcing ads.txt compliance.
What Happens to Exchanges That Don’t Adopt
The enforcement mechanism for ads.txt works from the buyer side: DSPs that crawl ads.txt files and filter bid requests against authorized seller lists will not bid on inventory claimed from publishers who have ads.txt files if the selling exchange doesn’t appear in the authorized list.
For exchanges that don’t implement seller-side support for ads.txt — meaning they don’t propagate accurate publisher account IDs in bid requests and don’t support the seller identification structure the spec requires — the consequence is that buyers enforcing ads.txt compliance will stop bidding on their inventory. Over time, as DSPs and buyers move toward ads.txt enforcement as a buying standard, exchanges without proper ads.txt support will face buy-side pressure.
The timeline for this enforcement pressure depends on buyer and DSP adoption, which is itself contingent on publisher adoption. If a significant percentage of publisher inventory doesn’t have ads.txt files, buyers can’t enforce it as a blanket buying standard — too much legitimate inventory would be excluded. Publisher adoption at sufficient scale is the necessary precondition for buyer-side enforcement to be meaningful.
Current adoption, several months after the spec release, is growing but uneven. Large premium publishers are moving to implement. Mid-tier publishers are more varied. The programmatic industry’s history of adoption curves suggests that a major DSP or buyer enforcing ads.txt as a buying requirement — announcing they will stop bidding on non-authorized inventory — would accelerate adoption significantly.
Whether It Becomes a Buying Requirement
The practical question for trading desks and programmatic buyers: should ads.txt compliance be made a buying requirement now, and if so how?
The challenge with enforcing ads.txt as an immediate blanket requirement is coverage gaps. If 60 percent of publisher inventory has ads.txt files and your DSP filters for ads.txt compliance, you lose access to 40 percent of inventory — including legitimate publishers who haven’t yet implemented the spec. A blanket enforcement policy right now would significantly reduce reach on campaigns.
The more practical near-term approach is to use ads.txt compliance as a quality signal in bid evaluation rather than a hard gate. Configure your DSP to deprioritize or apply a CPM discount to bid requests from publishers without ads.txt files or where the selling exchange doesn’t appear in the authorized list. This reduces exposure to spoofed inventory without cutting off all non-ads.txt inventory.
The medium-term expectation is that ads.txt becomes a buying requirement for any campaign with brand safety considerations — within 12 to 18 months, as publisher adoption reaches a threshold where enforcement doesn’t severely restrict reach. DSPs that build robust ads.txt crawling and enforcement capability now will be positioned to offer this as a buying feature when the market is ready.
The Trade Desk’s verification and transparency resources and other major DSPs have signaled commitment to ads.txt implementation, though specific enforcement timelines vary. Buyers should ask their DSP partners directly about ads.txt crawl frequency, enforcement options, and timeline for making it a default buying filter.
The Realistic Timeline
Industry adoption of technical standards follows a pattern: early adopters (major publishers, large DSPs) move quickly; mid-market follows over 6 to 12 months; long tail adoption is slow and may never be complete. Ads.txt will likely follow this curve.
For buyers, the opportunity is now: configure your DSP to report on ads.txt compliance for your current campaigns, use the data to identify the extent to which you’re currently buying non-authorized inventory, and begin planning for enforcement. The publishers who matter most to your campaigns — high-spend, brand-sensitive inventory — should be on your ads.txt implementation list to contact directly if they haven’t already published files.
Domain spoofing is a solvable problem if buyers drive adoption. The standard exists. The implementation is simple. The missing piece is market pressure sufficient to make adoption universal.
Frequently Asked Questions
What is domain spoofing and how does ads.txt prevent it? Domain spoofing is a fraud technique where a fraudulent seller represents inventory as belonging to a premium publisher in programmatic bid requests. Buyers bid at premium CPMs assuming they are buying from the named publisher, but the impression delivers on a fraud site. Ads.txt prevents this by allowing publishers to publicly declare authorized sellers — buyers can verify that the exchange submitting a bid request for a publisher’s inventory is actually authorized by that publisher.
How does a DSP use ads.txt files to filter inventory? DSPs crawl ads.txt files from publishers across the web and maintain a database of authorized publisher-exchange relationships. When a bid request arrives claiming to be from a specific publisher, the DSP checks the selling exchange and seller account ID against the publisher’s ads.txt entries. A bid request from an exchange that doesn’t appear in the publisher’s authorized list is flagged as potentially spoofed and can be filtered or down-weighted.
Does ads.txt work for video and app inventory? The initial ads.txt specification focuses on web inventory. Similar mechanisms for app inventory (app-ads.txt) and for seller-side transparency (sellers.json) are discussed within the industry and may be developed as subsequent standards. For now, ads.txt addresses the domain spoofing problem in web-based display and video programmatic inventory.
What is the RESELLER relationship type in ads.txt and when should publishers use it? RESELLER entries cover ad technology companies that are authorized to resell a publisher’s inventory but don’t have a direct account relationship with the publisher — for example, exchanges that can access publisher inventory through an SSP intermediary. Publishers should include all authorized reseller relationships in their ads.txt file to prevent legitimate reseller traffic from being misidentified as spoofed, while being careful not to include unauthorized parties that could be exploiting the reseller channel.