Email Authentication

SPF, DKIM, and DMARC Explained: The Complete Guide to Email Authentication

SPF, DKIM, and DMARC are the three DNS-based protocols that prove you are who you say you are when sending email. Together they stop spoofing, reduce spam complaints, and unlock the inbox at Google, Microsoft, and Yahoo. This guide explains what each one does, how they fit together, and how to set up DMARC correctly.

← All resources

Why Email Authentication Matters

Email was designed in the 1970s with no concept of sender verification. Anyone could send a message claiming to be from any address. Spam, phishing, and business-email compromise (BEC) attacks all exploit this gap.

SPF, DKIM, and DMARC close that gap by giving domain owners a way to cryptographically and policy-wise declare: "These are the only servers that can send email for my domain, and here's what to do if something doesn't match."

In 2024, Google and Yahoo introduced mandatory authentication requirements: bulk senders must have SPF and DKIM configured, and must have a DMARC record at p=none or stricter. Senders who don't comply see higher spam filtering rates and eventual outright rejection.

What Is SPF (Sender Policy Framework)?

SPF is a DNS TXT record that lists the IP addresses and mail servers that are authorised to send email for your domain. When a receiving mail server gets a message from your domain, it looks up your SPF record and checks whether the sending IP is on the approved list.

SPF checks the envelope sender (the MAIL FROM address used during the SMTP handshake) — not the From: header visible to users. This distinction matters for DMARC alignment (explained below).

Example SPF record:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:192.0.2.1 -all

This says: email for this domain may come from Google Workspace servers, SendGrid, or IP 192.0.2.1. Everything else is a hard-fail (-all).

Key SPF limitation: SPF breaks when email is forwarded, because the forwarding server's IP is not in your SPF record. This is one reason DKIM exists.

What Is DKIM (DomainKeys Identified Mail)?

DKIM adds a cryptographic signature to each outgoing email. Your mail server signs the message with a private key; the public key is published in a DNS TXT record on your domain. Receiving servers use the public key to verify the signature — if it matches, the message hasn't been tampered with in transit and genuinely came from a server that holds your private key.

Unlike SPF, DKIM survives email forwarding — the signature travels with the message headers and doesn't depend on the sending IP.

DKIM DNS record format (the public key lives at a specific selector subdomain):

selector._domainkey.yourdomain.com  TXT
  v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

You don't usually write this record manually — your email service provider (Google Workspace, Microsoft 365, SendGrid, Postmark, etc.) generates the key pair and gives you the DNS record to publish.

What Is DMARC?

DMARC (Domain-based Message Authentication, Reporting and Conformance) builds on SPF and DKIM by adding two things:

  • Alignment checking — DMARC requires that the domain in the From: header (what users see) aligns with the domain verified by SPF or DKIM. This closes the spoofing gap that SPF alone leaves open.
  • Policy enforcement — DMARC tells receiving servers what to do when a message fails both SPF and DKIM alignment: none (take no action), quarantine (send to spam), or reject (block the message).

Example DMARC record:

_dmarc.yourdomain.com  TXT
  v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100
  • p=quarantine — messages that fail DMARC should be quarantined (sent to spam).
  • rua=mailto:... — where to send aggregate reports (who is sending on your behalf, and which messages pass/fail).
  • pct=100 — apply the policy to 100% of failing messages.

How SPF + DKIM + DMARC Work Together

Think of them as three layers of a security system:

  • SPF verifies the sending server is on the approved list for your envelope domain.
  • DKIM verifies the message content hasn't been changed and was sent by a server holding your private key.
  • DMARC checks that at least one of SPF or DKIM aligns with the visible From: domain, and tells receivers what to do if neither passes.

For DMARC to pass, at least one of the following must be true: SPF passes and the SPF domain aligns with the From: domain, OR DKIM passes and the DKIM d= domain aligns with the From: domain.

Check your SPF, DKIM, and DMARC now

Run an instant check of your domain's authentication setup — SPF syntax, DKIM selector, DMARC policy, and alignment — all in one free tool.

Check your authentication for free →

Setting Up DMARC Step by Step

The standard approach is to start with a monitoring-only policy, review the reports, then tighten the policy once you're confident no legitimate mail will be blocked.

  1. Confirm SPF is working. Run a check on your domain and verify you have exactly one SPF record, it has fewer than 10 DNS lookups, and it ends in ~all or -all.
  2. Confirm DKIM is signing. Send a test email and check the headers for a DKIM-Signature header. Alternatively, use the free tool above to verify your DKIM selector exists in DNS.
  3. Publish a DMARC record at p=none. This is monitor-only — receiving servers send you reports but take no action on failing messages:
    v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
  4. Review the aggregate reports for 2–4 weeks. DMARC reports are XML files sent to the rua address daily by large providers. Use a DMARC report analyser to read them in a human-friendly format. Look for: which sources are sending on your behalf, and which ones are failing SPF or DKIM.
  5. Fix any legitimate sources that are failing. Add missing mail servers to your SPF record. Ensure DKIM signing is enabled on all your email platforms (ESP, CRM, helpdesk, etc.).
  6. Move to p=quarantine. Start with pct=10 (apply to 10% of failing messages) and increase gradually as you confirm no legitimate mail is being quarantined.
  7. Move to p=reject. The strictest policy — failing messages are blocked outright. This is the gold standard and the policy required by Google for sending to Google accounts without phishing warnings.

Common Mistakes

  • Publishing p=reject without testing. Going straight to reject before auditing all your sending sources will block legitimate email. Always start at p=none.
  • Forgetting DKIM on third-party senders. Your marketing platform, CRM, helpdesk, and calendar invites all send email on your behalf. Each needs DKIM configured with your domain — not just your primary mail provider.
  • Using +all in SPF. This allows any server in the world to pass SPF for your domain — it defeats the purpose entirely. Always end with -all.
  • Exceeding 10 SPF DNS lookups. Each include: counts as one lookup; nested includes count too. Exceeding 10 causes a PermError and SPF fails on all messages.
  • Not monitoring DMARC reports. DMARC without a rua address is flying blind. You won't know when a new sending source starts failing, or when a spammer starts spoofing your domain.

Check Your Setup

Once you have published your records, verify them with the free tool:

FAQ

Frequently asked questions

Next steps

Related resources

Continue with related guidance
Check a sending domain against DNS blocklists

Run a free, point-in-time lookup and review which configured providers report a listing, return a clean result, or are unavailable. No account is required.

Results cover only the configured DNS blocklists that return a usable response. A clean result does not cover every blocklist or establish inbox placement; an unavailable provider remains unchecked.

Open the public domain checker →

Stay on top of your authentication records

ReputaPilot monitors your SPF, DKIM, and DMARC configuration continuously and alerts you the moment a record changes, breaks, or drifts out of alignment — before it costs you inbox placement.

Start monitoring free →See pricing