SPF, DKIM, and DMARC Explained: The Email Authentication Trio

Email was designed in the 1980s without any built-in way to verify the sender's identity. By default, anyone can send an email claiming to be from any address — this is the fundamental flaw that enables phishing, spoofing, and spam.

SPF, DKIM, and DMARC are three complementary standards that fix this gap. Together, they allow receiving mail servers to verify that an email was actually sent by an authorized server, hasn't been tampered with in transit, and that the domain owner has specified what to do with emails that fail these checks.

Implementing all three is now effectively mandatory. Google and Yahoo began requiring SPF, DKIM, and DMARC for bulk senders in early 2024, and even small senders see significantly better deliverability with proper authentication in place.

SPF lets a domain owner specify which mail servers are authorized to send email on behalf of their domain. It's published as a DNS TXT record.

How it works:

1. You publish an SPF record in your domain's DNS listing the IP addresses and services allowed to send email for your domain.
2. When a receiving server gets an email from your domain, it checks the sending server's IP against your SPF record.
3. If the IP matches, SPF passes. If not, it fails.

Example SPF record: v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.50 -all

This record says: allow Google Workspace servers, SendGrid servers, and IP 203.0.113.50 to send email for this domain. Reject (-all) everything else.

Common SPF mechanisms:

• include: Allow servers authorized by another domain's SPF record
• ip4/ip6: Allow specific IP addresses
• a: Allow the IPs that the domain's A record points to
• mx: Allow the IPs that the domain's MX records point to
• -all: Fail everything not explicitly allowed (hard fail)
• ~all: Soft fail (mark as suspicious but don't reject)

SPF limitation: SPF only validates the "envelope from" (Return-Path), not the "header from" (the address displayed to users). This means SPF alone doesn't fully prevent spoofing — that's where DKIM and DMARC come in.

DKIM adds a cryptographic digital signature to outgoing emails, allowing the receiving server to verify that the message hasn't been altered in transit and was sent by an authorized server.

How it works:

1. You generate a public/private key pair. The public key is published as a DNS TXT record. The private key is stored on your mail server.
2. When sending an email, your server creates a hash of certain email headers and the message body, then encrypts this hash with the private key. This signature is added as a DKIM-Signature header.
3. The receiving server retrieves your public key from DNS and uses it to verify the signature.
4. If the signature matches, the email hasn't been tampered with and came from a server with access to the private key.

Example DKIM DNS record: selector1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGS..."

Why DKIM matters: Unlike SPF, DKIM survives email forwarding. When an email is forwarded, the DKIM signature remains intact (as long as the forwarding server doesn't modify the signed content). DKIM also verifies content integrity — if someone modifies the email in transit, the signature verification fails.

DMARC ties SPF and DKIM together and tells receiving servers what to do when emails fail authentication. It also provides a reporting mechanism so you can see who is sending email using your domain.

How it works:

1. You publish a DMARC record in DNS specifying your policy.
2. When a receiving server gets an email from your domain, it checks SPF and DKIM results.
3. DMARC requires "alignment" — the domain in the "From" header must match the domain validated by SPF or DKIM.
4. Based on the result and your DMARC policy, the server takes action.

Example DMARC record: _dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100"

DMARC policies:

• p=none: Monitor only. Emails that fail are delivered normally, but you receive reports. Start here.
• p=quarantine: Failed emails are sent to the spam/junk folder.
• p=reject: Failed emails are rejected entirely. This is the strongest protection.

Recommended rollout:

1. Set p=none and monitor DMARC reports for 2–4 weeks to identify all legitimate senders.
2. Add SPF and DKIM records for all legitimate senders you discover.
3. Move to p=quarantine for a few weeks.
4. Move to p=reject once you're confident all legitimate email passes.

Check your DNS records: Use LookMyIP's DNS Lookup tool to verify your SPF, DKIM, and DMARC records are published correctly. Look up TXT records for your domain.

Check MX records: Use LookMyIP's MX Checker to verify your mail servers are correctly configured.

Send a test email: Send an email to a Gmail address and check the original message headers (three dots menu > "Show original"). Look for SPF, DKIM, and DMARC results — each should show "PASS."

Common issues:

• SPF "too many lookups" error: SPF allows a maximum of 10 DNS lookups. If you include too many third-party services, you'll exceed this limit. Consolidate or use SPF flattening.
• DKIM key rotation: Rotate your DKIM keys at least annually. Some providers do this automatically.
• DMARC alignment failures: Make sure the domain in your "From" address matches the domain authenticated by SPF (Return-Path domain) or DKIM (d= domain).
• Third-party senders: If you use services like Mailchimp, SendGrid, or HubSpot, you need to add them to your SPF record AND configure DKIM signing with your domain.

SPF and DKIM each existed for years without meaningfully stopping spoofing, and the reason is alignment. Understanding it is what turns three separate acronyms into one coherent system.

An email has two "from" addresses, and users only ever see one of them.

• The envelope sender (MAIL FROM, also called Return-Path) is used during SMTP delivery and for bounce handling. It is invisible in every mail client.
• The header From is the address displayed to the recipient.

SPF validates the *envelope* sender. DKIM validates the domain in the signature's d= tag. Neither, on its own, says anything about the header From — which is the only one a human reads.

That gap is exactly how spoofing worked. An attacker sends from bounces@attacker-owned.example, publishes valid SPF for that domain, and sets the header From to ceo@yourbank.example. SPF passes. The message is authenticated. It is also completely fraudulent.

DMARC closes the gap by requiring alignment: the domain that passed SPF or DKIM must match the domain in the header From. A message passes DMARC if it passes SPF *with an aligned envelope domain*, or passes DKIM *with an aligned signing domain*. Either one suffices; both failing means the message fails DMARC.

Alignment comes in two modes, set with aspf and adkim:

• Relaxed (default) — the organisational domain must match. mail.example.com aligns with example.com.
• Strict — the domains must match exactly. mail.example.com does *not* align with example.com.

Start relaxed. Strict alignment breaks subdomain-based sending for very little additional protection, and is a common cause of self-inflicted delivery failures.

This is the most common SPF failure in production, and it fails in a way that is easy to miss because it does not announce itself.

RFC 7208 caps the number of DNS lookups an SPF evaluation may perform at ten. Exceed it and the result is permerror, which most receivers treat as a failure — not as "no policy". The mechanisms that count are include, a, mx, ptr and exists. Crucially, they count *recursively*: an include that itself contains three includes consumes four lookups, not one.

Real-world costs add up fast:

A company using Google Workspace, SendGrid and Mailchimp is already at seven. Add a CRM and a helpdesk tool and the record breaks — usually quietly, months after it was written, when a provider expands its own record.

Three fixes, in order of preference:

Remove what you no longer use. Most over-limit records contain includes for services abandoned years ago. Audit before optimising.

Never use `ptr`. It is deprecated, slow, and explicitly discouraged by RFC 7208. Remove it on sight.

Flatten the record. Resolve the includes to their underlying IP ranges and publish those directly, which costs zero lookups. The trade-off is real: when a provider changes its sending IPs, your flattened record is silently wrong and mail starts failing. Only flatten with automated tooling that re-checks and updates the record regularly.

Also note the 255-character limit per DNS string — long records must be split into multiple quoted strings within the same TXT record, which resolvers concatenate.

Check your current count with the SPF, DKIM and DMARC checker, which reports the recursive total rather than the visible one.

Publishing p=reject on day one is how organisations discover, painfully, how many systems send mail as their domain. The correct rollout is gradual and driven by data.

Week 1 — monitor only. This is safe: it changes no delivery behaviour whatsoever and simply asks receivers to report.

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1"

Weeks 2–4 — read the reports. Aggregate reports arrive daily as gzipped XML, one per reporting receiver. They are close to unreadable by hand at any volume, so use a processing service — several offer free tiers. What you are looking for is every source sending as your domain: the marketing platform nobody mentioned, the invoicing system, the office scanner, a legacy application on a server in a cupboard.

Expect surprises. Almost every organisation finds at least one legitimate sender it did not know about.

Weeks 4–8 — authenticate everything you found. Add each legitimate source to SPF, configure DKIM signing for it, and confirm alignment. Anything you cannot authenticate should be moved to a source you can, or migrated to a subdomain with its own policy.

Week 8 — partial quarantine. Apply the policy to a fraction of mail first:

"v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com"

Raise pct to 50, then 100 over several weeks, watching reports at each step.

Week 12+ — reject.

"v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc@example.com"

Note sp=reject, which covers subdomains. Without it, attackers spoof accounts.example.com and your apex policy does not apply. Also publish a null MX and a restrictive DMARC record on domains you own but never send from — parked domains are a favourite spoofing target precisely because nobody protects them.

Email authentication has one genuinely hard problem: forwarding legitimately breaks it.

SPF always breaks on forwarding. When a message is forwarded, the forwarding server becomes the new sender. Its IP is not in the original domain's SPF record, so SPF fails. This is not a misconfiguration — it is inherent to how SPF works.

DKIM usually survives, unless the message is modified. The signature covers the body and selected headers. A mailing list that appends a footer, rewrites the subject with a [list-name] prefix, or converts the message format invalidates the signature.

When both break, DMARC fails, and a p=reject policy causes forwarded legitimate mail to be discarded. This caused significant disruption when Yahoo and AOL adopted p=reject in 2014 and mailing lists across the internet began bouncing their subscribers.

Two mitigations are now standard.

From-header rewriting. Mailing lists rewrite the From address to their own domain — Alice via list-name <list@example.org> — preserving the original in Reply-To. Ugly, but it makes the message pass DMARC under the list's own domain. Mailman 3 and Google Groups do this by default.

ARC (Authenticated Received Chain), RFC 8617, is the proper fix. Each intermediary that handles a message records the authentication results it observed and signs that record. A receiver at the end of the chain can see that the message authenticated correctly before a trusted forwarder modified it, and choose to honour that rather than the now-broken original signature. Google, Microsoft and Zoho all implement it.

The practical guidance: if you run a mailing list, implement From-header rewriting and ARC sealing. If you publish p=reject, expect a small volume of forwarding-related failures in your reports and do not treat every one as an attack — read the source before acting.