SPF, DKIM, and DMARC are three DNS-based checks that let a receiving mail server decide whether a message really came from the domain it claims. SPF lists which servers may send for a domain, DKIM signs each message cryptographically, and DMARC tells receivers what to do when those checks fail. If your email lands in spam, missing or misaligned records are the first thing to check.
This post explains what each check does, shows how to inspect your own setup with free tools, and gives a step-by-step triage order. FindUtils tools used here: the Email Security Checker, the Email Header Analyzer, the IP Blacklist Checker, the DNS Lookup, and the Reverse DNS Lookup.
Why do mail providers care about authentication?
Mail providers use authentication to separate real senders from impostors. Since February 1, 2024, Google requires all senders to Gmail accounts to set up SPF or DKIM, and senders of more than 5,000 messages per day to set up SPF, DKIM, and DMARC, according to Google's email sender guidelines.
The same guidelines ask senders to keep the spam rate reported in Postmaster Tools below 0.10% and to avoid ever reaching 0.30%. They also require valid forward and reverse DNS for sending IPs, and one-click unsubscribe for marketing mail from bulk senders. Authentication is therefore a baseline, not an extra.
What do SPF, DKIM, and DMARC each check?
Each protocol answers a different question, and none of them replaces the others. The table summarizes them.
| Protocol | Question it answers | Where it lives | Defined in |
|---|---|---|---|
| SPF | Is this server allowed to send for the domain? | A TXT record on the domain | RFC 7208 |
| DKIM | Was this message signed by the domain and left unaltered? | A public key in a TXT record at selector._domainkey.domain | RFC 6376 |
| DMARC | Do SPF or DKIM pass for the domain in the visible From address, and what should happen if not? | A TXT record at _dmarc.domain | RFC 7489 |
A DMARC pass requires that SPF or DKIM passes and that the authenticated domain matches the domain in the From header. That match is called alignment, and it is the most common reason a message "passes SPF" yet still fails DMARC.
How do I check my own domain's records?
Start with the records, because they are public and quick to read. The FindUtils Email Security Checker queries public DNS for a domain's SPF, DKIM, DMARC, MTA-STS, TLS-RPT, and BIMI configuration and marks each as pass, warning, or fail.
Be aware of one limit: DKIM keys are published under a selector name that only the sender knows. The checker tries a short list of common selectors (default, google, selector1, selector2, mail, and dkim), so a "could not verify DKIM" result can simply mean your provider uses a different selector. In that case, find the selector in a real message's headers and query it with the DNS Lookup as a TXT record at selector._domainkey.yourdomain.com.
You can also read the raw records with DNS Lookup: the SPF record is a TXT value starting with v=spf1, and the DMARC record is a TXT value at _dmarc.yourdomain.com starting with v=DMARC1.
How do I read a message's headers?
The headers of a delivered message record what the receiving server concluded. Paste them into the FindUtils Email Header Analyzer to list the routing hops, the IP address at each hop, and the SPF, DKIM, and DMARC results the receiver recorded. The analysis runs in your browser, and the page does not upload the headers.
To get the headers:
- Gmail: open the message, use the three-dot menu, and choose Show original.
- Outlook: open the message, then File, Properties, and read the Internet headers box.
Look for the Authentication-Results line. It states spf=, dkim=, and dmarc= outcomes such as pass, fail, or none, which tells you which layer failed.
A step-by-step triage order
Work from the cheapest, most common cause to the rarest. Each step uses information you can verify in minutes.
Step 1Confirm the three records exist
Run the Email Security Checker on your sending domain. Fix any missing SPF or DMARC record first. If you send through an email service provider, add the include value the provider documents to your SPF record.
Step 2Watch the SPF lookup limit
SPF evaluation is limited to 10 DNS-querying mechanisms, such as include and a, per RFC 7208. Exceeding the limit produces a permanent error, so a record that has grown through years of added services can fail even though it looks correct. Use DNS Lookup on each include: domain to see how many more lookups it adds.
Step 3Send a test and read the headers
Send a message to a mailbox you control, open its original headers, and paste them into the Email Header Analyzer. Check that SPF, DKIM, and DMARC all show pass, and that the domain which passed matches your From domain.
Step 4Check the sending IP
If authentication passes but delivery is still poor, check the IP address. The IP Blacklist Checker queries five public DNS blocklists for an IPv4 address and reports which, if any, list it. Five lists are a subset of the many that exist, so a clean result is useful evidence but not a guarantee. The tool sends the checked address to Google's DNS-over-HTTPS resolver and to each list operator, which its own page states.
Step 5Check forward and reverse DNS
Google's guidelines require sending IPs to have a PTR record and a matching forward record. Use the Reverse DNS Lookup on your sending IP and confirm the hostname resolves back to the same IP in the DNS Lookup.
Step 6Tighten DMARC gradually
A DMARC policy of none only monitors, quarantine asks receivers to treat failures as suspicious, and reject asks them to refuse failures. Start at none with reporting turned on, confirm every legitimate sender passes, and then move to a stricter policy.
Common mistakes
Mistake 1: Publishing two SPF records
A domain must have a single SPF record. Merge all senders into one v=spf1 value rather than adding a second TXT record.
Mistake 2: Assuming SPF passing means DMARC passing
SPF can pass for a different domain than the one in the From header. DMARC needs alignment with the visible From domain.
Mistake 3: Jumping straight to reject
Moving to reject before every legitimate sender is authenticated can block your own mail. Monitor first.
Mistake 4: Ignoring the sending IP
Authentication proves identity, not reputation. A perfectly authenticated message from a poorly regarded or shared IP can still be filtered.
Mistake 5: Trusting a single check
A tool reports what it can see at one moment. DNS changes can take time to reach every resolver, so re-check after an update.
FAQ
Why does my email go to spam even though SPF passes?
SPF passing is only one signal. Receivers also weigh DKIM, DMARC alignment, sending IP reputation, spam complaint rates, and message content.
Do I need all three of SPF, DKIM, and DMARC?
Google requires SPF or DKIM from all senders to Gmail and all three from senders of more than 5,000 messages per day. Setting up all three is the safest baseline.
What does a DMARC policy of none do?
It asks receivers to take no action on failures while still allowing you to receive reports, which is why it is the usual starting point.
Why can't the checker find my DKIM record?
DKIM records live under a selector that your sender chooses. The FindUtils checker tries common selectors only, so find your selector in a message header and query it directly with DNS Lookup.
Does the Email Header Analyzer upload my headers?
No. The analysis runs in your browser and the page makes no lookups with the headers or the IP addresses found in them.
Is the IP Blacklist Checker free?
Yes, it is free and needs no signup. It supports IPv4 addresses only.
Tools used in this post
- Email Security Checker — read SPF, DKIM, DMARC, MTA-STS, TLS-RPT, and BIMI status for a domain
- Email Header Analyzer — trace routing hops and read authentication results from headers
- IP Blacklist Checker — check an IPv4 address against five DNS blocklists
- DNS Lookup — read TXT, MX, A, and other records directly
- Reverse DNS Lookup — confirm a sending IP resolves to a hostname
- DNS Lookup guide — a full walkthrough of record types and caching