SPF, DKIM and DMARC explained: stop your email landing in spam

Email was designed with no way to prove who sent a message. SPF, DKIM and DMARC are the three DNS records that fix that. Together they let a mailbox provider check that mail claiming to be from your domain came from a service you approved.

When they are missing or wrong, your real email gets filtered as suspicious and criminals can send invoices in your name.

How the three records work together

SPF is the guest list, DKIM is a tamper-evident seal, and DMARC is the policy at the door that decides what happens to anyone who fails both.

Alignment: the part most people miss

SPF and DKIM on their own do not check the From address your recipient sees. SPF checks the hidden envelope sender (the Return-Path, where bounces go), and DKIM checks whichever domain signed the message (the d= value in the signature).

DMARC closes that gap with alignment. A message passes DMARC if at least one of these is true:

• SPF passed, and the Return-Path domain matches the From domain.
• DKIM passed, and the signing d= domain matches the From domain.

With the default relaxed alignment, "matches" means the same organisational domain, so bounce.example.com aligns with example.com. That is why a newsletter platform can pass SPF and DKIM yet fail DMARC: it passes for its own domain until you set up DKIM for yours in its settings.

SPF: the list of approved senders

An SPF record is a single TXT record on your domain that starts with v=spf1, lists the servers allowed to send, and ends with a rule for everyone else.

Example SPF records

Google Workspace only:

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

Microsoft 365 only:

v=spf1 include:spf.protection.outlook.com -all

Mailbox at your web host (Hostinger shown; other hosts publish their own include in their email DNS settings, so copy the exact value your control panel gives you):

v=spf1 include:_spf.mail.hostinger.com ~all

Google Workspace plus a newsletter platform and a transactional service, merged into one record:

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

Those are Mailchimp's and SendGrid's includes, shown for illustration. Always copy includes from each provider's current documentation.

Only ever one SPF record

A domain must have exactly one TXT record beginning with v=spf1. When a new service tells you to "add this SPF record", it means add its include to your existing record, not create a second one. Two SPF records produce a permanent error, and SPF then fails for every message, including ones from your main mailbox.

The 10 DNS lookup limit

The standard (RFC 7208) caps evaluation at 10 DNS lookups. The mechanisms that count are include, a, mx, ptr, exists and the redirect modifier. Crucially, lookups inside each include count too. ip4, ip6 and all do not.

Google's include costs several lookups once its nested includes are followed, so a few marketing tools on top can push a domain over. Past 10, the result is a permanent error, which most receivers treat as a fail.

To stay under the limit:

• Remove includes for services you no longer use.
• Drop a and mx unless your website or mail servers genuinely send mail directly.
• Never use ptr; the standard discourages it.
• Move bulk and marketing mail to a subdomain such as news.example.com with its own SPF record. It has its own 10 lookup budget.
• Rely on DKIM for services that support a custom DKIM domain. DMARC only needs SPF or DKIM to align, and many platforms use their own Return-Path anyway.

"SPF flattening" replaces includes with raw IP addresses. Providers change their ranges without notice, so only use a service that updates the record automatically.

~all versus -all

~all (soft fail) says mail from unlisted servers is probably not legitimate. -all (fail) says it definitely is not. Once DMARC is enforcing, DMARC makes the final decision anyway. Use ~all while you are still discovering who sends for you, and -all when you are confident the list is complete. Never use +all: it authorises the entire internet.

DKIM: the tamper-evident seal

DKIM has the sending service sign each message with a private key. The matching public key is published in your DNS, and the receiver uses it to check the signature. A valid signature proves the message came from someone holding your key and was not altered.

Unlike SPF, DKIM usually survives forwarding, because the signature travels with the message.

Selectors

Each key lives at a name made from a selector plus ._domainkey. The selector lets one domain have many keys, one per service. Some common ones:

google._domainkey.example.com  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

DNS cannot list every selector on a domain, so checkers can only try common names. To find yours, open a message you sent, view the original headers, find the DKIM-Signature line and read the s= value (the selector) and d= value (the signing domain).

Two Google gotchas: after publishing the record, click Start authentication in the Admin console. And if your DNS panel rejects the long 2048-bit key, split it into multiple quoted strings in the same record rather than falling back to 1024-bit.

Key rotation

Use 2048-bit keys and rotate them periodically, especially after staff or agency changes. The safe method is to publish a new key under a new selector, switch signing to it, wait a few days for in-flight mail, then remove the old record. Microsoft 365 does this for you by alternating between its two selectors.

DMARC: the policy and the reports

DMARC is a TXT record at _dmarc.yourdomain. It tells receivers what to do with mail that fails alignment, and asks for reports that reveal every service sending as your domain.

_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r"

If the rua address is on a different domain, that domain must publish a small authorisation record. Report services handle this for you.

A safe rollout plan

1. Weeks 1 to 4: p=none with rua. Read the aggregate reports. List every source sending as your domain and fix each legitimate one until it passes SPF or DKIM with alignment.
2. Next: p=quarantine; pct=25. A quarter of failing mail goes to spam. After a week or two of clean reports, raise pct to 50 and then 100.
3. Finally: p=reject. Failing mail is refused outright. This is full protection against exact-domain spoofing.

Keep rua reporting on permanently. Some receivers apply pct values between 0 and 100 inconsistently, and the revised DMARC specification moves away from it, so treat pct as a gentle phase-in rather than a precise dial.

Google and Yahoo sender requirements

In February 2024 Google and Yahoo began enforcing new rules for anyone sending to their users. Microsoft announced similar rules for high-volume senders to Outlook.com in 2025. The core rules are:

• All senders must authenticate with SPF or DKIM (set up both), have valid forward and reverse DNS for sending servers, use TLS, and keep spam complaints low.
• Bulk senders, which Google defines as close to 5,000 or more messages a day to Gmail addresses, must have SPF, DKIM and a DMARC record (p=none is the minimum), and the From domain must align with SPF or DKIM.
• Marketing and subscribed mail from bulk senders must support one-click unsubscribe (the List-Unsubscribe and List-Unsubscribe-Post headers) and honour requests within two days.
• Spam complaint rates, as reported in Google Postmaster Tools, must stay below 0.3%, and Google recommends keeping them under 0.1%.

Reputable newsletter platforms add the unsubscribe headers for you. Publishing your DNS records is still on you.

Common mistakes

• Two SPF records, usually because a new service's instructions were followed literally.
• Over 10 SPF lookups from years of accumulated includes.
• DKIM published but not switched on in the sending service, so mail is still signed with the provider's domain.
• Website forms sending from the web server via PHP mail, which is not in SPF and does not sign with DKIM.
• Forms using the visitor's address in From. That is spoofing someone else's domain and will fail their DMARC. Put the visitor in Reply-To.
• Jumping straight to p=reject without reading reports first.
• Records at the wrong name. Many DNS panels append the domain, so enter just _dmarc, not _dmarc.example.com.

Troubleshooting

Start with the message headers

Send a message to a Gmail address, open it, and choose Show original. Gmail shows SPF, DKIM and DMARC results at the top, and the Authentication-Results header shows which domain each check passed for. This tells you whether the problem is the record, the alignment or the service.

Symptoms and likely causes

For that last row, query the record directly. If public resolvers return the old value or nothing at all, the problem is DNS, not email.

Launching a new site too? See our website launch checklist.

Frequently asked questions