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.