Most of DNS maps names to addresses: ask for a hostname, get back an IP. A TXT record does something different — it lets the owner of a domain publish a short piece of free text that anyone in the world can look up.
That sounds unremarkable until you notice what it implies. Publishing under a domain requires control of that domain’s DNS. So a TXT record is not just storage: it is a statement that could only have been made by whoever holds the domain. Nearly every practical use follows from that one property.
A single domain can carry many unrelated TXT records, so each convention marks its own. v=spf1, v=DMARC1 and v=AEO1 all exist for the same reason: a parser reads the opening tag, recognises whether the record belongs to it, and ignores the rest. Without that, coexisting conventions would have no way to tell each other apart.
Placement follows a similar convention. SPF sits on the domain itself; DMARC lives at _dmarc.example.com; an AEO1 record lives at _aeo.example.com. The leading underscore marks a name reserved for machines rather than for a website.
dig TXT example.comnslookup -type=TXT example.comdig TXT _aeo.example.comIt proves control. Someone with access to the domain’s DNS published that text. For domain verification, that is the whole job and it does it well.
It does not prove the text is accurate. A domain owner can publish anything they like, and the record itself carries no evidence for the claim inside it. It also carries no expiry — a record stays live until changed, and a TTL only governs caching, not validity.
Those two gaps are why some conventions go further. Signing the content cryptographically means the record proves origin and integrity rather than origin alone; carrying a date inside the record lets consumers reason about freshness explicitly instead of inferring it from the DNS layer. The v=AEO1 standard does both, and its published methodology states precisely which of those a verification tier attests — and which it deliberately does not.
A TXT record is a DNS entry that stores arbitrary text against a domain name. DNS mostly maps names to addresses; a TXT record instead lets the domain owner publish a short piece of text that anyone can look up. Because only the domain owner can publish it, a TXT record doubles as proof of control over that domain.
Mostly for proving things about a domain. Email authentication is the largest use - SPF, DKIM and DMARC are all TXT records - and services routinely ask you to add one to verify you own a domain before enabling a feature. The v=AEO1 record uses the same mechanism to declare that a verified fact catalog exists for the domain.
Query DNS directly. On macOS or Linux, dig TXT example.com; on Windows, nslookup -type=TXT example.com. If a local resolver is unavailable or filtered, a DNS-over-HTTPS endpoint returns the same answer over an ordinary HTTPS request.
Because a single domain can hold many unrelated TXT records, so each convention marks its own with a version tag at the start. A parser reads the tag, recognises whether the record belongs to it, and ignores everything else. It is what allows SPF, DMARC and AEO1 records to coexist on one domain without interfering.
Either, and the choice is part of the convention. SPF sits on the domain itself; DMARC lives at _dmarc.example.com; a v=AEO1 record lives at _aeo.example.com. The leading underscore marks a name reserved for machine use rather than for a website.
It proves control, which is the practical equivalent for most purposes. Publishing a record requires access to the domain's DNS, so a value that appears there could only have been placed by someone with that access. That is why domain verification flows so often ask for one.
Not on someone else's domain, since publishing requires DNS control. But a TXT record only proves who published the text - not that the text is accurate. That gap is why some conventions add a cryptographic signature over the content, so the record proves both origin and integrity rather than origin alone.
There is no expiry built into DNS. A record stays published until it is changed or removed, and a TTL only controls how long resolvers cache it. Any notion of freshness has to be carried in the record's own content - which is why some conventions include a date and separate it from any claim about expiry.