OWNERDOMAIN and MANAGERDOMAIN in ads.txt Explained

Most publishers focus on the seller lines in their ads.txt — the SSP domain, account ID, relationship type. That's where the money is. But there are two variable declarations at the top of the file that affect how DSPs verify everything below them.

OWNERDOMAIN and MANAGERDOMAIN. Two lines. Most publishers either don't have them, have them wrong, or have them when they shouldn't.

Here's what each one does, when you need them, and what happens when they're misconfigured.

What OWNERDOMAIN Does

OWNERDOMAIN declares the domain of the entity that owns the website where ads appear.

The syntax is simple:

text
OWNERDOMAIN=example.com

In most cases, the owner domain is the same as the domain hosting the ads.txt file. If your ads.txt lives at publisher.com/ads.txt and publisher.com is the entity that owns the content and sells the ad inventory, you technically don't need OWNERDOMAIN. It's implied.

Where OWNERDOMAIN becomes essential:

Subdomains with separate ads.txt files. If news.publisher.com has its own ads.txt that's different from publisher.com/ads.txt, the subdomain's file should declare OWNERDOMAIN=publisher.com to tell DSPs that the parent entity controls this inventory.

Domain aliases and vanity domains. If your content lives on brand-name.com but your business entity operates under parent-company.com, OWNERDOMAIN connects the two for verification purposes.

White-label or hosted publisher platforms. If publishers run on your platform using subdomains (like publisher-name.yourplatform.com), each publisher's ads.txt should use OWNERDOMAIN to declare the actual publisher's domain.

When a DSP sees OWNERDOMAIN, it knows to look up that domain for additional verification context. If OWNERDOMAIN points to a domain that doesn't exist or doesn't have its own ads.txt, the DSP can't complete the verification chain.

What MANAGERDOMAIN Does

MANAGERDOMAIN declares the domain of the entity that manages the ads.txt file on behalf of the publisher.

text
MANAGERDOMAIN=admanager.com

This is for delegated management. When a publisher doesn't maintain their own ads.txt but instead has a third-party company manage it, MANAGERDOMAIN tells DSPs two things:

1. Someone other than the domain owner manages this file
2. The managing entity's own ads.txt (at admanager.com/ads.txt) contains the authoritative seller list

The flow works like this:

1. DSP fetches publisher.com/ads.txt
2. Sees MANAGERDOMAIN=admanager.com
3. Fetches admanager.com/ads.txt for additional context
4. Cross-references both files to build the complete authorization picture

When You Need MANAGERDOMAIN

Ad management companies. If you've hired a company to handle your programmatic operations and they control which SSPs appear in your ads.txt, declare their domain.

CMS platforms with built-in ad management. Some platforms generate ads.txt files for their publishers. The platform's domain should be declared as MANAGERDOMAIN.

Publisher networks. If a network manages monetization across multiple publisher sites, each site's ads.txt should reference the network's domain.

When You Don't Need MANAGERDOMAIN

If you manage your own ads.txt. This is the majority of publishers. You paste SSP lines yourself, you decide which partners to add or remove, you control the file. No MANAGERDOMAIN needed.

If your SSP account manager sent you lines to paste. That's not delegated management. You're still the one controlling the file. The SSP provided the data, but you made the decision to add it.

Adding MANAGERDOMAIN when it's not needed creates confusion. DSPs that check this field will try to fetch the manager's ads.txt and cross-reference it. If the manager domain doesn't have a proper ads.txt, or if the entries don't align, you've introduced a verification failure that didn't need to exist.

How DSPs Use These Fields

DSPs have been gradually tightening their verification processes. Here's how major platforms handle OWNERDOMAIN and MANAGERDOMAIN:

Google (DV360/AdX) actively crawls and uses both fields. Google's ads.txt crawler follows OWNERDOMAIN declarations to verify domain ownership chains. If OWNERDOMAIN points to a domain without a valid ads.txt, Google may flag the inventory.

The Trade Desk factors these fields into their supply path verification. OWNERDOMAIN helps them map complex publisher hierarchies where content appears on subdomains or partner domains.

