← AEO Record Standard
aeorecord.org / What is the AEO Record Standard?
DEFINITION · v=AEO1

What is the AEO Record Standard?

A plain definition of v=AEO1, what it proves, and where it sits relative to everything else a domain already publishes.
Published 2026-08-02  ·  Specification v0.2  ·  aeorecord.org

The AEO Record Standard (v=AEO1) is an open specification for a DNS TXT record, published at _aeo.<domain>, that declares whether a verified, machine-readable fact catalog exists for that domain and where to find it. It is a discovery and provenance convention for the AI answer layer — the same shape as v=spf1 or v=DMARC1 in email, applied to the question of which facts about a domain an AI engine or agent can rely on.

It is aimed at three audiences: domain owners who want the facts about their business to reach answer engines from an authorized source, AI engines and agents that want a cheap, authoritative place to look before grounding an answer, and tool builders who want to read or verify records in their own software. The specification is open and free to implement; the current revision is v0.2, first published 2026-06-29.

On this page
  1. The short definition
  2. Anatomy of a record
  3. What the standard proves
  4. How a record is discovered
  5. The four tiers
  6. Who maintains it
  7. Standards status
  8. How to publish one
  9. Frequently asked questions

The short definition

Three sentences, for anyone who needs to quote it:

v=AEO1 is an open, DNS-anchored standard for declaring a verified fact catalog for a domain. The domain owner publishes a short TXT record at _aeo.<domain> naming the catalog URL, a verification tier, an issuance date, and — on issued tiers — an Ed25519 signature over the published facts.

Any engine, agent, or tool can resolve that record and know two things without trusting the page it is reading: the statement came from whoever controls the domain, and the facts have not been altered since they were signed.

Anatomy of a record

A record is a single line of text. Here is the full grammar in practice:

_aeo.example.com. IN TXT "v=AEO1; id=grd_TOKEN; catalog=https://groundedaeo.com/c/example.com; tier=verified; ts=20260729; sig=BASE64URL"
TagMeaning
v=AEO1Version tag. Marks the record as belonging to this convention so parsers can ignore unrelated TXT records on the same name.
catalog=The URL of the canonical, structured fact catalog for the domain.
tier=The declared verification depth: self_declared, listed, verified or grounded.
ts=The issuance date, YYYYMMDD. Normatively a tenure date — consumers must not read its age alone as staleness.
id=An issuer token in grd_ form, present only on issued tiers. Self-declared records simply omit it.
sig=A base64url Ed25519 signature over AEO1|domain|tier|ts|facts_hash, present on paid tiers. The public key is discovered from the catalog origin at /.well-known/aeo-public-key.json.

The full tag reference, ABNF grammar and JSON Schema live on the specification page.

What the standard proves — and what it leaves to others

The value of the record comes from two properties, and both have clean edges.

Domain control

Publishing anything at _aeo.<domain> requires access to that domain’s DNS. So a record is not merely data — it is a statement that only the domain holder could have made. That is the same property SPF, DKIM and DMARC rest on, and it is the foundation the rest of AEO1 builds on. Background: what a DNS TXT record is and what it proves.

Fact integrity

On signed tiers, the Ed25519 signature covers a canonical hash of the published fact set — NFC-normalised, codepoint-ordered {fact_type, key, value} triples. Change a single fact and the signature stops verifying. A consumer therefore learns not just who declared the facts but that the facts in hand are byte-for-byte the ones that were declared. Key rotation is part of the model: keys marked retired still verify older signatures, and keys marked revoked must be skipped entirely.

A record attests provenance, integrity and corroboration depth as of a stated date. It does not warrant that a fact is true in the world, and it does not warrant that a fact stays true afterwards. That boundary is stated deliberately and in full in the published verification methodology — the split every credential ecosystem uses between who declared what, and whether the claim itself holds.

How a record is discovered

Because crawler capabilities differ, the standard defines an ordered discovery hierarchy. A consumer works down the list and stops at the first hit:

  1. <link rel="aeo" href="/.well-known/aeo.json"> in the page head — an explicit advertisement any HTML crawler already sees.
  2. /.well-known/aeo.json — the crawl-time bridge, carrying the same claims over ordinary HTTPS with no DNS lookup. It follows the RFC 8615 well-known-URI convention.
  3. _aeo.<domain> TXT — the authoritative DNS record.
  4. A pointer inside llms.txt, for crawlers already reading that file.
  5. An MCP directory entry, for agent builders installing tools.
  6. An ordinary HTML crawl — the last resort, and the unverified one.

The practical effect is that a domain gets useful behaviour from step 2 on day one, with steps 1 and 3 strengthening the signal as consumers mature.

The four tiers

A tier is a declaration of how much checking stands behind the catalog. Each higher tier is a strict superset of the one below.

TierWhat it says
self_declaredThe owner published this themselves. Free, no token, no signature, no account — the same trust level as an llms.txt file, and a perfectly valid record.
listedProvenance plus domain control, with a catalog published. No fact review.
verifiedAuthentic, owner-attested, and checked by human review or at least one independent source as of a stated date.
groundedEverything in verified, plus agreement across two or more independent sources, and signed. The highest diligence claim the standard makes.

Anyone may publish a self_declared record for free. Issued tiers carry a grd_ token from the record authority, which checks domain ownership before issuing; self-generated tokens are invalid by definition. The complete check-by-check breakdown is in the methodology.

Who maintains the standard

The specification is authored by Garrett Miller and maintained through Grounded AEO / Meadow Mountain AI LLC, and it is open: the format, the grammar, the JSON Schema and the reference verifier are all public, and anyone may read, check or implement records without permission or payment. The aeo-record npm package (current line 0.3.x) is an open, zero-dependency checker — npx aeo-record example.com resolves and verifies any domain’s record from a terminal.

