> ## Documentation Index
> Fetch the complete documentation index at: https://docs.apostra.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Which domain is which

> Your account's registered domain, your brand domain, and your publisher domains do different jobs, and only one of them is the inventory you sell. How each is verified and what to do when verification stays pending.

Three different domains describe a seller. A small publisher has one domain doing
all three jobs, so they are easy to confuse. When they differ, for example after a
rebrand, for a holding company, or for a network that sells other people's sites,
the difference decides whether a storefront can go live.

| Domain | What it answers | Where it lives |
| - | - | - |
| **Registered domain** | Which account is this, and do we know you own it? | On your account, normally taken from the email you signed up with |
| **Brand domain** | Who is selling, commercially? | The seller's `operatorDomain`. Read it with `get({ "kind": "seller", "include": ["identity"] })`, set it with `save_seller`. |
| **Publisher domain** | What inventory is being sold? | The domains in your publisher coverage. Each domain's `adagents.json` says who may sell it. |

Only the third is inventory. A brand domain is never a product's coverage. See
[Publisher coverage](https://docs.apostra.com/v3/seller-publisher-coverage.md) for publisher domains and
[Identity documents](https://docs.apostra.com/v3/identity-documents.md) for `adagents.json` and `brand.json`.

An organization also claims the domain it operates as, and its buyer accounts take
that claim as their operator domain. Open the organization's Domains page with
`open_domains_page`; [Your organization's domain](https://docs.apostra.com/v2/buyer/account/tasks/organization-domains.md)
has the steps.

Every domain is held at the organization, so a buyer or agents account in an
organization does not type a registered domain of its own. It picks one of the
organization's verified domains, or none, in **Settings → Account configuration**,
and takes the organization's proof with it. A domain an account already holds
stays until it is cleared or replaced. A seller account keeps its own brand domain
until the organization's claims take it over in a later step.

### A worked example

Raptive runs a network and sells CafeMedia's sites.

* **Registered domain** `raptive.com`: the account was created by someone with a
  `@raptive.com` email.
* **Brand domain** `raptive.com`: Raptive is who the buyer deals with.
* **Publisher domains** `cafemedia.com`, `wholesomeyum.com` and others: the sites
  whose inventory is for sale, each with its own `adagents.json`.

Here the registered and brand domains match. That is the easy case, and it
verifies automatically. The rest of this page covers what happens when they do not.

## Why the brand domain must be verified

The brand domain is the seller's buyer-facing identity. Apostra reads the logo and
company description from it, and it is what a buyer sees they are dealing with, so
Apostra does not take it on assertion. An unverified brand domain blocks go-live. It
shows as the `operator_domain` check in the seller's
[setup checklist](https://docs.apostra.com/v3/seller-readiness.md) and stays a blocker until it resolves.

Verification depends on whether the brand domain matches the account's registered
domain.

### The brand domain matches the registered domain

The registered domain must be **approved**. An account administrator, or an
administrator of the organization that manages the account, can get there three
ways, for buyer, seller and organization accounts alike:

1. **An email on the domain.** An active member of the account has an email address
   at the registered domain. This needs nothing beyond signing in with that address.
2. **A DNS TXT record.** In your account's domain settings in the Apostra web app,
   choose **Verify with a DNS record**. Apostra shows a record name and value. Add
   that TXT record at your DNS provider, then choose **Check now**. Apostra reads
   the record straight from DNS, with no third party and no sign-in.
3. **A manual review.** Choose **Request manual review** and say why the first two
   do not fit, for example because you are an agency working for a client. An
   Apostra administrator reviews it and, if it holds up, attests the domain.

Starting a DNS check or a review happens in the web app's domain settings, not in a
V3 tool. Once the registered domain is approved, a brand domain equal to it
verifies automatically and the checklist updates right away, with no sync to wait
for.

#### The DNS record

The record sits at a dedicated host under your registered domain, so it does not
add to the TXT records at the domain's apex:

| Part | Value |
| - | - |
| Name | `_apostra-domain-verification.<your registered domain>` |
| Value | `apostra-domain-verification=<token>` |

The token is random and belongs to one account and one registered domain. If you
change the account's registered domain, Apostra issues a new token for the new
domain, and the old record does not verify it. Some DNS providers add the domain
for you, so enter the name as `_apostra-domain-verification` if yours does.

DNS changes can take a few minutes to appear. Until Apostra sees the exact value,
the check stays pending, whether the record is missing, wrong, or the lookup did
not finish. A check never approves a domain on a failed lookup. One account can run
a check about once every five seconds; a check made sooner is refused with
`RATE_LIMITED`. If the domain is already approved, for example by an email on the
domain, there is nothing to verify.

> [!NOTE]
>
> Verify via AAO is no longer offered. Its routes answer `410 Gone` and point to the
> DNS record and manual review. An approval made earlier through it stays valid.

If verification stays pending here, the account domain has not been approved yet.
That is what to chase, not the brand domain.

### The brand domain differs from the registered domain

This is the case that generates support requests. A seller registers as
`spanglishmovies.com` and sells as `latinxctv.com`. A company owns both `loopme.ai`
and `loopme.com`. Both are legitimate, and neither verifies on assertion. Two
conditions must hold, in order:

1. **The registered account domain is approved**, as above. Alias evidence is never a
   way around this. An unapproved account cannot verify any brand domain.
2. **Published evidence links the two domains.** Apostra reads each domain's
   `brand.json` through the AgenticAdvertising.org (AAO) registry and looks for one
   domain naming the other. It counts when either domain's `brand.json` lists the
   other in `authorized_operators`, names it as its `authoritative_location` or
   `house`, or lists it as one of its website properties.

> [!WARNING]
>
> A website redirect is not ownership proof. Pointing `old.com` at `new.com`, or
> serving the same site from both, verifies nothing. The evidence has to be a
> published claim in a `brand.json`, not server behavior.

A DNS record, an email address or a review for your registered domain does not prove
a different brand domain. Only the published link does.

Apostra cannot yet tell "no link is published" from "the lookup did not finish". Either
way the check stays pending, and the checklist says Apostra could not complete the
evidence check. If you have not published the link, publish or correct it in
`brand.json` at both domains. That is yours to do, because Apostra reads what you
publish. If you have published it and the check is still pending, it is waiting on
Apostra, and you can file that with `save_ask` rather than waiting.

## Change a brand domain

Saving a new brand domain with `save_seller` runs verification against it from
scratch, so expect the `operator_domain` check to go back to pending until the new
domain resolves. [Identity and brands](https://docs.apostra.com/v3/identity-setup.md#confirm-the-sellers-operator-and-follow-proof)
shows the preview and confirmation that a change needs.

* **Saving the same brand domain again re-runs nothing.** A brand domain that is
  already verified, including one an Apostra administrator attested, keeps its
  verification when you update other parts of the profile.
* **A lookup that fails counts as "not verified".** If the registry or `brand.json`
  lookup times out, the result is never "verified". A pending check after a change may
  only mean the lookup has not completed. The check runs again each time the
  storefront is read, so read it again to retry.
* **Withdrawing approval withdraws the verification.** If the account domain stops
  being approved, a brand domain that was verified through that approval goes back to
  pending. A verification an Apostra administrator attested directly stays.

## When it stays pending

Work down this list. Each step has a different owner.

1. **Is the account's registered domain approved?** Nothing else can succeed first.
   It needs a member email on the domain, a DNS TXT record Apostra has checked, or
   Apostra's attestation. The checklist says which can work for you. If no active
   member of the organization has an email address on the registered domain, email
   cannot work, so use the DNS TXT record or **Request manual review**. This is common
   when a company's people email from one domain and its brand lives on another.
2. **Does the brand domain match the registered domain?** If it does and it is still
   pending, the blocker is step 1.
3. **If it differs, is the linking evidence published?** Check that one domain's
   `brand.json` names the other. Redirects do not count.
4. **Evidence published and still pending?** It is with Apostra for review. File a
   request with `save_ask`.

## Related

* [Identity documents](https://docs.apostra.com/v3/identity-documents.md) explains `adagents.json`, `brand.json`
  and the AAO registry.
* [Identity and brands](https://docs.apostra.com/v3/identity-setup.md) covers setting and proving a domain in chat.
* [Publisher coverage](https://docs.apostra.com/v3/seller-publisher-coverage.md) covers publisher domains and
  properties.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.