What is domain spoofing, and how do buyers catch it?
Part of Supply path transparency
The short answer
Domain spoofing is a form of ad fraud in which a bid request names a website the seller has no right to sell, so buyers pay premium prices for impressions that run somewhere else. Buyers counter it by checking the seller account against the named site's ads.txt, the exchange's sellers.json and the request's supply chain object.
Key takeaways
- A spoofed request lies about the site.domain or page field, which buyers' platforms otherwise take on trust.
- ads.txt authorizes seller accounts for a domain, so an account the domain never listed can be refused before bidding.
- A mismatch between the domain a buyer bid on and the domain where the ad actually rendered is the clearest sign in reports.
- A private deal limits who may bid but does not prove the inventory is what the request says it is.
What is domain spoofing?
Definition
- Domain spoofing
- Offering ad inventory in real time bidding under the domain of a site the seller is not authorized to sell, so the buyer believes the ad will appear on that site.
The IAB Tech Lab wrote ads.txt to counter exactly this. The introduction to the ads.txt 1.1 specification (opens in a new tab) describes the target in one sentence, quoted below. The spoofer gains because the impression is priced as if it ran on a known publisher, while the ad lands on a cheaper page or an unrelated site.
Typically the domain of the webpage, or the ID of the mobile app has been falsified to look like a site or app they do not have authorization to sell.
Measurement standards treat it as a hard case. The Media Rating Council's June 2020 invalid traffic addendum (opens in a new tab) lists "Domain and App misrepresentation: App ID spoofing, domain laundering and falsified domain / site location" among its key examples of sophisticated invalid traffic, the category it says requires advanced analytics and multi-point corroboration to identify. A wider field guide to schemes sits on the ad fraud types page; this page stays with the selling path.
How does ads.txt help prevent domain spoofing?
ads.txt moves the question of who may sell a site onto the site itself. The publisher posts a file at its root domain listing each advertising system and the account ID it uses there. The specification says it is meant to be used with site.domain or app.bundle in OpenRTB bid requests, and that advertising systems should retrieve the declarations before buying or selling advertising claiming to be on the website. For SSPs it recommends placing the seller's account ID in Publisher.ID and populating Site.Domain with the domain that hosts the ads.txt file where that ID is posted.
How a buyer's platform tests one request against ads.txt
- Read the claimed domain. Take site.domain from the request, or the bundle for an app, and reduce it to the root domain the specification defines, the public suffix plus one label.
- Fetch the cached file. Look up that domain's ads.txt, refreshed on the expiry the specification sets, which defaults to seven days when no cache directive is present.
- Match the account. Look for a line whose advertising system domain equals the exchange sending the request and whose account ID equals publisher.id.
- Apply the result. No matching line means the seller account was never authorized for that domain, so the request can be refused before a bid is placed.
- Record the relationship. A match also returns DIRECT or RESELLER, which the next checks in sellers.json test again.
What do sellers.json, the SupplyChain object and ads.cert add?
Each of the IAB Tech Lab's supply chain tools closes a different gap. The Tech Lab's ads.txt implementation guidance (opens in a new tab) credits ads.txt with helping reduce "misrepresentation (aka 'domain spoofing')" and says buyers can now use ads.txt, sellers.json and the OpenRTB SupplyChain object together for a more comprehensive view. ads.cert works on a different layer, the connection between systems.
| Control | What it checks | Gap it leaves |
|---|---|---|
| ads.txt | That the exchange and account ID in the request are authorized by the claimed domain | Cannot see the page actually loaded, or a request whose fields were altered after it left the seller |
| sellers.json | Who the account belongs to, its seller_type and its business domain | Confidential entries hide the name, and the file says nothing about one specific impression |
| SupplyChain object (schain) | Every seller and reseller that handled this request, in order, and whether the chain is complete | A node can only be checked against the files; a chain marked incomplete leaves the start unknown |
| ads.cert Authenticated Connections | A signed HTTP header showing the request came from the claimed system and was not tampered with | Proves who sent the request, not that the page or domain inside it is true |
The SupplyChain rules matter here because a reseller must add itself. The SupplyChain object specification (opens in a new tab) says it is invalid for a reseller to copy the previous seller's object without inserting its own node. The open source ads.cert repository (opens in a new tab) explains that Authenticated Connections signs the URL, the POST body and the timestamp, origin and destination, and labels the library itself a proof of concept not meant for use in its current form, so buyers should ask each partner whether it signs traffic at all.
How can a buyer detect a declared seller that does not match the bid request?
A mismatch is any point where the request, the publisher's file and the exchange's directory tell different stories. The implementation guidance gives the core rule: when the sellers.json domain equals the OWNERDOMAIN in ads.txt, the seller is the owner; when it equals neither OWNERDOMAIN nor MANAGERDOMAIN, the seller is a reseller, whatever the ads.txt line says. The checks below can run on a sample of logged requests.
Mismatch tests for one logged request
- The host in site.page belongs to the root domain in site.domain.
- The pair of exchange domain and publisher.id appears in that domain's ads.txt.
- The same ID appears in the exchange's sellers.json, with a seller_type that fits the ads.txt label.
- For a DIRECT line, the sellers.json domain equals the site's OWNERDOMAIN or MANAGERDOMAIN.
- The schain nodes name each exchange and account the request passed through, and the last node matches the sender.
- For a complete chain, the first node is the owner's own account on the first exchange.
- If the request carries inventorypartnerdomain, that domain's own ads.txt authorizes the seller.
A failed test is a lead, not a verdict. A publisher can forget an ads.txt line, and the ads.txt checking guide covers honest errors with the same symptom. Invalid traffic filtering, covered in the invalid traffic guide, completes the picture.
What does a spoofed domain look like in reports?
No single report column says spoofed. The signal is disagreement between what the buyer bid on and what measurement saw. Display & Video 360, as one example, offers an Authorized Seller state (opens in a new tab) reporting dimension that sorts bought inventory into Authorized Direct Sellers, Authorized Resellers, Non-Participating Publishers and Ineligible. Google says declaring authorized sellers helps protect buyers and sellers from misrepresented inventory, but the dimension reports authorization status; it does not label an impression as spoofed.
| Pattern in the data | What it can mean | Next check |
|---|---|---|
| The domain in bid logs differs from the domain a measurement tag recorded where the ad rendered | The request named one site and the ad ran on another | Pull the page URLs for those impressions and the seller IDs that sold them |
| A known publisher arrives through a seller ID missing from its ads.txt | An unauthorized account is selling under that name | Confirm the file on the live site, then block the account for that domain |
| A DIRECT label whose sellers.json domain is unrelated to the site | A reseller is presenting itself as the owner | Compare the sellers.json domain with OWNERDOMAIN and MANAGERDOMAIN |
| Requests for a site through an exchange the site has never listed | Resold or invented supply under the site's name | Read the schain nodes and ask the exchange who sent the inventory |
Can spoofing happen in private marketplace deals?
Yes, because a deal ID restricts who may bid, not what the request says about the site. The seller still fills site.domain and publisher.id. Display & Video 360's help page shows the pressure point: its Authorized and Non-Participating Publishers option, which also buys from publishers with no ads.txt file, raises inventory quality risk, and Google advises considering it only temporarily for private deals.
A deal built from a checked site list narrows the risk further, since each domain's sellers are known before the deal ID exists. The curated deals hub explains how those deals are set up.
What does a spoofing review look like on a real plan?
Fictional example
A term life insurer in Boston and Hartford
A fictional term life insurer wants display ads beside personal finance, retirement planning and local news sites read in Massachusetts and Connecticut, in English. Its agency's trading desk buys an approved list of regional publishers through two exchanges.
In the first week the desk samples logged requests. One personal finance site, written here as bayledger.example, arrives through its own account on the first exchange and also through a second account on an exchange its ads.txt does not list. The second path's schain is marked incomplete, and its first known node is an intermediary whose sellers.json domain has no link to the site.
The desk blocks the unlisted account for that domain, keeps the publisher's own path and asks the exchange to explain where the second account's supply came from. The measurement report for the blocked path is compared with the bid logs, and the page URLs there belong to other domains. The publisher stays on the plan, bought only on its authorized path.
How does PlacementGraph help before a spoofed request arrives?
Frequently asked questions
Is domain spoofing the same as domain laundering?
They are close relatives. The MRC groups app ID spoofing, domain laundering and falsified domain or site location together under domain and app misrepresentation, one of its sophisticated invalid traffic examples. In each case the buyer is told the impression belongs to one property while it belongs to another, which is why the same seller checks apply.
Does app-ads.txt stop spoofing of mobile and CTV apps?
It applies the same idea to apps. The ads.txt specification names a falsified app ID as the app form of the problem, and app-ads.txt lets the developer list authorized sellers on the website named in the store listing. The app-ads.txt guide explains how buyers' platforms find the file through the store.
Can a publisher's own mistake look like spoofing?
Yes. If a publisher forgets to list a real partner, or lists the wrong account ID, legitimate requests through that partner fail the ads.txt match exactly as a spoofed one would. Before blocking a known publisher, confirm the live file and ask the publisher or exchange whether the account is theirs.
Should ads.txt be served over HTTPS?
The specification allows HTTP or HTTPS but warns that an unauthenticated fetch could be intercepted or impersonated. Its suggested remedy is for site owners to redirect plain HTTP requests for the file to HTTPS. Buyers checking a file by hand can open the HTTPS address and compare it with what their platform cached.
Sources
- ads.txt Specification Version 1.1 (opens in a new tab)IAB Tech Lab, Supply Chain Validation repository
- Ads.txt Implementation Guidance (opens in a new tab)IAB Tech Lab, Supply Chain Validation repository
- sellers.json specification (opens in a new tab)IAB Tech Lab, Supply Chain Validation repository
- SupplyChain object specification (opens in a new tab)IAB Tech Lab, OpenRTB repository
- OpenRTB 2.6 specification (opens in a new tab)IAB Tech Lab, OpenRTB 2.x repository
- ads.cert Authenticated Connections Protocol library (opens in a new tab)IAB Tech Lab, GitHub
- Invalid Traffic Detection and Filtration Standards Addendum, June 2020 update (opens in a new tab)Media Rating Council
- Authorized Digital Sellers (opens in a new tab)Google, Display & Video 360 Help
Researched and written by PlacementGraph Research. Read how we research, source and update these pages. Corrections: diana@placementgraph.com.