Do I need OWNERDOMAIN if my ads.txt is already on my own domain?

Yes. IAB Tech Lab recommends declaring OWNERDOMAIN on every ads.txt file even when it matches the domain that hosts the file, because buyers match it against the domain field in each seller's sellers.json entry. Without it, that match is a guess.

Can I have more than one MANAGERDOMAIN line?

Yes, one per country, written as MANAGERDOMAIN=manager.example, US. Without a country code the line means the manager handles the whole site, and the spec allows only one such line. Two uncoded MANAGERDOMAIN lines is an error.

How quickly do buyers pick up a changed ads.txt?

Most exchanges and DSPs crawl ads.txt daily; a few re-crawl within hours and a few take longer. A line you remove at 09:00 can take demand away by the afternoon, so a change you did not intend costs at least a day. Keep a copy of the last good file and compare before you publish.

ads.txt 1.1 explained, with the OWNERDOMAIN and MANAGERDOMAIN mistakes that cost you demand

ads.txt 1.1 added two lines to the file: OWNERDOMAIN, which names the business that owns the site, and MANAGERDOMAIN, which names a company that sells the site's inventory on the owner's behalf. Buyers read both and compare them with the sellers.json files that exchanges publish. When the names do not line up, some buyers treat the inventory as unverified and bid less, or not at all. The spec is from August 2022. Enforcement by buyers is what changed, and it has been tightening through 2025 and 2026.

If your file still looks the way it did in 2021, this is the hour to fix it.

What the two lines mean

Every seller line in ads.txt says "this exchange may sell my inventory under this account ID". Version 1.1 adds context about who "my" is.

OWNERDOMAIN is the domain of the business that owns the site. It should match the domain field in your entry in each exchange's sellers.json. For a site that monetises itself, it is simply the site's own domain, written once:

OWNERDOMAIN=example-news.com

MANAGERDOMAIN is for the case where another company handles your monetisation: a sales house, a network, a managed-service partner. It names that company, and it can carry a country code when different partners manage different markets:

MANAGERDOMAIN=salespartner.com, US
MANAGERDOMAIN=otherpartner.fr, FR

Both lines go at the top of the file, after any comments. One OWNERDOMAIN. One MANAGERDOMAIN without a country code, or several with codes.

What buyers do with them

A DSP looking at a bid request walks the supply chain object, finds the seller IDs, and looks each one up in the exchange's sellers.json. The sellers.json entry says whether that ID is a PUBLISHER (sells its own inventory) or an INTERMEDIARY, and gives the seller's domain. The buyer then opens your ads.txt and asks:

Is this exchange and this seller ID listed? (The classic ads.txt check.)
Does the seller's domain in sellers.json match your OWNERDOMAIN, or one of your MANAGERDOMAIN lines?

When the second check fails, the inventory is not fraud, but it is not verifiably yours either. Some buyers downgrade it. Some skip it. You see neither decision; you see fewer bids on some exchanges and a slow slide in CPM that does not match any change you made.

The five mistakes we see most

1. No OWNERDOMAIN at all. Still the most common state. The file validates, everything "works", and the owner match is left to the buyer's guess. Add the line. It costs nothing.

2. OWNERDOMAIN that does not match sellers.json. Your exchange account was opened by a parent company, or under a trading name, or under an old domain. The domain field in sellers.json says holdingco.com; your ads.txt says example-news.com. Ask the exchange to update the sellers.json entry, or declare the owner the way the exchange knows you. Pick one spelling and use it everywhere.

3. MANAGERDOMAIN missing when a partner sells for you. The partner's seller ID is in your ads.txt as an INTERMEDIARY line, but nothing says they manage the site. Buyers that want to see the manager relationship do not find it.

4. Two MANAGERDOMAIN lines without country codes. Only one uncoded line is allowed. The second one is a spec error, and tools that validate strictly will flag the whole file.

5. The lines in the wrong place, or with comments after them. Put them at the top, one per line, nothing trailing. Some parsers are forgiving; the ones that are not are the ones you cannot see.

A working example

# ads.txt for example-news.com, last reviewed 2026-10-11
OWNERDOMAIN=example-news.com
MANAGERDOMAIN=salespartner.com, US
google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0
rubiconproject.com, 00000, DIRECT, 0bfd66d529a55807
appnexus.com, 0000, RESELLER, f5ab79cb980f11d1

Keep the comment with the date. The person who edits this file in March will thank the person who dated it in October.

How to check your own file in five minutes

Fetch https://yoursite.com/ads.txt in a private window. Confirm it returns 200 with content type text/plain. A 404, a redirect to the homepage, or an HTML error page counts as "no file" to a crawler.
Look for OWNERDOMAIN at the top. Add it if it is missing.
For each exchange where you have a direct account, open that exchange's sellers.json and find your seller ID. Compare the domain field with your OWNERDOMAIN. Note every mismatch.
If a partner manages your monetisation, add MANAGERDOMAIN, with country codes if the arrangement differs by market.
Save a copy of the file. Next time you compare, this is the baseline.

Step 5 is the one that pays off. Most ads.txt damage is not a wrong line written on purpose; it is a deploy that overwrote the file, a CMS plugin that regenerated it, or a colleague who removed "an old line" that a demand partner required. PubPilot fetches your ads.txt on a schedule, validates it against the spec, checks that the lines you mark as required are still there, and sends you the difference when the file changes, so a missing OWNERDOMAIN or a vanished partner line reaches you the same day, not when the invoices come in.