Key Takeaways

• Domain spoofing is when fraudsters claim their inventory belongs to premium publishers. They falsify bid request data so DSPs think they're buying ads on CNN or ESPN when the ads actually run on worthless sites.
• ads.txt gives publishers a way to publicly declare their authorized sellers. A text file at yourdomain.com/ads.txt lists every SSP and account ID allowed to sell your inventory. Anything not on the list is unauthorized.
• DSPs check ads.txt before bidding. When a bid request comes in claiming to be from your domain, the DSP verifies that the SSP and account ID appear in your ads.txt. No match = likely spoofed = no bid.
• Over 90% of top 1,000 domains now publish ads.txt. The absence of an ads.txt file is itself a red flag for DSPs evaluating inventory quality.
• ads.txt alone doesn't eliminate spoofing. Fraudsters exploit gaps: copied files, stale reseller entries, and buyers who don't enforce verification. sellers.json and schain add necessary layers.
• Stale ads.txt entries are "prime masking spots" for fraud. Old SSP lines that no longer represent real relationships give fraudsters cover to inject unauthorized supply.

---

How ads.txt Prevents Domain Spoofing

Before ads.txt existed, a fraudster could spin up a website, fill it with scraped content, and tell DSPs the bid requests were coming from a premium publisher's domain.

The DSP had no way to verify the claim.

It would see "nytimes.com" in the bid request, check that the CPM looked right for a premium publisher, and bid on it. The ad served on a junk site. The fraudster pocketed the premium CPMs. The real publisher got nothing.

This was domain spoofing. And it was rampant.

The IAB Tech Lab launched ads.txt in May 2017 specifically to give publishers a tool to fight back. The concept was simple: publishers post a text file on their domain listing every company authorized to sell their inventory. DSPs crawl these files and use them to verify bid requests before placing bids.

It didn't eliminate spoofing entirely. But it fundamentally changed the economics of the fraud.

Here's how.

What Domain Spoofing Actually Is (And Why It Was So Easy)

Domain spoofing is a programmatic ad fraud technique where fraudsters falsify the domain field in bid requests. They claim their inventory belongs to a publisher it doesn't, tricking DSPs into paying premium prices for worthless impressions.

The mechanics are surprisingly straightforward.

In programmatic advertising, every bid request includes a domain field telling the DSP where the ad will appear. Before ads.txt, this field was self-reported. The SSP (or whoever generated the bid request) just put whatever domain they wanted in there. No verification. No checks.

That's it.

That was the whole exploit.

Fraudsters targeted major publishers like CNN, ESPN, and other high-CPM domains because the payoff was highest. A display ad on a premium news site might command $15-30 CPMs. The same ad on a content farm gets $0.10.

By spoofing the domain, fraudsters captured that premium spread on every impression.

For publishers, domain spoofing was a double hit:

• Lost revenue. Buyers who thought they were buying your inventory were actually buying from fraudsters. That demand never reached your actual ad server
• Damaged reputation. If an advertiser's brand safety tool flagged the spoofed impression (running on a junk site), they might associate the brand safety violation with your domain

And the publisher had zero visibility into it happening.

None.

How ads.txt Creates a Verification Layer

ads.txt works because it flips the trust model. Instead of trusting what the bid request claims, DSPs now verify the claim against a file the publisher controls.

Here's the exact verification flow:

1. Publisher creates ads.txt at their root domain (yourdomain.com/ads.txt)
2. The file lists every authorized seller: SSP domain, account ID, relationship type (DIRECT/RESELLER), and optional TAG-ID
3. DSPs crawl and cache ads.txt files from publisher domains (typically every 24-72 hours)
4. Bid request arrives at the DSP claiming to be from yourdomain.com, sent by SSP X with account ID 12345
5. DSP checks its cached copy of yourdomain.com/ads.txt for a matching entry
6. Match found? Bid proceeds normally
7. No match? DSP flags the request as potentially spoofed and can reject it

The critical insight: only the real domain owner can place a file at yourdomain.com/ads.txt.

A fraudster who spoofs your domain in a bid request can't modify the actual file on your server. So the verification is anchored to something the fraudster can't fake.

That's what makes ads.txt effective. It's not a fancy technical solution. It's a plain text authorization list hosted where only the legitimate publisher can put it.

Sometimes the simplest ideas work best.

