TXT Records, SPF, DKIM & DMARC: The Guide to Email Authentication

A TXT record attaches arbitrary text to a DNS name. There is no fixed syntax DNS itself enforces — the value is just one or more text strings — so TXT records have become the general-purpose place to publish machine-readable facts about a domain.

Two properties matter:

• One name can hold many TXT records. Unlike a CNAME, a single name can carry multiple TXT records side by side. A resolver returns all of them, and each consumer reads only the ones it understands (an SPF checker reads the v=spf1 string; a verification service reads its own token).
• The content is interpreted by convention, not by DNS. SPF, DKIM, and DMARC all live in ordinary TXT records; what makes them "an SPF record" or "a DMARC record" is the prefix and the location, not a special DNS type.

Common uses you will meet:

• Human notes — a free-text description, contact info, or a reminder for whoever administers the zone.
• Domain verification — proving control of a domain to a third party (covered next).
• Email authentication — SPF, DKIM, and DMARC, which make up the rest of this guide.

When you sign up for a service that needs to prove you own a domain — Google Workspace, Microsoft 365, a marketing platform, a search console — it usually hands you a TXT verification token: a unique string you add as a TXT record on your domain.

For example, a provider might ask you to publish a TXT record at example.com containing a value like provider-site-verification=Ab12Cd34Ef56. The service then performs a DNS lookup, sees its token, and concludes that whoever controls the DNS for example.com — that is, you — also controls the account.

Because one name can hold many TXT records, these verification strings sit happily alongside your SPF and other TXT records. You can usually remove a verification token once setup is confirmed, though some providers prefer you leave it in place.

SPF (Sender Policy Framework) answers one question: which mail servers are allowed to send email using your domain in the envelope sender? You publish the answer as a TXT record at your domain apex (for example, at example.com), and a receiving server checks it when mail arrives.

An SPF record always starts with v=spf1 and lists mechanisms that authorize senders, ending with an all mechanism that says what to do with everything else:

• ip4 / ip6 — authorize a specific IP address or range, e.g. ip4:198.51.100.0/24.
• include — pull in another domain's SPF record, e.g. include:_spf.example.net (this is how you authorize a mail provider's servers without listing their IPs yourself).
• a / mx — authorize the hosts named in the domain's A or MX records.
• -all (hard fail) — reject anything not matched above. ~all (soft fail) — accept but mark it as suspicious. Most domains end with -all once they are confident the record is complete.

A complete record looks like this:

v=spf1 include:_spf.example.net ip4:198.51.100.0/24 -all

Two rules trip people up:

• Exactly one SPF record per domain. If a name has two TXT records that both begin with v=spf1, SPF is treated as broken (a "permerror"). Merge everything into a single record.
• A hard limit of 10 DNS lookups. Per RFC 7208, evaluating an SPF record may trigger at most 10 DNS-querying mechanisms (each include, a, mx, and a few others counts). Exceed it and SPF fails with a permerror — even though the record "looks" fine. Flatten or consolidate includes to stay under the limit.

One historical note: there was once a dedicated SPF DNS record type, but it was deprecated. In practice SPF lives in a TXT record, full stop.

DKIM (DomainKeys Identified Mail) proves that a message genuinely came from your domain and was not altered in transit. Where SPF authorizes servers, DKIM signs the message itself with public-key cryptography (RFC 6376).

It works in two halves:

• The sending server signs. When mail leaves, the server computes a cryptographic signature over the message headers and body using a private key, and attaches it as a DKIM-Signature: header. That header names the domain and a selector (a short label like selector1).
• The public key lives in DNS. You publish the matching public key as a TXT record at <selector>._domainkey.<domain> — for example, selector1._domainkey.example.com. Its value looks like v=DKIM1; k=rsa; p=<base64 public key>.

A receiver reads the selector from the DKIM-Signature header, fetches the public key from that exact DNS name, and verifies the signature. If it checks out, the receiver knows two things: the message really was signed by a holder of that domain's private key, and the signed content arrived intact.

The selector is what lets a domain run several keys at once (different providers, or rotating an old key out for a new one) — each provider publishes its key under its own selector name.

DMARC (Domain-based Message Authentication, Reporting & Conformance) sits on top of SPF and DKIM. It is a TXT record published at _dmarc.<domain> — for example, _dmarc.example.com — and it does two jobs (RFC 7489):

• It tells receivers what to do with mail that fails authentication, via a policy.
• It asks for reports so you can see who is sending mail as your domain.

A starter record looks like this:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

The key tags:

