SPF, DKIM and DMARC Explained

SPF, DKIM and DMARC are three DNS-based standards that let receiving mail servers verify that email claiming to come from your domain really does. SPF lists which servers may send for you, DKIM adds a cryptographic signature to each message, and DMARC ties both to the visible From address and tells receivers what to do when checks fail.

The email protocol, SMTP, was designed without any built-in way to verify the sender. Anyone can send a message with From: billing@example.com, which is exactly what phishing relies on. These three standards close that gap, and they are no longer optional: since February 2024, Google and Yahoo have required bulk senders to authenticate with SPF and DKIM and to publish a DMARC policy, and smaller senders face stricter filtering without them.

SPF: Sender Policy Framework

SPF is a TXT record at your domain that lists the servers and services allowed to send mail for it. When a message arrives, the receiving server takes the domain from the envelope sender (the hidden "Return-Path" address used for bounces, not necessarily the From header), looks up its SPF record, and checks whether the connecting IP address is on the list.

example.com.  3600  IN  TXT  "v=spf1 ip4:192.0.2.25 ip6:2001:db8::25 include:_spf.example.net mx ~all"

Reading left to right:

  • v=spf1 identifies the record as SPF.
  • ip4: and ip6: authorize specific addresses or ranges.
  • include: pulls in another domain's SPF record, which is how you authorize an email provider or newsletter service.
  • mx authorizes the hosts in your MX records.
  • ~all is the catch-all for everything else.

~all vs -all

The final mechanism sets the result for senders that match nothing:

QualifierResultMeaning
-allFailUnlisted servers are not authorized; reject or treat as spoofed.
~allSoftfailProbably not authorized; accept but treat with suspicion.
?allNeutralNo statement either way.
+allPassAnyone may send. Never use this; it makes SPF useless.

-all is the strictest, but once DMARC is enforced, DMARC decides what happens to failing mail, so many administrators keep ~all to avoid outright rejection of legitimately forwarded messages before DMARC is evaluated. Either is reasonable if you have a complete list of senders.

The 10-DNS-lookup limit

To protect receivers from expensive lookups, the SPF specification (RFC 7208) allows at most 10 mechanisms that trigger DNS queries while evaluating a record: include, a, mx, ptr, exists and the redirect modifier all count, including those nested inside included records. ip4, ip6 and all do not count. Exceed the limit and SPF returns a permerror, which receivers treat as a failure. Each email service you add usually costs one or more lookups, so audit your record when you add providers, remove services you no longer use, and replace a or mx with explicit ip4 ranges where practical.

Note: A domain must have only one SPF record. Publishing two TXT records that start with v=spf1 causes a permerror. Merge them into a single record.

DKIM: DomainKeys Identified Mail

DKIM (RFC 6376) adds a digital signature to each outgoing message. The sending server signs selected headers and the body with a private key, and adds a DKIM-Signature header. The receiver fetches the matching public key from DNS and verifies the signature, which proves the message was authorized by the signing domain and was not altered in transit.

Selectors

The signature names a selector (s=) and a domain (d=). The receiver looks up the key at selector._domainkey.domain:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2026; ...

mail2026._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...IDAQAB"

Selectors let a domain publish several keys at once, one per email service or one per key generation. That makes key rotation simple: publish a new selector, switch signing to it, and remove the old key after messages signed with it have been delivered. Use 2048-bit RSA keys where your DNS host supports them, and split long keys into several quoted strings if needed, since one TXT string is limited to 255 characters.

Unlike SPF, DKIM signatures usually survive forwarding, as long as the forwarder does not modify the message, which makes DKIM the more robust of the two.

DMARC: tying it together

