Domains and DNS

What is a TXT record used for?

TXT is the record type with no defined meaning, which is exactly why it ended up carrying most of the internet’s trust signals.

A TXT record publishes arbitrary text at a DNS name. It was defined with no particular purpose, and that blankness is why it now carries five specific things: proof that you own a domain, your SPF policy, your DKIM public keys, your DMARC policy, and configuration strings for SaaS platforms. A single name can hold many TXT records, and a resolver returns all of them — which is why an ownership string sitting next to your SPF record is harmless, but a second SPF record is not.

Worked out 2026-09-11 (IST) · standard DNS as specified in RFC 1035

The five jobs TXT records do

What lives in a TXT record
Purpose	Published at	Looks like
Domain ownership proof	the domain, or a vendor-specified name	google-site-verification=…
SPF — who may send as you	the domain itself	v=spf1 include:_spf.google.com ~all
DKIM — signing public key	selector._domainkey.example.com	v=DKIM1; k=rsa; p=MIIBIjANBg…
DMARC — what to do on failure	_dmarc.example.com	v=DMARC1; p=reject; rua=mailto:…
Service configuration	vendor-specified name	MS=ms12345678, atlassian-domain-verification=…

Rules that are easy to break

Constraints worth knowing
Rule	Consequence of breaking it
One SPF record per domain	Two v=spf1 records = permanent error, SPF fails for everyone
255 bytes per character-string	Longer values are split into several quoted strings automatically
SPF resolves at most 10 DNS lookups	An eleventh include or mx pushes you over and SPF returns permerror
DMARC must be at _dmarc, not the apex	A DMARC record at the apex has no effect at all
TXT is public	Never put anything confidential in one — the whole internet can read it

What a domain’s TXT records tell an outsider

Because TXT records are public and rarely cleaned up, the set a domain publishes is a readable history of the software an organisation runs. A verification string for a helpdesk platform, another for a CRM, an SPF include for a marketing tool, DKIM selectors for two different mail providers — together these describe a company's stack without anyone having to ask. That is useful when you are auditing your own domain, and it is the first thing an attacker looks at when they are planning a convincing phishing email.

The three mail records are covered in detail in what is an SPF record and what is DMARC.

Sources: IETF RFC 1034 and RFC 1035 (domain names), RFC 2181 (clarifications to the DNS specification), RFC 5321 (SMTP) and RFC 7505 (null MX).

Check your own numbers

List every TXT record a domain publishes, including the _dmarc and _domainkey names.

DNS LookupA, AAAA, MX, NS, TXT, CNAME and SOA records, live from the resolver.

Frequently asked

Can I have more than one TXT record?

Yes, as many as you like, and a lookup returns all of them. The exception that bites people is SPF: RFC 7208 permits exactly one SPF record per domain, so if you publish two strings starting with v=spf1, compliant receivers treat the result as a permanent error and your SPF stops working entirely. Merge them into one record instead.

Why is my TXT record split into two quoted strings?

A single character-string inside a DNS record is capped at 255 bytes. Anything longer - a 2048-bit DKIM key, for instance - is published as several quoted strings, which the receiver concatenates with nothing between them. Your DNS interface may show it as one long value and store it as several; both are correct and the join is invisible.

Where exactly do SPF, DKIM and DMARC records live?

SPF goes on the domain itself - example.com. DMARC goes on the subdomain _dmarc.example.com. DKIM goes on selector._domainkey.example.com, where the selector is a label your mail provider chooses, such as google or s1. Putting any of them at the wrong name is the most common reason a correctly written record has no effect at all.

Is it safe to leave old verification TXT records in place?

It is safe but untidy, and occasionally worse than untidy. Stale verification strings tell anyone who looks which SaaS platforms you have ever used, which is useful reconnaissance. More seriously, a verification record left behind for a service you no longer control can let someone re-claim your domain on that platform. Remove them when you stop using the service.

Need domain and DNS checks inside your own product?

We build WHOIS, RDAP, DNS and SSL lookups as embeddable widgets or a plain JSON API in your branding, wired to your own lead form. Tell us which checks you need and we will send a working demo.