• p= — the policy: none (monitor only), quarantine (send failures to spam), or reject (refuse them outright).
• rua= — a mailto: address where aggregate (daily summary) reports are sent.
• Optional: sp= (policy for subdomains), pct= (apply the policy to a percentage of mail during rollout), and adkim= / aspf= (how strictly alignment is enforced).

The crucial idea is alignment. DMARC does not just ask "did SPF or DKIM pass?" — it asks whether the domain that passed matches the visible From: address. A message passes DMARC when SPF or DKIM passes and the passing identifier aligns with the From: domain. Alignment is what makes DMARC effective against spoofing: an attacker may be able to pass SPF for some throwaway domain, but they cannot make it align with your From: domain.

Picture an inbound message that claims to be From: news@example.com, arriving at a receiving mail server. Here is the check it runs:

1. SPF. The receiver notes the sending server's IP and the envelope sender domain, fetches the SPF record at that domain, and checks whether the IP is authorized. Pass or fail is recorded.
2. DKIM. The receiver reads the DKIM-Signature header, fetches the public key from selector1._domainkey.example.com, and verifies the signature over the message. Pass or fail is recorded.
3. DMARC and alignment. The receiver looks up _dmarc.example.com. It then asks: did SPF or DKIM pass, and does the passing domain align with the From: domain example.com? If yes, the message passes DMARC.
4. Act on policy. If DMARC fails, the receiver applies your published policy — deliver (p=none), quarantine, or reject — and later sends an aggregate report to your rua= address summarizing what it saw.

The result: a forged message that copies your From: address but cannot produce a DKIM signature or an SPF-authorized, aligned sender fails DMARC — and your policy decides its fate.

The mistake that breaks legitimate mail is enforcing too early. DMARC is designed to be rolled out in stages so you can watch before you block:

1. Publish p=none with rua=. This changes nothing about delivery but starts the flow of aggregate reports. You now get a daily picture of every source sending as your domain — including the forgotten newsletter tool and the billing system you did not know about.
2. Monitor and fix. Read the reports. Make sure every legitimate sender is authorized in SPF and signing with DKIM, and that those identifiers align with your From: domain. This is the real work, and it can take a few weeks.
3. Move to p=quarantine. Once legitimate mail is consistently passing, raise the policy so failures go to spam rather than the inbox. Optionally use pct= to ramp it up gradually.
4. Move to p=reject. When you are confident, set the policy to reject. Now forged mail using your domain is refused outright at the receiver.

The order matters: enforcement should be the last step, after monitoring has proven that no legitimate mail is caught in the net.

Most email-authentication problems come from a short list of avoidable errors:

• Two SPF records. Publishing more than one TXT record starting with v=spf1 is invalid and breaks SPF entirely. Combine them into a single record with multiple mechanisms.
• SPF over the 10-lookup limit. Stacking too many include mechanisms pushes evaluation past the 10-DNS-lookup ceiling and triggers a permerror. Audit your includes and flatten where you can.
• Missing or wrong DKIM selector. If the public key is not published at the exact <selector>._domainkey.<domain> name your sender uses, verification fails. The selector in DNS must match the one in the DKIM-Signature header.
• DMARC without alignment. SPF or DKIM can technically pass while still failing DMARC because the passing domain does not match the From: domain. Check alignment, not just raw pass/fail.
• Jumping straight to p=reject. Enforcing before monitoring is the fastest way to send your own legitimate mail to oblivion. Start at p=none and earn your way to reject.

It is easy to lump MX in with SPF, DKIM, and DMARC because they all concern email, but they do different jobs:

• MX records route mail — they tell other servers where to deliver mail addressed to your domain.
• SPF, DKIM, and DMARC authenticate mail — they let receivers decide whether mail claiming to be from your domain is genuine.

An MX record is its own DNS record type, not a TXT record, and it has nothing to say about authentication. A domain can route mail perfectly via MX while still being trivially spoofable because it has no SPF, DKIM, or DMARC. For how mail routing itself works — priorities, fallbacks, and the host an MX points to — see MX records.

Because SPF, DKIM, and DMARC all live in TXT records, you can read every one of them with a single tool:

• Run a DNS lookup on a domain and read its TXT records. The SPF record is the value starting with v=spf1 at the domain apex.
• To see a domain's DMARC policy, look up the TXT record at _dmarc.<domain> — for example, _dmarc.example.com.
• To inspect a DKIM key, you need the selector the sender uses; query the TXT record at <selector>._domainkey.<domain> (such as selector1._domainkey.example.com).
• Check the MX records alongside them to confirm where the domain's mail is actually routed.

For a wider view of what every record type does, see DNS record types. Start by looking up a domain's TXT records.