Auditing DV360 Spoofing Fraud with Sellers.json and ads.txt
Auditing DV360 spoofing fraud requires cross-referencing incoming bid requests against the publisher's published ads.txt and the exchange's sellers.json files to verify direct and reseller authorization paths. When bad actors falsify domain names in the OpenRTB bid stream, standard viewability and brand safety wrappers from vendors like IAS or DoubleVerify only catch the symptom after the bid wins; manual or programmatic inspection of authorized digital sellers is the only way to cut off the supply at the root.
Key Takeaways
- Domain spoofing relies on fake OpenRTB headers where unverified supply-side platforms (SSPs) pass premium publisher URLs they have no rights to sell.
- Checking an exchange's sellers.json file confirms whether a specific publisher ID is listed as Direct, Reseller, or omitted entirely as an unauthorized entity.
- Cross-referencing ads.txt validates that the SSP transacting the impression is officially sanctioned by the domain owner to monetize that specific inventory source.
- Automating this verification workflow prevents budget leakage, ensuring custom bids and private marketplaces operate without malicious supply paths.
Ad-ops leads running enterprise campaigns in Display & Video 360 often encounter discrepancies where spend concentrates on domains that yield zero genuine human traffic or fail basic verification metrics. While verification partners deploy pre-bid segments to mitigate bad inventory, malicious actors continually evolve domain spoofing tactics, such as URL masking and fraudulent header injection. Relying solely on dashboard alerts is insufficient. Traders must inspect the underlying plumbing: the ads.txt file hosted on the publisher's root domain and the sellers.json file hosted by the exchange.
Understanding these authorization frameworks is particularly critical when managing complex campaign structures. For instance, if you are scaling video inventory and notice unexpected delivery drop-offs or waste, you might investigate issues similar to those outlined when dealing with Vast error 303 troubleshooting in DV360 video and CTV campaigns. Supply chain transparency directly impacts yield and performance across all formats.
Deconstructing the OpenRTB Bid Stream and Spoofing Vectors
Every programmatic transaction begins with an OpenRTB bid request. Within this payload, the publisher domain is declared in the `publisher.domain` or `site.domain` field, while the exchange details its relationship via the `publisher.id` or `seat` parameters. Fraudsters exploit this architecture by injecting high-value domains into the bid stream while routing the actual ad impression through low-quality or completely unrelated publisher sites.
Consider a scenario where an unverified SSP sends a bid request claiming to represent `news-premium-site.com`. Your DV360 line item evaluates the bid, applies targeting criteria, and wins the auction. Upon inspection, the tracking pixel fires on a parked domain or a MFA (Made-For-Advertising) site. The SSP collected the arbitrage margin, and your brand safety vendor flags the mismatch too late. To intercept this before money changes hands, traders must audit the authorization chain using two IAB standards: ads.txt and sellers.json.
Inspecting ads.txt and app-ads.txt Direct Files
Authorized Digital Sellers (ads.txt) is a plain text file that publishers host on their root domain (e.g., `example.com/ads.txt`). It lists every entity authorized to sell the publisher's inventory. For mobile apps and CTV environments, the equivalent is `app-ads.txt`, crawled via the app store listing URL.
A standard ads.txt line contains four distinct components:
- Exchange Domain: The canonical domain name of the SSP or exchange (e.g., `rubiconproject.com`).
- Publisher's Account ID: The unique identifier corresponding to the seller's account within that specific exchange (e.g., `12345`).
- Supply Relationship Type: Designated as either `DIRECT` (the publisher manages the account directly with the exchange) or `RESELLER` (the publisher authorizes a third party to resell their inventory).
- Certification Authority ID: An optional field referencing the Trustworthy Accountability Group (TAG) registry (e.g., `f0847936a71cbdf3`).
When auditing a suspicious domain in DV360, your first step is navigating directly to `https://[publisher-domain]/ads.txt`. Search the file for the SSP domain transacting your impressions. If the exchange is absent, or if the publisher ID does not match the ID in the bid request, the transaction is unauthorized. This constitutes a severe spoofing risk, and the domain or SSP must be blocked via DV360 channel targeting or exclusion lists.
Querying Exchange sellers.json for Ownership Verification
While ads.txt is maintained by the publisher, sellers.json is maintained and published by the exchange or SSP (hosted at `exchange.com/sellers.json`). This file provides a directory of all entities that the exchange pays for inventory. Combining ads.txt and sellers.json allows ad ops to perform a bidirectional verification loop.
The sellers.json file exposes key attributes for every seller ID:
- seller_id: The identifier matching the second field in the publisher's ads.txt file.
- name: The legal business name or DBA of the entity operating the account.
- seller_type: Categorized as `PUBLISHER`, `INTERMEDIARY`, or `BOTH`.
- domain: The business domain associated with the seller account.
If an SSP passes an impression claiming to represent a publisher, but that publisher ID is missing from the SSP's sellers.json file—or if the domain associated with that seller ID points to a suspicious, unrelated shell company—you are looking at intermediate spoofing or unauthorized arbitrage. Enterprise traders often write Python scripts to ingest sellers.json files via API, matching them against daily DV360 log files to flag discrepancies at scale.
Maintaining pristine supply paths is just as important in direct commitments as it is in open auction campaigns. Ensuring that your supply path is optimized helps avoid issues similar to those managed when resolving inventory bottlenecks during DV360 programmatic guaranteed deal under-pacing troubleshooting. Clean supply paths prevent wasted budgets from getting trapped in spoofed intermediaries.
Operationalizing Fraud Audits Within DV360
Manual inspection of individual domains does not scale across enterprise accounts managing millions of monthly impressions. Ad-ops teams must operationalize these checks within DV360 workflows. Start by extracting scheduled reports from DV360 that isolate spend by exchange, app ID, and publisher domain. Filter for high-volume domains with anomalous win rates or low viewability metrics.
Next, implement Supply-Path Optimization (SPO) strategies that restrict buying to direct pathways or certified resellers. By consolidating your exchange relationships and cutting out long reseller tails, you drastically reduce the surface area for domain spoofing. Pair your SPO efforts with custom channel exclusions in DV360 to instantly drop domains that fail ads.txt validation checks. For CTV campaigns, where app-ads.txt adoption varies and spoofing yields high CPM waste, maintaining rigid exclusion lists based on missing app-ads.txt files is non-negotiable.
Frequently Asked Questions
What is the difference between ads.txt and sellers.json?
Ads.txt is published by the content owner on their own website to declare who is authorized to sell their inventory. Sellers.json is published by the advertising exchange or SSP to list all accounts they do business with and pay out. Together, they provide a two-way verification mechanism to catch domain spoofing.
How can I automate sellers.json and ads.txt auditing in DV360?
You can use scripts to pull daily DV360 reporting data via the API, extract the transacting domains and publisher IDs, and cross-reference them against downloaded copies of exchange sellers.json files and publisher ads.txt parsers. Any mismatch between the declared seller ID and the authorized list triggers an automated alert or blocklist update.
What does a 'RESELLER' designation mean in ads.txt?
A reseller entry indicates that the publisher has authorized a third-party ad network, SSP, or managed service partner to sell their ad space on their behalf. While legitimate resellers are common, excessive reseller hops increase supply chain opacity and raise the risk of unauthorized domain spoofing.