SPF, DKIM, and DMARC Explained: What They Do and How They Work Together

Why email authentication matters

Without email authentication, anyone can send a message with your domain in the From: address. This is called email spoofing and it's the foundation of most phishing attacks. A scammer can send "From: [email protected]" with no technical barrier stopping them.

SPF, DKIM, and DMARC are the three DNS-based standards that close this gap. Each one solves a different part of the problem, and together they give email receivers everything they need to verify your messages are legitimate — and reject the ones that aren't.

SPF — who is allowed to send for your domain

SPF (Sender Policy Framework) is a DNS TXT record you publish at your root domain that lists which mail servers are authorized to send email on your behalf.

When an email arrives claiming to be from [email protected], the receiving server looks up your SPF record and checks whether the sending server's IP address is listed. If it's not, the message fails SPF.

What an SPF record looks like

• v=spf1 — Identifies this as an SPF record
• include:_spf.google.com — Authorizes Google's mail servers (for Google Workspace)
• include:sendgrid.net — Authorizes SendGrid (for transactional email)
• ~all — Softfail anything not listed (use -all for hardfail once your list is complete)

SPF's limitation: it breaks on forwarding

SPF checks the server that delivered the message — not the original sender. When email is forwarded (e.g., by an email alias or mailing list), the forwarding server's IP is not in your SPF record. This causes legitimate forwarded email to fail SPF. This is why DKIM is essential — it survives forwarding.

DKIM — cryptographic proof the message wasn't altered

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing message. The signature is embedded in the email headers. Receiving servers use a public key published in your DNS to verify the signature, confirming two things:

1. The message genuinely came from a server in control of your domain
2. The message body and headers weren't altered after it was signed

What a DKIM record looks like

The selector (here, google) is set by your email provider. Each service that sends on your behalf has its own selector — Google Workspace, SendGrid, Mailchimp, and others each give you a DNS record to publish. Your DNS can have multiple DKIM records (one per selector).

DMARC — the enforcement layer

DMARC (Domain-based Message Authentication, Reporting & Conformance) is the layer that ties SPF and DKIM together and adds two critical capabilities:

1. Alignment — DMARC requires that the domain in the From: address matches the domain verified by SPF or DKIM. This closes the "cousin domain" attack where spammers pass SPF/DKIM for a different domain than the one shown in From.
2. Policy enforcement — DMARC tells receivers what to do when a message fails: deliver it anyway (none), send it to spam (quarantine), or reject it outright (reject).
3. Reporting — DMARC generates daily reports showing every source that sent email using your domain, and whether each passed or failed authentication.

What a DMARC record looks like

How SPF, DKIM, and DMARC work together

When a message arrives at Gmail or Outlook, here is what happens behind the scenes:

1. The receiving server checks the sending IP against the sender's SPF record. Pass or fail.
2. The receiving server verifies the DKIM signature in the message headers using the public key in DNS. Pass or fail.
3. The receiving server checks the DMARC record. For DMARC to pass, at least one of SPF or DKIM must pass and align with the domain in the From: header.
4. Based on the DMARC policy (none, quarantine, reject), the receiver decides what to do with the message.
5. The receiver sends an aggregate report to the rua address in your DMARC record, summarizing the day's activity.

What order to set them up in

1. SPF first — Add the TXT record at your root domain listing all authorized senders. Verify it's live with dig TXT yourdomain.com.
2. DKIM second — Publish the DKIM public key records your email provider gives you. Verify each one resolves correctly.
3. DMARC third (p=none) — Publish your DMARC record with p=none to start monitoring. This collects reports without affecting delivery.
4. Monitor for 2–4 weeks — Review reports for any legitimate senders that are failing. Fix their SPF/DKIM alignment.
5. Enforce (p=quarantine, then p=reject) — Gradually tighten your policy once you're confident all legitimate email is passing.

For a detailed walkthrough with DNS record examples, see our DMARC setup guide →

Frequently asked questions

What is the difference between SPF, DKIM, and DMARC?

SPF lists the mail servers authorized to send for your domain. DKIM cryptographically signs your messages. DMARC ties both together — it sets an enforcement policy for failing messages and generates reports about your domain's email activity.

Do I need all three?

Yes. SPF and DKIM each protect against different attack vectors. DMARC requires at least one to pass and align. Without DMARC, there's no enforcement — receivers can still deliver spoofed messages even if SPF and DKIM are set up.

Can I have DMARC without DKIM?

Technically yes, but it's fragile. SPF alone breaks on email forwarding — forwarded messages fail SPF because the forwarding server isn't in your SPF list. DKIM survives forwarding because the signature travels with the message. Always configure both SPF and DKIM before publishing DMARC.

How do I know if my domain has SPF, DKIM, and DMARC set up?

Run these DNS lookups (replace yourdomain.com with your domain):

For DKIM, you need to know the selector name (provided by your email provider). Then: dig TXT selector._domainkey.yourdomain.com +short.