DKIM Fails but SPF Passes: What It Means

SPF passed. DKIM still failed. That split matters.

A green SPF result can hide a broken sender. The message may be allowed by the envelope domain, while the DKIM signature is missing, uses the wrong selector, or was broken after the send. Gmail, Outlook, and other mailbox providers can still filter that mail when authentication, reputation, or complaint signals are weak.

SPF checks whether the sending server is allowed for the return-path domain. DKIM checks a cryptographic signature in the message headers. DMARC checks whether SPF or DKIM passed and whether the passing domain lines up with the visible From domain. So SPF pass, DKIM fail can be harmless for DMARC, or it can be the reason the message fails. The difference is alignment.

If SPF passes for a bounce domain like send.vendor.com while the visible From address uses example.com, DMARC may still fail. If SPF passes for example.com or a relaxed aligned subdomain, DMARC can pass even while DKIM fails. The base rules are in RFC 7208 for SPF and RFC 6376 for DKIM. For DMARC, use RFC 9989 for the current core protocol and RFC 9990 for aggregate reports. RFC 7489 is the older DMARC spec many guides still cite.

Why DKIM fails when SPF passes

The usual cause is simple: the sender is allowed by SPF, but it is not signing correctly for your domain.

• DKIM is turned off for that sender. Google Workspace, Microsoft 365, CRMs, billing tools, and email platforms each need their own DKIM setup. One working sender does not cover the others.
• The selector is wrong. DKIM records live at names like selector._domainkey.example.com. If the message says s=mail but DNS only has google._domainkey, the receiver cannot find the right public key.
• The public key in DNS is missing or changed. A copied record can be cut short, pasted under the wrong host name, left behind after a domain move, or replaced during cleanup.
• The message changed after signing. Some forwarders, footers, link wrappers, and gateways alter signed headers or body content. Relaxed DKIM canonicalization can survive small changes, but real content changes can break the signature.
• The wrong domain signed the message. A vendor may sign with its own domain. That can pass DKIM as a raw check, but it does not help DMARC for your From domain unless the DKIM signing domain aligns.
• The key is outdated or too weak for receiver policy. Use your mail provider's current DKIM setup steps and rotate old keys when they tell you to. Do not invent a key by hand.

Check DMARC before you panic

DMARC can pass with aligned SPF or aligned DKIM. One aligned pass is enough under the published DMARC rule, but both paths should work for steady deliverability.

Look at the authentication results for a failed message. Find three fields: SPF result, DKIM result, and DMARC result. Then check the domain shown beside each result. A raw SPF pass is weaker than an aligned SPF pass. A DKIM pass from a vendor domain is weaker than an aligned DKIM pass from your domain.

Your DMARC record sits at _dmarc.example.com. A monitoring record often starts with v=DMARC1; p=none; rua=mailto:dmarc@example.com. The p=none policy tells receivers not to quarantine or reject mail solely because it failed DMARC. The rua tag asks receivers to send aggregate reports. p=quarantine asks them to treat failing mail as suspicious. p=reject asks them to reject failing mail. Use rua reports to see which senders are passing, failing, and aligning before you tighten policy.

Google's sender guidelines and Microsoft's Outlook.com sender policies both focus on SPF, DKIM, DMARC, and alignment. They do not publish every spam rule. The reliable move is to pass and align authentication before chasing smaller issues.

Fix it in this order

Start with the sender that produced the failed header. Do not edit every DNS record at once.

• 1. Identify the sending service. Check the message headers, return-path, sending IP, DKIM domain, and DKIM selector. Match them to the real system that sent the mail.
• 2. Turn on DKIM inside that service. Use the provider's exact host name and TXT value, or CNAME target if that is what the provider gives you. For Microsoft 365 and Google Workspace, confirm DKIM is enabled after DNS has propagated.
• 3. Publish the selector record exactly. The host should look like selector._domainkey under your sending domain. When the provider gives you a TXT record, the value often starts with v=DKIM1. Copy the whole value.
• 4. Confirm SPF alignment. A raw SPF pass is not enough when the passing return-path domain does not align with your visible From domain. Your SPF record should include every real sender and no random extras. End with ~all while you are still finding senders. Move to -all only when all valid senders are known.
• 5. Stay under the SPF 10-lookup limit. SPF mechanisms and modifiers that can cause DNS lookups include include, a, mx, ptr, exists, and redirect. If evaluation needs more than 10 of those terms, SPF returns a permanent error instead of a pass.
• 6. Check DMARC reports. Use rua aggregate reports to see the real senders using your domain. Fix unknown senders, then move from p=none toward quarantine or reject when the data is clean.
• 7. Check MX and replies. MX records are for receiving mail, not SPF or DKIM. Still, make sure replies to your From domain can land somewhere real, and make sure bounce handling is not hiding a bad sender setup.
• 8. Rule out blocklists after auth is clean. If DKIM, SPF, and DMARC pass but mail still goes to spam, check sending IP and domain reputation. A blocklist listing usually points to list quality, compromise, or abuse. Fix the cause before asking for delisting.

What a good result looks like

A healthy domain has two working ways to prove mail is real.

SPF passes for the return-path domain and aligns with the visible From domain. DKIM signs with your domain or an aligned subdomain. DMARC sees at least one aligned pass. Your policy starts at p=none while you watch reports, then tightens when you know every sender is covered.

Use a live check instead of guessing from old screenshots. InboxRadar can read your SPF, DKIM, DMARC, and MX records and show the domain scorecard at the free checker. For the broader checklist, start with the related guides at InboxRadar guides.