TXT Records Explained: SPF, DKIM, DMARC and Verification

A TXT record is a DNS record that holds free-form text. Originally meant for human-readable notes, it is now the standard place to store machine-readable values for two jobs: verifying that you control a domain and authenticating the email sent from it. If you have ever pasted a long token into your DNS panel to "verify your domain," or set up SPF, DKIM and DMARC, you were creating TXT records.

TXT records sit alongside the other record types covered in DNS records explained. Unlike address records that point a name to a server, a TXT record carries text that other systems read and act on. The most important of those systems are mail receivers, which check your TXT records before deciding whether to trust an incoming message.

Domain Verification

Proving ownership is the simplest use. A service hands you a unique string, you publish it as a TXT record, and the service queries DNS to confirm it. Since only the domain owner can edit DNS, a matching value proves control.

A typical verification record looks like google-site-verification=abc123def456. Other providers use their own prefixes, such as MS=ms12345678 for Microsoft. These records do nothing beyond verification, so you can leave them in place or remove them once confirmed.

SPF: Who Is Allowed To Send

SPF, short for Sender Policy Framework, publishes the list of servers permitted to send mail for your domain. When a message arrives, the receiver looks up your SPF record and checks whether the connecting server is on it. The mechanism is specified in RFC 7208.

An SPF record is a TXT record beginning with v=spf1, for example v=spf1 include:_spf.google.com ~all. The include pulls in your provider's allowed servers. Everything else gets softfailed by ~all. Once you are confident the list is complete, switch to -all for a strict hardfail.

Here is the one rule you cannot bend: a domain must have exactly one SPF record. Send through several providers? Merge every source into a single v=spf1 line. Two separate SPF records produce a permerror under RFC 7208 and break authentication entirely.

DKIM: Proving The Message Was Not Altered

DKIM, or DomainKeys Identified Mail, adds a cryptographic signature to outgoing mail. Your sending platform signs each message with a private key. The matching public key lives in a TXT record. A receiver fetches that public key, verifies the signature, and confirms the message was not altered in transit. The signing and verification process is defined in RFC 6376.

DKIM records live at a selector subdomain, such as selector1._domainkey.example.com. The value carries the public key, for example v=DKIM1; k=rsa; p=MIGfMA0GCSq.... When you enable DKIM, your provider supplies both the selector name and the key.

DMARC: Tying It Together

DMARC, which stands for Domain-based Message Authentication, Reporting and Conformance, builds on top of SPF and DKIM. It tells receivers what to do when a message fails authentication, and where to send reports about your domain's mail. The policy framework comes from RFC 7489.

A DMARC record is a TXT record published at _dmarc.example.com. A sensible starting value is v=DMARC1; p=none; rua=mailto:[email protected]. The policy p takes one of three settings: none for monitoring only, quarantine to divert failing mail to spam, or reject to refuse it outright. Most domains begin at p=none to gather reports, then tighten gradually toward p=reject.

SPF vs DKIM vs DMARC

Mechanism	What it does	Where it lives
SPF	Lists servers allowed to send for the domain	TXT at the root, v=spf1 ... ~all
DKIM	Cryptographically signs messages so receivers detect tampering	TXT at selector._domainkey, v=DKIM1; ... p=...
DMARC	Sets policy and reporting when SPF or DKIM fails	TXT at _dmarc, v=DMARC1; p=none

Why TXT Records Matter For Deliverability

These records are the backbone of anti-spoofing. Without SPF and DKIM, anyone can forge mail from your domain, and receivers have no way to tell genuine messages from phishing. Without DMARC, even failing messages may still land in inboxes. Mailbox providers increasingly require all three, and bulk senders that lack them see mail rejected or dumped into spam.

TXT records handle authentication, while MX records explained cover where incoming mail is delivered. MX routes the mail; SPF, DKIM and DMARC authenticate it. Both work together for a healthy mail setup, and both are part of the wider picture in DNS records explained.

How To Check Your TXT Records

Misconfigured TXT records fail quietly: mail still flows until a receiver starts enforcing policy, then deliverability drops without warning. The fix is to inspect what is actually published. Our DNS lookup pulls every TXT record for a domain so you can confirm your SPF line is single and correct, your DKIM selectors resolve, and your DMARC policy reads the way you intended.

Run a free DNS check at domainintel.app to see your live TXT records and verify your email authentication is set up correctly.