Why Spoofing Got Harder (But Didn't Disappear)

ads.txt made basic domain spoofing dramatically more expensive to pull off. Over 90% of the top 1,000 domains now publish ads.txt, which means a fraudster trying to spoof any major publisher's domain will get caught by any DSP that bothers to check.

But fraudsters adapted.

They always do.

The current landscape of spoofing exploits the gaps in the system:

Targeting publishers without ads.txt. Smaller publishers who haven't implemented ads.txt are still vulnerable. If there's no file to check, the DSP has to decide whether to bid without verification. Some DSPs still will, and that's the opening.

Cloning ads.txt files. DoubleVerify documented cases where fraudsters copied a legitimate publisher's ads.txt onto their own junk domains. The file looks real because the entries are real. But the domain hosting the file isn't the publisher. DSPs that only check "does an ads.txt exist?" without cross-referencing sellers.json get fooled.

Exploiting stale reseller entries. This one is subtle and worth paying attention to. Publishers who leave old, unused SSP entries in their ads.txt create cover for fraud. A fraudster can use those stale account IDs in bid requests, and the DSP's verification will pass because the entry technically exists in the publisher's file.

Security researchers call stale entries "prime masking spots" for this exact reason.

CTV and mobile app spoofing. Domain spoofing has evolved beyond web. In connected TV and mobile apps, the verification is more complex because app-ads.txt has lower adoption than web ads.txt. Fraudsters exploit these gaps aggressively.

And right now, they're winning that particular battle.

The Three-Layer Defense: ads.txt + sellers.json + schain

ads.txt alone is a one-dimensional check. It confirms authorization but doesn't verify the complete supply chain.

That's why the IAB Tech Lab built two companion specs:

| Layer | What It Checks | Who Creates It |

|-------|---------------|----------------|

| ads.txt | Is this seller authorized by the publisher? | Publisher |

| sellers.json | Is this account actually who they claim to be? | SSP/Exchange |

| schain | What's the full path this impression took? | SSP (in bid request) |

Here's how they work together against spoofing:

A bid request arrives from SSP X claiming to be for publisher.com. The DSP checks publisher.com/ads.txt and finds SSP X with account ID 12345 listed as DIRECT.

Check one passes.

Then the DSP checks SSP X's sellers.json for account 12345. It finds the entry with seller_type: "PUBLISHER" and domain: "publisher.com".

Check two passes.

Finally, the DSP examines the schain object in the bid request, which shows the full supply chain path. If the chain is clean (publisher to SSP X to DSP), check three passes. If there are unexpected intermediaries or the chain doesn't match the ads.txt/sellers.json data, something's wrong.

A fraudster would need to compromise all three layers simultaneously to spoof successfully. That's orders of magnitude harder than just changing a domain string in a bid request.

Not impossible, but the economics stop working for most fraud operations at that point.

What Happens When Publishers Don't Maintain Their ads.txt

Here's the irony.

ads.txt was built to protect publishers, but publisher negligence is now one of the biggest remaining vulnerability vectors.

When publishers let their ads.txt files decay:

Stale entries create fraud surface area. Every old SSP line that no longer represents an active relationship is an entry a fraudster could use as cover. Remove what you don't use. It's that simple.

Missing entries hurt legitimate revenue. If you added a new SSP partner but forgot to update ads.txt, legitimate bid requests from that partner get flagged as unauthorized. You're essentially blocking your own demand. And you probably don't even know it.

Syntax errors disable entire lines. A missing comma or wrong field order means the DSP can't parse that line. The IAB Tech Lab has documented this as one of the "three deadly sins" of ads.txt.

No file is worse than a bad file. DSPs increasingly treat the absence of ads.txt as a disqualifying signal. If you don't have one, you're signaling either that you don't care about supply chain integrity or that you're not a real publisher.

Neither is great.

We see this pattern across 120K+ domains we monitor. The publishers who maintain their files month-over-month have measurably better verification scores and programmatic performance than those who set and forget.

How to Use ads.txt to Protect Your Domain

Step 1: Implement ads.txt if you haven't. Host it at your root domain, accessible via HTTP 200 at yourdomain.com/ads.txt. Plain text, no authentication required.

Step 2: List only active, verified sellers. Every SSP you currently work with, correct account ID, correct relationship type. Nothing more.

Step 3: Remove stale entries aggressively. If you stopped working with an SSP, remove their lines immediately. Don't leave dead entries as potential fraud vectors.

Step 4: Cross-verify against sellers.json. Your ads.txt entries should match what SSPs have in their sellers.json files. Mismatches mean broken verification. BeamFlow's free scan does this cross-check automatically.

Step 5: Monitor for unauthorized copies. Fraudsters sometimes clone your ads.txt onto their domains. Monitoring services can alert you when your entries appear on domains you don't own.

Step 6: Add OWNERDOMAIN and MANAGERDOMAIN. The ads.txt 1.1 spec added these variables to strengthen domain ownership verification. Use them.

Frequently Asked Questions

Does ads.txt completely prevent domain spoofing?

No. It significantly reduces basic domain spoofing by giving DSPs a verification mechanism. But sophisticated fraudsters can still exploit gaps: cloned files, stale entries, publishers without ads.txt, and buyers who don't enforce verification. ads.txt is a foundation, not a complete solution. Combine it with sellers.json verification and schain analysis for maximum protection.

What happens if I don't have an ads.txt file?

DSPs have no way to verify which SSPs are authorized to sell your inventory. This means fraudsters can spoof your domain freely, and many DSPs will either stop buying your inventory entirely or significantly reduce spend as a precaution. Implementing ads.txt is the minimum standard for programmatic trust.

Can fraudsters copy my ads.txt file?

Yes, they can copy the contents of your ads.txt onto their own domain. But this exploit falls apart when DSPs also check sellers.json, because the SSP's sellers.json will show your domain (not the fraudster's) as the authorized publisher for those account IDs. This is why the three-layer defense (ads.txt + sellers.json + schain) matters so much.

How do DSPs handle bid requests from domains without ads.txt?

Policies vary by DSP. Some will still bid but at lower rates. Others block all inventory from domains without ads.txt entirely. Google's DV360 and most major DSPs strongly prefer (and increasingly require) ads.txt verification. The trend is toward stricter enforcement, not looser.

Does ads.txt protect against all types of ad fraud?

No. ads.txt specifically targets unauthorized inventory selling and domain spoofing. It doesn't protect against bot traffic, click fraud, ad stacking, pixel stuffing, or other fraud types. Those require different detection methods like IVT (Invalid Traffic) filtering and bot detection. Different problems, different tools.