General DSP behavior: Most major DSPs now parse these fields when present. The trend is toward stricter verification — fields that were once ignored are increasingly used for trust scoring.

The practical impact: a correct OWNERDOMAIN strengthens your verification signal. An incorrect one weakens it. And an unnecessary MANAGERDOMAIN pointing to an entity without proper ads.txt? That's worse than not having the field at all.

Common Mistakes

Setting OWNERDOMAIN to the Wrong Domain

The most common error. Publishers set OWNERDOMAIN to their parent company's corporate domain instead of the domain that actually owns the publishing entity. If your corporate parent is megacorp.com but your publishing brand operates independently as publisher.com, OWNERDOMAIN should be publisher.com.

The rule: OWNERDOMAIN should point to the domain of the entity that has the direct business relationship with the SSPs listed in the ads.txt file.

Adding MANAGERDOMAIN When Self-Managing

If you control your own ads.txt, don't add MANAGERDOMAIN. It's not a "nice to have." It actively changes how DSPs interpret your file. An unnecessary MANAGERDOMAIN declaration tells DSPs to go look at another domain's ads.txt, which may not align with yours.

Pointing MANAGERDOMAIN to an SSP

MANAGERDOMAIN is for the entity managing the file, not for the SSPs listed in it. Setting MANAGERDOMAIN=google.com because Google Ad Manager is your primary SSP is incorrect. Google isn't managing your ads.txt file. They're a seller listed in it.

Using HTTP Instead of the Root Domain

Both fields should be bare domains without protocol prefixes:

text
OWNERDOMAIN=publisher.com       (correct)
OWNERDOMAIN=https://publisher.com  (incorrect)
OWNERDOMAIN=www.publisher.com      (incorrect)

Not Having ads.txt on the Declared Domain

If you declare OWNERDOMAIN=parent.com, then parent.com/ads.txt needs to exist and be accessible. DSPs will try to fetch it. If it returns a 404, the verification chain breaks for every entry in your file.

How to Check Your Configuration

Step 1: Open your ads.txt file and look for OWNERDOMAIN and MANAGERDOMAIN lines near the top.

Step 2: If OWNERDOMAIN is present, verify that the declared domain has a valid, accessible ads.txt file.

Step 3: If MANAGERDOMAIN is present, verify that the manager's domain has a valid ads.txt and that the entries align with yours.

Step 4: If neither is present and you manage your own ads.txt on your primary domain, you're fine. No action needed.

Step 5: If you operate subdomains with separate ads.txt files, ensure each subdomain's file includes OWNERDOMAIN=yourrootdomain.com.

Run a full verification check on your domain to see how DSPs evaluate your OWNERDOMAIN and MANAGERDOMAIN configuration alongside your seller entries.

Frequently Asked Questions

Are OWNERDOMAIN and MANAGERDOMAIN required?

No. Both are optional per the IAB Tech Lab specification. But "optional" doesn't mean "irrelevant." DSPs that check these fields use them to strengthen or weaken their trust in your ads.txt entries. If you need them based on your setup, omitting them creates a verification gap.

Can I have multiple OWNERDOMAIN or MANAGERDOMAIN entries?

No. The specification allows only one of each per ads.txt file. If your situation involves multiple owners or managers, that's a signal your domain structure may need simplifying.

Does OWNERDOMAIN affect my revenue directly?

Not directly in the sense of a line item on your P&L. But incorrect OWNERDOMAIN can cause DSP verification failures, which means fewer bids, which means lower fill rates and CPMs. The impact is real — it's just invisible because DSPs don't tell you when they skip your inventory due to verification issues.

Should I add OWNERDOMAIN if I only have one domain?

Only if that domain is not the one hosting the ads.txt file. If you're a single-domain publisher with ads.txt at your root domain, OWNERDOMAIN is redundant. Adding it doesn't hurt, but it doesn't help either.

What's the difference between OWNERDOMAIN and the domain field in sellers.json?

OWNERDOMAIN in ads.txt declares who owns the publisher domain. The domain field in sellers.json declares the domain associated with a specific seller account on an SSP. DSPs cross-reference both: the ads.txt OWNERDOMAIN should align with the domain field in the SSP's sellers.json for your account.