--- url: https://findutils.com/blog/spf-dkim-dmarc-explained-why-email-lands-in-spam title: "SPF, DKIM and DMARC Explained: Why Email Lands in Spam" description: "Email landing in spam? Learn what SPF, DKIM, and DMARC check, how to read your own records and headers, and how to triage deliverability step by step." category: security content_type: blog cluster: email-deliverability locale: en read_time: 8 status: published author: "olgunozoktas" published_at: 2026-10-16T21:30:00Z excerpt: "A practical triage for email that lands in spam or bounces: what SPF, DKIM, and DMARC actually verify, how to read a message's headers, and how to check your sending domain and IP." tag_ids: ["email", "spf", "dkim", "dmarc", "deliverability"] tags: ["Email", "SPF", "DKIM", "DMARC", "Deliverability"] primary_keyword: "SPF DKIM DMARC explained" secondary_keywords: ["why email goes to spam", "email authentication check", "dmarc policy explained", "check spf record", "email header analyzer"] tool_tag: "email-security-checker" related_tool: "email-security-checker" related_tools: ["email-security-checker", "email-header-analyzer", "ip-blacklist-checker", "dns-lookup", "reverse-dns-lookup"] updated_at: "2026-10-16T21:30:00Z" og_image: "/images/content/blog/spf-dkim-dmarc-explained-why-email-lands-in-spam-cover-20261017.webp" image_alt: "An envelope carries two checked seals and a third seal marked with a cross, illustrating one failed email authentication check." --- 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](/security/email-security-checker/), the [Email Header Analyzer](/network/email-header-analyzer/), the [IP Blacklist Checker](/network/ip-blacklist-checker/), the [DNS Lookup](/network/dns-lookup/), and the [Reverse DNS Lookup](/network/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](https://support.google.com/a/answer/81126). 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](https://datatracker.ietf.org/doc/html/rfc7208) | | DKIM | Was this message signed by the domain and left unaltered? | A public key in a TXT record at `selector._domainkey.domain` | [RFC 6376](https://datatracker.ietf.org/doc/html/rfc6376) | | 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](https://datatracker.ietf.org/doc/html/rfc7489) | 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](/security/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](/network/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](/network/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 1: Confirm the three records exist Run the [Email Security Checker](/security/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 2: Watch the SPF lookup limit SPF evaluation is limited to 10 DNS-querying mechanisms, such as `include` and `a`, per [RFC 7208](https://datatracker.ietf.org/doc/html/rfc7208). 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 3: Send 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](/network/email-header-analyzer/). Check that SPF, DKIM, and DMARC all show pass, and that the domain which passed matches your From domain. ### Step 4: Check the sending IP If authentication passes but delivery is still poor, check the IP address. The [IP Blacklist Checker](/network/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 5: Check 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](/network/reverse-dns-lookup/) on your sending IP and confirm the hostname resolves back to the same IP in the [DNS Lookup](/network/dns-lookup/). ### Step 6: Tighten 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](/security/email-security-checker/)** — read SPF, DKIM, DMARC, MTA-STS, TLS-RPT, and BIMI status for a domain - **[Email Header Analyzer](/network/email-header-analyzer/)** — trace routing hops and read authentication results from headers - **[IP Blacklist Checker](/network/ip-blacklist-checker/)** — check an IPv4 address against five DNS blocklists - **[DNS Lookup](/network/dns-lookup/)** — read TXT, MX, A, and other records directly - **[Reverse DNS Lookup](/network/reverse-dns-lookup/)** — confirm a sending IP resolves to a hostname - **[DNS Lookup guide](/guides/dns-lookup-guide/)** — a full walkthrough of record types and caching ## Sources - [Google: Email sender guidelines](https://support.google.com/a/answer/81126) - [RFC 7208: Sender Policy Framework (SPF)](https://datatracker.ietf.org/doc/html/rfc7208) - [RFC 6376: DomainKeys Identified Mail (DKIM) Signatures](https://datatracker.ietf.org/doc/html/rfc6376) - [RFC 7489: DMARC](https://datatracker.ietf.org/doc/html/rfc7489)