SPF and DKIM each verify a domain, but not necessarily the one in the visible From header that people actually see. A spammer could pass SPF for their own domain while displaying yours. DMARC (RFC 7489) fixes this with alignment, and it lets you publish a policy and receive reports.

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r"
  • p= is the policy for failing mail: none, quarantine or reject.
  • rua= is where receivers send daily aggregate reports.
  • sp= optionally sets a different policy for subdomains.
  • adkim= and aspf= set alignment to relaxed (r, the default) or strict (s).
  • pct= applies the policy to a percentage of failing mail.

Alignment

A message passes DMARC if either SPF or DKIM passes and is aligned with the From domain. With relaxed alignment, the domains only need to share the same organizational domain, so a DKIM signature from mail.example.com aligns with From: news@example.com. With strict alignment they must match exactly.

The most common real-world failure is a third-party service, such as a CRM or newsletter tool, that sends with its own bounce domain and signs with its own DKIM key. SPF and DKIM pass for the provider's domain, but neither aligns with yours, so DMARC fails. The fix is to configure the service to sign with DKIM on your domain (usually by publishing CNAME or TXT records it provides) and, if supported, a custom return-path subdomain.

A safe DMARC rollout plan

  1. Inventory senders. List every system that sends mail as your domain: your mailbox provider, website, invoicing, marketing, support desk.
  2. Publish SPF and enable DKIM for each of them.
  3. Start with p=none and a rua address. This changes nothing about delivery but starts the reports flowing.
  4. Read the aggregate reports for a few weeks. They are XML files listing, per sending IP, how many messages passed or failed SPF, DKIM and alignment. A DMARC report analyzer makes them far easier to read. Fix every legitimate source that fails.
  5. Move to p=quarantine, optionally with pct= to ramp up gradually. Failing mail now goes to spam.
  6. Move to p=reject once reports show only unauthorized sources failing. Spoofed mail using your exact domain is now refused by receivers that enforce DMARC.
Tip: Domains that never send email should still be protected. Publish v=spf1 -all and a DMARC record with p=reject so nobody can spoof them.

Mailbox provider requirements

Since February 2024, Google and Yahoo have required bulk senders (Google defines them as sending around 5,000 or more messages a day to personal Gmail accounts) to authenticate with both SPF and DKIM, publish a DMARC record (p=none is the minimum), have the From domain align with SPF or DKIM, offer one-click unsubscribe, and keep spam complaint rates low. Microsoft announced similar requirements for its consumer Outlook.com domains in 2025. Even if you send far less, meeting these requirements is the simplest way to stay out of spam folders. Valid reverse DNS on your sending IPs matters too.

Common errors and fixes

  • Multiple SPF records: merge them into one.
  • Too many lookups: remove unused includes and flatten where safe.
  • SPF record on the wrong name: SPF is published at the domain used in the envelope sender (often the apex), not at _dmarc or www.
  • DKIM key not found: check the selector spelling and that the record is at selector._domainkey; some DNS panels append the domain automatically, producing a doubled name.
  • DMARC record on the apex: it must be at _dmarc.example.com.
  • Forwarded mail failing: forwarding breaks SPF; make sure DKIM is in place, since it usually survives.

Our SPF and DMARC checker flags many of these problems automatically, the MX lookup confirms where your mail is delivered, and the DNS lookup tool can fetch any DKIM selector's TXT record.

Frequently asked questions

Do I need all three?

Yes. SPF and DKIM provide authentication, but only DMARC connects them to the From address people see and lets you request enforcement. Major mailbox providers expect all three from anyone sending at volume.

Will p=reject block my legitimate email?

It can if some legitimate sender is not aligned yet, which is why you start at p=none and use aggregate reports to find and fix every source before enforcing.

How do I find my DKIM selector?

Open a message you sent, view its original source or headers, and find the DKIM-Signature header. The s= value is the selector and d= is the signing domain. Your email provider's setup guide also lists it.

Does SPF check the From address?

No. SPF checks the envelope sender (Return-Path). That is why DMARC alignment is needed to protect the visible From address.

Try it yourself

Put this guide into practice with our free tools.

Keep reading

Copied to clipboard