SPF, DKIM, and DMARC Explained: Why Email Goes to Spam

SPF, DKIM, and DMARC are three DNS records that let a receiving mail server check whether a message that claims to come from your domain was sent with your permission. SPF lists the servers allowed to send your mail, DKIM adds a cryptographic signature to each message, and DMARC tells receivers what to do when neither check passes for the domain in the From line. When these records are missing, broken, or do not match the way your mail is sent, receivers have no way to tell your messages from forgeries, and large mailbox providers can send them to spam or reject them.

Check a domain's SPF, DKIM, and DMARC records Email Check reads the records from DNS and flags common problems. Free, no signup.

Why does email need SPF, DKIM, and DMARC?

The mail protocol, SMTP, does not verify the sender. Any server can connect to a receiver and claim to send mail from any address. The three records let a domain owner publish in DNS which mail is genuine, and let receivers check it before deciding where a message goes.

A message has two sender addresses. The envelope sender (the SMTP MAIL FROM, later copied into the Return-Path header) is where bounces go. The header From address is what the recipient sees. The two often differ, for example when a newsletter platform sends on your behalf.

What is SPF?

SPF (Sender Policy Framework, RFC 7208) is a TXT record published on the domain itself. It lists the servers allowed to send mail with that domain as the envelope sender. The receiver checks the connecting server's IP address against the SPF record of the envelope sender's domain.

ip4 and ip6 list addresses directly, include pulls in another domain's SPF record (this is how you authorize a mail provider), and the final all term says what happens to every server not listed. The prefix on all sets the result: -all is fail, ~all is softfail (suspicious), ?all is neutral, and +all is pass.

SPF has two limits. It checks the envelope sender, which the recipient never sees, so on its own it does not protect the visible From address. It also fails when mail is forwarded, because the forwarding server is not on your list.

What is DKIM?

DKIM (DomainKeys Identified Mail, RFC 6376) has the sending server sign each message with a private key. The signature goes in a DKIM-Signature header, which names the signing domain in its d= tag and a selector in its s= tag. The receiver fetches the public key from DNS at <selector>._domainkey.<domain> and verifies the signature.

The selector is any name the domain owner or mail provider picks, so one domain can hold several keys. A valid signature proves the signed headers and body were not changed after signing and that the signer controls the domain in d=. DKIM signatures usually survive forwarding, where SPF does not. An empty p= tag means the key has been revoked. RFC 8301 requires RSA keys of at least 1024 bits and recommends 2048.

What is DMARC?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a TXT record at _dmarc.<domain>. It was first published as RFC 7489 and is now defined by RFC 9989, a standards-track document, with aggregate reports in RFC 9990. It states a policy for mail that fails and asks receivers for reports.

The p= tag is the policy: none (no special handling, monitoring only), quarantine (treat as suspicious, which usually means the spam folder), or reject (refuse the message). sp= sets a separate policy for subdomains, and rua= is the address that receives aggregate reports, XML summaries of which servers sent mail as your domain and whether it passed. The policy is a request. Receivers make the final call, and RFC 9989 says they must not reject a message on the basis of p=reject alone.

How do SPF, DKIM, and DMARC work together?

DMARC ties SPF and DKIM to the From address the recipient sees. A message passes DMARC when at least one of these is true:

• SPF passes, and the envelope sender's domain aligns with the From domain.
• DKIM passes, and the signing domain (d=) aligns with the From domain.

Alignment is relaxed by default: the two domains only need to share the same organizational domain, so bounces.example.com aligns with example.com. Strict alignment, set with aspf=s or adkim=s, requires an exact match.

Alignment explains why mail can land in spam with SPF and DKIM both passing. If a marketing platform sends your newsletter with its own bounce domain and signs it with its own domain, SPF and DKIM pass for the platform's domain, neither aligns with yours, and DMARC fails. The fix is in the platform's settings: a custom return-path domain on your domain, and DKIM signing with a key published under your domain.

Common SPF, DKIM, and DMARC mistakes

Two SPF records on one domain

This happens when two services each say "add this TXT record". RFC 7208 allows one SPF record per name. With two or more, the result is a permanent error (permerror), and SPF cannot pass for any message. Merge them into a single record with one include per service.

More than 10 DNS lookups in SPF