One thing is reserved rather than open: the issuance of grd_ tokens for the paid tiers, which is what makes an issued tier mean anything. Grounded AEO is the first implementer and currently the only issuing authority. Reading, verifying and self-declaring stay free and unowned.

Standards status — stated precisely

The specification was filed with the IETF as an Internet-Draft on 2026-07-18: draft-miller-aeo-00, “The AEO1 Discovery Mechanism”, an Individual Submission on the Informational track. An Internet-Draft is a published, permanently citable working document. It is not an endorsed or approved standard, and filing one confers no IETF endorsement — the distinction matters, and this site states it everywhere rather than blurring it.

Likewise, the aeo.json well-known URI is not currently entered in the IANA well-known-URIs registry; the record works today because the path is served and read directly, and formal registration is being pursued through the standards process rather than claimed in advance.

Adoption is early and stated as such. The standard was first published on 2026-06-29, and no DNS-layer standard for AI citation verification existed before it. The honest position: publishing a record today is an early-mover posture — a domain that starts accruing tenure and a signed refresh history now holds exactly the signal that becomes valuable as consumers begin checking at scale.

How to publish a record

  1. Decide the tier. self_declared needs nothing but a text editor and DNS access.
  2. Publish the TXT record at _aeo.<yourdomain> with at minimum v, catalog, tier and ts.
  3. Serve the same claims at /.well-known/aeo.json so crawlers that never resolve DNS still find them.
  4. Add <link rel="aeo" href="/.well-known/aeo.json"> to your homepage head.
  5. Check your own work: npx aeo-record yourdomain.com.

A no-account generator for a valid self-declared record is available free at groundedaeo.com/free-record. If you would rather see how your domain reads to an engine first, the free audit scores it. And if you are weighing this against the other things a site can publish, the alternatives comparison lays them side by side, including where they do the job better.


Frequently asked questions

What is the AEO Record Standard?

The AEO Record Standard, identified by the tag v=AEO1, is an open specification for a DNS TXT record published at _aeo.<domain> that declares whether a verified, machine-readable fact catalog exists for that domain and where to find it. It is a discovery and provenance convention for AI answer engines, built on the same DNS mechanism that SPF, DKIM and DMARC use for email.

What does AEO stand for?

Answer Engine Optimization — the practice of making a site's information usable and citable by AI answer engines rather than only rankable in a list of links. The AEO Record Standard addresses one specific part of that: giving engines an authorized, verifiable place to read a domain's facts.

Who is the AEO Record Standard for?

Three groups. Domain owners who want the facts about their business to reach answer engines from a source the owner authorized. AI engines and agents that want a cheap, authoritative check before grounding an answer on a domain's data. And tool builders who want to read or verify records inside their own software, which the specification explicitly permits.

Is the AEO Record Standard open?

Yes. The record format, the ABNF grammar, the JSON Schema and the reference verifier are all published, and anyone may read, check, or implement records without permission or payment. The one reserved element is the issuance of grd_ tokens for the paid verification tiers, since an issued tier only means something if a single authority stands behind it. Self-declared records need no token at all.

What does a v=AEO1 record actually prove?

Two things with clean edges. Domain control, because publishing at _aeo.<domain> requires access to that domain's DNS. And fact integrity on signed tiers, because the Ed25519 signature covers a canonical hash of the published facts, so any edit breaks verification. It does not warrant that a fact is true in the world, and the published methodology states that boundary explicitly.

Is it free to publish a record?

Yes. A self-declared record is free, needs no account and no token, and is a fully valid record under the specification — it simply sits at the lowest trust tier, the same level as an llms.txt file. A no-account generator is available at groundedaeo.com/free-record. The paid tiers add issuer verification, corroboration and a signature.

Is v=AEO1 an IETF standard?

No, and the distinction is stated deliberately. It was filed with the IETF as an Internet-Draft on 2026-07-18 — draft-miller-aeo-00, an Individual Submission on the Informational track. An Internet-Draft is a published, permanently citable working document, not an endorsed or approved standard, and filing one carries no IETF endorsement.

Do AI engines check these records today?

Adoption is early and the specification says so rather than implying otherwise. It was first published on 2026-06-29, and no DNS-layer standard for AI citation verification existed before it. The case for publishing now is tenure: a domain that starts accruing a stable, signed refresh history holds exactly the signal that gains weight as consumers begin checking at scale.

How does it relate to llms.txt and schema.org?

They compose rather than compete. schema.org describes facts inside a page, llms.txt indexes content at the file level, and v=AEO1 sits at the DNS and well-known layer declaring which catalog is authoritative and proving who authorized it. The discovery hierarchy in the specification includes an llms.txt pointer as one route to the record. A side-by-side comparison is on the alternatives page.

How do I check a domain's record?

Three interchangeable ways. Run npx aeo-record yourdomain.com using the open npm checker. Resolve the TXT record at _aeo.yourdomain.com directly with dig or nslookup, or over DNS-over-HTTPS. Or fetch https://yourdomain.com/.well-known/aeo.json, the crawl-time bridge that carries the same claims without any DNS lookup.

What is the current version of the specification?

Version 0.2, published 2026-07-06, superseding v0.1 of 2026-06-29. That revision made key revocation normative, removed the unused method= DNS tag, aligned roughly a dozen details with the reference implementation, added the ABNF grammar and JSON Schema, defined the link rel="aeo" discovery convention, and separated tenure from freshness across three distinct dates. The full changelog is on the specification page.