Why do phishing emails pass SPF and DKIM checks?

When a phishing email changes from an SPF and DKIM pass to a DMARC failure

DMARC evaluates the visible From: domain and requires either SPF or DKIM to pass with an aligned identifier. Alignment means the authenticated SPF domain or DKIM d= domain has the required relationship to the visible From domain.

A phishing email can therefore pass SPF and DKIM but fail DMARC when its authenticated domains differ from the visible From domain. For example, a message can use an attacker-controlled return path and DKIM signature while showing billing@yourcompany.com in the visible From header. SPF and DKIM may each have a technical pass result, but neither aligns with yourcompany.com.

The answer changes when the attacker sends from a domain they own and also uses that same domain in the visible From header. In that case, the message can pass SPF, DKIM, and DMARC. DMARC confirms that the domain in the visible From header authorized the message. It does not establish that the domain is a legitimate business, that a display name is truthful, or that a linked sign-in page is safe.

Use this decision rule:

• If SPF or DKIM passes but the authenticated domain differs from the visible From domain, inspect DMARC alignment.
• If DMARC passes for a lookalike domain, the message is authenticated as that lookalike domain. Evaluate the sender identity, links, recipient context, and security controls separately.
• If mail claims to be from your exact domain but fails DMARC, your published DMARC policy can ask receivers to apply handling to that failure.
• If mail uses a different registered domain, your DMARC policy has no authority over that domain.

Worked header example: valid checks, dishonest purpose

This illustrative example shows why an authentication pass is not a trust verdict:

From: Accounts Payable <invoice@yourcornpany-example.com>
Return-Path: <bounce@yourcornpany-example.com>
Authentication-Results: receiver.example;
  spf=pass smtp.mailfrom=yourcornpany-example.com;
  dkim=pass header.d=yourcornpany-example.com;
  dmarc=pass header.from=yourcornpany-example.com

The domain spelling is the evidence that matters in this example. The sender controls yourcornpany-example.com, so it can authorize an IP for SPF, sign mail with DKIM, and publish a DMARC record. None of those checks make it yourcompany.com.

Compare the exact domains in these fields:

• From: is the identity most mail clients show to the recipient.
• smtp.mailfrom is the SPF identity reported in Authentication-Results.
• header.d is the DKIM signing identity reported in Authentication-Results.
• header.from is the domain DMARC evaluates for alignment.

Do not block or allow mail solely because SPF or DKIM says pass. A pass can be correct while the message still impersonates a person, business function, or brand through a different domain.

What to check next, based on the evidence you have

If you have a suspicious delivered message, inspect its raw headers in the mail system that received it. Look for the receiver-added Authentication-Results field, then compare smtp.mailfrom, header.d, and header.from with the domain the recipient expected. A result from a forwarding service or another intermediary may not reflect the final recipient's assessment.

If you only have a domain name, check its published configuration with Palisade's SPF checker and DKIM checker. A public DNS check can show the record a domain publishes. It cannot prove the production message path, identify the party behind a domain, show a receiver's private filtering decision, or predict future inbox placement.

If the suspicious email uses your exact domain in the visible From header, review your DMARC policy and the aggregate reports for your domain. The email security learning hub covers the controls that complement authentication when the threat is impersonation rather than a direct domain forgery.

Track the senders that still fail alignment

A header review can explain one phishing message, and public SPF or DKIM lookups can show a domain's published DNS. Neither action inventories every legitimate source that sends as your domain or shows which sources later fail DMARC alignment.

Palisade is agent-first DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy stage when the evidence supports it, while your team reviews the evidence and applies any DNS policy change.

Start with Palisade

Palisade does not determine whether an attacker-controlled lookalike domain is trustworthy, guarantee inbox placement, or prove that every future message will authenticate.