Why exchanges reject publishers — what supply vetting actually checks

Rejection emails from exchanges are famously uninformative. “We’re unable to onboard your inventory at this time” tells you nothing about which of a dozen possible checks you failed, or whether it’s fixable in an afternoon.

The vagueness is deliberate — publishing the exact thresholds would be publishing the evasion manual. But the categories aren’t secret, and most declines come down to four of them.

Why vetting exists at all

When an exchange accepts your inventory, it inherits your risk. It will represent your inventory to buyers, vouch for it in sellers.json, and carry the consequences if it turns out to be misrepresented. A single bad publisher can get an exchange throttled or delisted across multiple DSPs.

So vetting isn’t gatekeeping for its own sake. It’s the exchange asking: if I put my name on this, what am I signing up for? Understanding it that way makes the checks predictable.

Ownership: can we prove the site is yours?

The first check is the most basic, and a surprising number of applications fail it.

• Does your ads.txt authorise us? Adding the exchange’s line is the standard proof of control, because only someone with write access to the domain can do it. If the file isn’t there, isn’t fetchable, or doesn’t contain the line, there’s nothing to verify against.
• Does the corporate entity match? The company on the application should have a plausible relationship to the domain’s registration and the site’s stated publisher.
• Is the same inventory already onboarded through someone else? If your domain is already being sold by three parties, an exchange will want to understand why before adding a fourth.

Most ownership failures are administrative. They’re also the easiest to fix — often literally by correcting the file.

Traffic: where does it come from?

This is where most genuine declines happen.

• Sourced or purchased traffic. Buying traffic isn’t inherently illegitimate — plenty of legitimate publishers do it. Undisclosed sourced traffic is the problem, because it changes what a buyer is bidding on. Declare it up front and you’ll be assessed on it; hide it and you’ll be declined for it.
• Traffic shape. Sudden step-changes in volume, traffic concentrated in unusual hours, or a geographic mix that doesn’t match the content are all signals worth explaining before someone else interprets them.
• Technical fingerprints. Datacenter IP ranges, implausible session patterns, and known invalid traffic signatures are checked automatically and are rarely arguable.

The recurring theme: exchanges are far more tolerant of unusual traffic that was disclosed than of ordinary traffic that wasn’t.

Declarations: do your files agree?

• Is ads.txt present, fetchable at the root, and served as plain text?
• Do your DIRECT lines correspond to sellers.json entries that say PUBLISHER? Claims that don’t corroborate look like misrepresentation whether or not they are.
• Is OWNERDOMAIN declared, so ownership is unambiguous where a sales house is involved?

Content and the MFA question

Illegal, infringing, and adult content are obvious exclusions. The harder category is made-for-advertising characteristics: very high ad density, thin or templated content, low dwell time, heavy paid acquisition, aggressive refresh.

MFA is a spectrum, not a binary, and plenty of ordinary sites sit uncomfortably close to the line during a redesign or a traffic experiment. If your ad-to-content ratio is high for a defensible reason, say so in the application rather than letting it be inferred.

If you’re declined

• Ask for the category, not the threshold. Most partners will tell you whether it was ownership, traffic, declarations, or content, even if they won’t share the specific number.
• Fix and reapply. Declines are rarely permanent, and ownership or declaration failures can often be resolved the same week.
• Don’t route around it via a reseller. If an exchange declined your inventory directly, reaching them through an intermediary tends to be discovered, tends to be treated as evasion, and creates the duplicate path problem on top.

The takeaway

Supply vetting checks four things: whether you can prove you control the domain, where your traffic comes from and whether you disclosed it, whether your ads.txt and the corresponding sellers.json tell the same story, and whether your content and ad density sit on the right side of the MFA line. Ownership and declaration problems are usually clerical and quick to fix. Traffic problems are usually about disclosure rather than the traffic itself — the fastest route through vetting is to explain the unusual thing before anyone has to ask.

---

Lumorrow verifies publishers directly and tells you what needs fixing rather than declining silently. Start the publisher application →