RFC 7208 section 4.6.4 limits SPF evaluation to 10 terms that need a DNS lookup: include, a, mx, ptr, exists, and redirect. The count includes the lookups inside every included record, and ip4, ip6, and all are free. Going over gives a permerror. Remove services you no longer use, and replace a and mx with address ranges where the addresses are stable.

Ending SPF with +all or ?all

+all authorizes every server on the internet, which turns SPF off. ?all never fails anything. Use ~all or -all; both are valid. RFC 9989 notes one cost of -all: some receivers reject a hard SPF fail during the SMTP conversation, before DMARC runs, so a message with a valid aligned DKIM signature can be refused, and the rejection never appears in your DMARC reports. A domain that sends no mail at all should publish v=spf1 -all, which is what example.com does.

DMARC at p=none, with no rua

p=none asks receivers to change nothing, so forged mail is still delivered. It is the correct starting policy, because its value is the reports. Without a rua tag, RFC 9989 says receivers must not generate aggregate reports for the domain, so a record of v=DMARC1; p=none produces no enforcement and no data. Always include rua, and if the report address is on another domain, that domain has to publish a record authorizing it (report services set this up for you).

A sending service that is not authenticated

Every service that sends as your domain needs either an include in your SPF record with a return-path on your domain, or DKIM signing under your domain. Billing systems and website contact forms that send through their own servers are easy to miss. DMARC aggregate reports list each sending IP address with its SPF and DKIM results, which shows the gaps.

Looking for DKIM under the wrong selector

DNS cannot list a domain's selectors. To find yours, open a message the domain sent, view the full headers, and read s= and d= from the DKIM-Signature header. Email Check tries six common selectors (google, default, selector1, selector2, k1, and mail), so a key it does not find may still exist under another name.

How do you move DMARC from none to reject?

1. Publish p=none with rua. Collect reports and list every source sending as your domain.
2. Fix legitimate senders. Add SPF includes and set up aligned DKIM for each service until its mail passes DMARC.
3. Move to p=quarantine. Failing mail goes to spam instead of being refused, so a missed sender is noticed without mail being lost.
4. Move to p=reject. Forged mail using your domain is refused.

RFC 9989 suggests at least a month at p=none and an equally long period at quarantine, comparing the results before moving to reject. It also warns that p=reject causes problems for domains whose users post to mailing lists, because lists modify messages and break signatures, and that a domain publishing reject must sign its mail with DKIM and not rely on SPF alone. RFC 9989 also drops the old pct tag (apply the policy to a percentage of mail) in favor of a test flag, t=y.

What do Gmail and Yahoo require from senders?

Google's sender guidelines ask every sender to set up SPF or DKIM, have valid forward and reverse DNS for sending IP addresses, use TLS, and keep the spam rate low. Bulk senders must set up SPF and DKIM, publish a DMARC record (Google states the policy can be none), align the From domain with the SPF or DKIM domain, and support one-click unsubscribe for marketing mail. Google says unauthenticated messages might be marked as spam or rejected. Yahoo's sender requirements follow the same pattern: SPF or DKIM for all senders, and for bulk senders both, a DMARC policy of at least p=none that passes, and one-click unsubscribe. The volume that counts as bulk and the spam-rate limit are set on those pages and can change.

Frequently asked questions

My records are correct. Why is my mail still going to spam?

Authentication is one input. Receivers also weigh the sending IP address's reputation, whether it appears on a spam blacklist, its reverse DNS (PTR) name, the content, and how recipients have treated earlier mail. Check the sending IP with Blacklists and its PTR record with DNS Lookup.

How long does a DNS change to SPF or DMARC take to apply?

Resolvers keep the old record until its TTL runs out, so a change can take up to the old record's TTL to be seen everywhere. If there was no record before, resolvers may also remember that for up to the zone's negative-caching time, set in its SOA record. To see the SPF record a resolver returns now, look up the domain's TXT records with DNS Lookup.

Does a subdomain need its own records?

For SPF and DKIM, yes: each name that sends mail needs its own SPF record, and DKIM keys are found under the domain in d=. DMARC is different: when a subdomain has no _dmarc record, receivers use the parent domain's record, which applies its sp= policy, or p= if there is no sp=.