Email Authentication Explained: SPF, DKIM, and DMARC in Plain English

Every day, billions of phishing and spoofing emails are sent from domains that have no right to use them. If your domain lacks proper email authentication, attackers can send messages that appear to come from you — to your customers, partners, and employees — with nothing to stop them.

SPF, DKIM, and DMARC are three DNS-based standards that, together, verify that email claiming to be from your domain actually is. This guide explains each one clearly, how they interlock, and how to implement them step by step.

Why email authentication matters in 2026

Google and Yahoo now require SPF and DMARC for bulk senders (5,000+ messages/day). Microsoft is following suit. Even if you're a small sender, missing these records means:

• Your legitimate emails hit spam folders
• Anyone can impersonate your domain in phishing campaigns
• Your domain reputation degrades over time

The good news: setting these up is a one-time DNS task that takes under an hour.

SPF — Sender Policy Framework

SPF lets you publish a list of servers that are authorised to send email on behalf of your domain. It lives in a TXT DNS record at your root domain.

How it works

When a receiving mail server gets a message from @yourdomain.com, it looks up the SPF record for yourdomain.com and checks whether the sending server's IP is on the approved list. If it isn't, the message fails SPF.

Example SPF record

v=spf1 include:_spf.google.com include:sendgrid.net ~all

• v=spf1 — identifies this as an SPF record
• include: — authorises sending servers from another provider's SPF list
• ~all — soft fail for unlisted senders (use -all for hard fail once you're confident)

Common mistakes

• Multiple SPF records: You can only have one SPF TXT record per domain. Merge all sources into a single record.
• Too many lookups: SPF allows a maximum of 10 DNS lookups. Exceeding this causes a PermError and the record is ignored.
• Forgetting subdomains: SPF on example.com does not protect mail.example.com — add records for each sending subdomain.

DKIM — DomainKeys Identified Mail

DKIM adds a cryptographic signature to outgoing messages. The signature is verified against a public key published in DNS, proving the email body hasn't been tampered with in transit.

How it works

Your mail server signs outgoing messages using a private key. The signature goes in a DKIM-Signature header. The receiving server fetches your public key from a DNS TXT record at selector._domainkey.yourdomain.com and verifies the signature.

Example DKIM DNS record

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUA...

Key points

• Your email provider (Google Workspace, Postmark, SendGrid, etc.) generates the key pair and gives you the DNS record to publish.
• Use a 2048-bit key minimum — 1024-bit keys are considered weak.
• Rotate keys annually or after any security incident.
• Each sending service needs its own selector and key pair.

DMARC — Domain-based Message Authentication, Reporting & Conformance

SPF and DKIM each have blind spots — an email can pass one but fail the other, or a forwarder can break SPF alignment. DMARC ties them together by:

1. Requiring at least one of SPF or DKIM to align with the From: header domain
2. Telling receiving servers what to do when a message fails: nothing, quarantine (spam folder), or reject
3. Requesting aggregate and forensic reports so you can see all email flows from your domain

Example DMARC record (start here)

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; fo=1

Progressing to enforcement

Once you've reviewed a few weeks of rua reports and confirmed your legitimate senders all pass:

1. Move to p=quarantine — failing messages go to spam
2. After another monitoring period, move to p=reject — failing messages are dropped entirely

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; adkim=s; aspf=s

adkim=s; aspf=s enforces strict alignment — the domains must match exactly, not just be subdomains.

DMARC alignment explained

Alignment is the key concept that makes DMARC work. A message only passes DMARC if the From: domain aligns with:

• The domain that passed SPF (the envelope sender/Return-Path domain), OR
• The domain in the DKIM d= tag

This is why DMARC catches sophisticated spoofing that SPF or DKIM alone miss — the visible From: address must match the authenticated domain, not just some other sender in the chain.

Step-by-step implementation checklist

[ ] 1. Inventory all services that send email from your domain
       (transactional, marketing, support, CRM, etc.)
[ ] 2. Add an SPF record listing all authorised senders
[ ] 3. Enable and publish DKIM keys for each sending service
[ ] 4. Publish a DMARC record with p=none and rua= reporting address
[ ] 5. Monitor rua reports for 2-4 weeks
[ ] 6. Fix any legitimate senders not passing SPF/DKIM alignment
[ ] 7. Move to p=quarantine
[ ] 8. Monitor for another 2 weeks
[ ] 9. Move to p=reject
[ ] 10. Set a calendar reminder to rotate DKIM keys annually

Check your domain with Sitecheck

Sitecheck's DNS checker tests your domain for SPF, DKIM (common selectors), DMARC, DNSSEC, MX records, and more in a single scan. It flags missing records, misconfigurations, and known issues with actionable recommendations — no account required.

Summary

All three work together. SPF stops unauthorised senders. DKIM proves message integrity. DMARC ties both to the visible From address and gives you visibility. Implement them in order, monitor before enforcing, and your domain will be significantly harder to abuse.