SPF, DKIM and DMARC pass. Why is email still in spam?

What each pass actually means

SPF evaluates whether a sending server is authorised for the envelope-sender domain used in that check. That can be different from the address the recipient sees in From.

DKIM allows a receiving system to validate a signature associated with a signing domain. Merely finding a DKIM-Signature header does not establish that the signature is valid.

DMARC connects authentication to the visible From domain through alignment. It can pass when either SPF or DKIM passes and aligns; both do not have to provide the aligned pass.

These checks answer identity-related questions. They do not measure how useful, expected or relevant the message is to the recipient.

Make sure you’re reading the right result

Messages can carry several Authentication-Results headers because multiple systems handled them. Headers can also contain untrusted or forged text. The receiving system’s trusted result is the important context, not whichever line looks most favourable.

Our header explainer shows the recorded outcomes from a selected block. It deliberately does not choose a trust boundary or verify signatures. Ask an administrator to identify the relevant receiving system when the route is unclear.

Don’t confuse an ARC-related record, an old forwarded result or a signature’s presence with a fresh DMARC evaluation of the message you care about.

Check alignment before making a DNS change

A message can record SPF pass for a service-owned envelope domain without that domain aligning to the visible sender. Similarly, a valid DKIM signature for an unrelated domain is not automatically an aligned DKIM pass.

If DMARC fails, have the administrator compare the visible From domain, the evaluated envelope domain and the signing domain against the applicable alignment policy. Use the exact message and configuration, not an assumed provider setup.

Avoid changing DMARC policy from monitoring to enforcement as a general spam-folder fix. A policy change can affect legitimate sending sources that have not yet been identified.

When authentication is genuinely passing

Move to a different question: what else distinguishes the affected mail? Build a small comparison rather than another list of DNS edits.

• Is the problem confined to one recipient organisation or provider?
• Is it limited to outreach, while expected replies arrive normally?
• Did the list, volume, connection, links or tracking change?
• Is there evidence of complaints, invalid contacts or unexpected account activity?
• Does the same route affect several message versions?

Use confirmed observations where possible. A low open rate is not a reliable way to prove folder placement, and a low reply rate alone does not identify a technical failure.

Test the remaining hypothesis

If your next question is placement, a controlled seed test may be useful. If it is whether the message left Microsoft 365, message trace is more directly relevant. If only an old candidate list performs poorly, investigate the data and its relevance before changing authentication.

Read the test-selection guide to keep those questions separate. Record the original evidence, the change and the comparison outcome.

A useful question for IT

Ask: “For this received message, which Authentication-Results block should we trust, which domain supplied the aligned pass, and what evidence should we inspect next?”

That is more actionable than “all the checkers are green, so why are we in spam?” Use the handoff builder to collect the context without uploading your headers or mailbox data.