ads.txt Verification Status: Verified, Unverified, Mismatch, Indeterminate
DSPs don't just check if your ads.txt exists. They verify every entry against sellers.json. The result is one of four statuses. Here's what each means for your revenue.

ads.txt Verification Status: What Each One Means
When you look at your ads.txt, you see a list of SSPs and account IDs. When a DSP looks at it, they see verification statuses.
Every line in your file gets checked. The DSP fetches your ads.txt, then fetches the sellers.json file from each SSP you've listed, and cross-references the data. The result of that cross-reference is a verification status that directly affects whether the DSP bids on your inventory through that path.
Understanding these statuses matters because they're the language DSPs use to make spending decisions. A file full of "Verified" entries gets premium treatment. A file full of "Mismatches" gets deprioritized or blocked.
Here's what each status means, what causes it, and how to fix it.
Verified
What it means: Complete supply chain verification passed.
The DSP checked your ads.txt entry against the SSP's sellers.json and everything aligned:
- The SSP domain in your ads.txt has an accessible sellers.json file
- Your account ID appears in that sellers.json
- The seller_type in sellers.json matches the relationship type in your ads.txt (DIRECT maps to PUBLISHER, RESELLER maps to INTERMEDIARY)
- The domain field in sellers.json matches your publisher domain
This is the gold standard. A Verified entry tells the DSP: this publisher explicitly authorized this SSP, and the SSP confirms the relationship. Bid with confidence.
Revenue impact: Verified entries receive the most competitive bids. DSPs running supply path optimization prioritize verified paths. When multiple SSPs can reach the same impression, the verified path wins.
What to do: Nothing. This is working correctly. Monitor it to make sure it stays verified — SSPs can change their sellers.json at any time, and a verified entry today can become unverified tomorrow without warning.
Unverified
What it means: The verification chain is incomplete.
The DSP tried to verify the entry but couldn't complete the process. Common causes:
SSP Has No sellers.json
The SSP domain in your ads.txt doesn't host a sellers.json file at all. The DSP fetched https://ssp-domain.com/sellers.json and got a 404. Without sellers.json, the DSP can verify that you authorized this SSP (via ads.txt) but can't verify the SSP's side of the relationship.
This affects all your entries for that SSP, not just one.
Account ID Not in sellers.json
The SSP has sellers.json, but your specific account ID doesn't appear in it. The file exists, but your entry is missing. This usually means:
- You have the wrong account ID in your ads.txt
- You're a new account and the SSP hasn't updated their sellers.json yet
- The SSP removed your account (intentionally or accidentally)
Confidential Entry
Your account ID exists in the SSP's sellers.json, but it's marked as is_confidential: 1. The DSP can see that the ID exists but can't verify the name, domain, or seller_type. This is a partial verification — better than missing entirely, but worse than full transparency.
Revenue impact: Unverified entries still receive bids from many DSPs, but at lower priority. Some DSPs discount CPMs for unverified paths. Others, especially those with strict supply chain requirements, may skip them entirely. BeamFlow's analysis across 220K+ domains shows that unverified entries consistently underperform verified ones in auction competitiveness.
What to do: Identify the specific cause for each unverified entry. If the SSP has no sellers.json, that's on them — contact your SSP representative. If your ID is missing, verify you have the correct account ID and that your account is active. If the entry is confidential, ask the SSP to make your entry non-confidential.
Mismatch
What it means: The data in your ads.txt conflicts with the data in the SSP's sellers.json.
This is the most damaging status. The DSP found your entry in the SSP's sellers.json, but the details don't align. Common mismatches:
Relationship Type Mismatch
Your ads.txt says DIRECT but the SSP's sellers.json lists your account as seller_type INTERMEDIARY. Or your ads.txt says RESELLER but sellers.json says PUBLISHER.
This is the most common mismatch. It happens when:
- You copied a RESELLER line from an SSP but actually have a direct account
- The SSP miscategorized your account in their sellers.json
- You set up through a reseller but labeled the entry as DIRECT
Domain Mismatch
The SSP's sellers.json lists a different domain for your account than your actual publisher domain. This happens when:
- You rebranded or changed domains
- The SSP has an old domain on file
- The wrong domain was entered during SSP onboarding
Name Mismatch
Less critical for automated verification, but the business name in sellers.json doesn't match the entity operating your domain. This can indicate an account ownership issue.
Revenue impact: Mismatches are actively penalized. DSPs treat mismatches as trust failures — the publisher claims one thing, the SSP says another. This triggers fraud detection heuristics in some DSPs. Even when it's an honest mistake, the DSP can't distinguish a typo from a spoofing attempt. The bid request may be rejected outright.
From what we see across our data, mismatched entries can reduce bid rates by 30-60% compared to verified entries for the same inventory. That's significant revenue left on the table.
What to do: Fix these immediately. Mismatches are the highest-impact issue in your ads.txt.
For relationship type mismatches: confirm with the SSP whether you're a direct publisher or going through a reseller. Update your ads.txt to match what the SSP has in their sellers.json. If the SSP's categorization is wrong, ask them to update sellers.json.
For domain mismatches: contact the SSP to update the domain field in their sellers.json to match your current publisher domain.
Indeterminate
What it means: Verification couldn't complete, but not because of a definitive failure.
Indeterminate is a temporary or ambiguous state. The DSP attempted verification but the result was inconclusive:
sellers.json Temporarily Unavailable
The SSP's server was down, returned an error, or timed out when the DSP tried to fetch sellers.json. The file may exist and be perfectly fine — it just wasn't accessible at the moment of verification.
sellers.json Parse Error
The SSP's file exists but contains formatting errors that prevent parsing. The DSP can't extract the data it needs to verify your entry.
Rate Limiting
Some SSPs rate-limit requests to their sellers.json. If the DSP's crawler was throttled, verification couldn't complete.
Revenue impact: Minimal if temporary. DSPs typically cache previous verification results, so a brief sellers.json outage doesn't immediately change your status. If the indeterminate state persists across multiple crawl cycles, it effectively becomes "Unverified" in the DSP's evaluation.
What to do: Check if the SSP's sellers.json is accessible by visiting https://ssp-domain.com/sellers.json directly. If the file loads normally, the issue was temporary and will resolve on the DSP's next crawl. If the file consistently fails to load, treat it as an Exchange Not Found issue and follow the diagnostic steps.
The Revenue Gap Between Statuses
The difference between verification statuses isn't academic. It maps directly to auction behavior.
A simplified view of how DSPs treat each status:
Status | DSP Behavior | Bid Impact
Verified | Full confidence, competitive bidding | Baseline (highest)
Unverified | Reduced confidence, conservative bidding | 10-30% lower CPMs
Mismatch | Trust failure, often rejected | 30-60% lower CPMs or blocked
Indeterminate | Cautious, uses cached data | Varies by DSP policy
These numbers aren't uniform across all DSPs — they vary by platform, campaign settings, and advertiser preferences. But the direction is consistent: verification status directly correlates with bid aggressiveness.
How to Check Your Verification Status
Your SSP dashboard won't show you this. SSPs don't cross-reference their own sellers.json against your ads.txt for you. And DSPs don't publish their verification results.
This is the gap. You can't see how DSPs evaluate your entries unless you run the same cross-reference they do.
BeamFlow's scanner runs this exact check: it fetches your ads.txt, fetches sellers.json from every SSP you've listed, and reports the verification status for each entry. You see what DSPs see.
Frequently Asked Questions
Can a Verified entry become Unverified without me changing anything?
Yes. If the SSP updates their sellers.json — removes your account, changes your seller_type, or marks you as confidential — your status changes even though your ads.txt is identical. This is why continuous monitoring matters. One-time audits miss these changes.
Do all DSPs check verification status the same way?
No. Major DSPs like Google and The Trade Desk run comprehensive cross-verification. Smaller DSPs may only check basic ads.txt presence without cross-referencing sellers.json. The industry trend is toward more thorough verification.
How quickly do verification status changes take effect?
DSPs re-crawl ads.txt and sellers.json every 24-72 hours. After you fix a mismatch or an SSP updates their sellers.json, expect 1-3 days before DSPs pick up the change. Some changes propagate faster for high-volume publishers that DSPs crawl more frequently.
Is it possible to have all entries Verified?
Achievable but rare. It requires every SSP you work with to maintain an accurate, up-to-date sellers.json with your correct account details. The industry-wide stat is sobering: 24% of ads.txt entries fail sellers.json verification. A realistic goal is getting 80%+ verified and fixing all mismatches.
What should I prioritize fixing first?
Mismatches first — they're actively penalized. Then Unverified entries where the cause is a wrong account ID (quick fix). Then Unverified entries where the SSP lacks sellers.json (requires SSP action, longer timeline).
Related Articles

Delegated vs. Direct ads.txt Hosting: Which Is Right for You?
Should you manage your own ads.txt or let someone else handle it? Direct hosting gives you control. Delegated hosting gives you convenience. Here's how to choose.

TAG Certification and the TAG-ID (CAID) Field in ads.txt
TAG-certified sellers get preferential treatment from DSPs. The TAG-ID field in ads.txt proves certification status at the entry level. Here's how it works.

OWNERDOMAIN and MANAGERDOMAIN in ads.txt Explained
Two ads.txt variables that most publishers ignore. OWNERDOMAIN declares domain ownership. MANAGERDOMAIN declares who manages the file. Both affect how DSPs verify your supply chain.
Ready to optimize your ads.txt?
Check your domain's supply chain health instantly, free.
Check Your Domain Free