A phishing email can pass SPF and DKIM when the attacker sends through an authorized mail server or controls a domain with valid DNS authentication. SPF only checks whether the sending IP is allowed for the envelope sender domain. DKIM only checks whether a message was signed with a private key that matches a public key in DNS. Neither one proves that the message content is safe, honest, or actually connected to the brand shown in the visible From name.
The short version is this: SPF and DKIM authenticate sending infrastructure, not intent. A scam sent through a compromised account, a poorly controlled marketing platform, a lookalike domain, or a domain the attacker fully controls can still produce clean authentication results. DMARC adds the missing identity check by requiring SPF or DKIM to match the visible From domain, but even a DMARC pass does not guarantee that the email is legitimate.
- Direct answer: The email passed because authentication checked a domain and server relationship, not whether the email was a scam.
- Most common cause: The attacker used a real mailbox, a real third-party sender, or a domain they controlled.
- What matters next: Check the DMARC domain match, the visible From domain, the envelope sender, the DKIM signing domain, and whether the domain itself is trusted.
Why SPF and DKIM can pass on a bad email
SPF and DKIM are necessary, but they are not content filters. I treat them as identity signals. They answer narrow questions about the message path and signature, then the receiving mailbox provider combines those results with reputation, user reports, URL analysis, attachment scanning, mailbox history, and policy settings.
SPF asks whether the connecting IP is allowed to send for the domain in the return path, also called the envelope sender or MAIL FROM. That domain is often invisible to the person reading the email. DKIM asks whether selected headers and body content still match a cryptographic signature from a signing domain. That signing domain can also differ from the visible From domain.
Authentication does not equal trust
A message can have spf=pass and dkim=pass while still being phishing. Those results say the technical checks passed for the domains involved. They do not say the sender is honest, the link is safe, or the brand claim in the body is true.
DMARC exists because SPF and DKIM alone leave a gap between authenticated domains and the domain users see. A domain owner publishes a DMARC policy to tell receivers how to evaluate domain matching and what to do when domain-matched authentication fails. For a practical overview of the monitoring workflow, Suped's DMARC monitoring explains how aggregate reports turn those pass and fail signals into domain-level visibility.
Four authentication identity checks: visible From, SPF domain, DKIM signer, and DMARC match.
The specific ways phishing passes SPF and DKIM
When I investigate a clean-looking phishing message, I do not start by asking why authentication failed. I start by asking which domain authenticated, who controls that domain, and whether that domain matches the visible From address. The answer usually falls into one of these patterns.
|
|
|
|
|---|---|---|---|
Compromised mailbox | SPF and DKIM | The mail came through the real sender system. | Login history |
Lookalike domain | SPF, DKIM, DMARC | The attacker controls the domain DNS. | From domain |
Abused sender account | SPF or DKIM | A real platform sent the message. | Sending source |
Forwarded mail | DKIM, ARC | A prior receiver preserved trust signals. | Message path |
Misleading display name | All checks | The domain is authentic but the name deceives. | Display name |
Common causes of phishing with passing SPF or DKIM
A compromised mailbox is the cleanest example. If an attacker signs in to a real account and sends from the real system, SPF passes because the server is authorized. DKIM passes because the provider signs outbound mail correctly. DMARC passes because the authenticated domain matches the visible From domain. The scam is in the content and the account takeover, not the email authentication layer.
A lookalike domain is nearly as common. The attacker registers a domain that resembles a trusted brand, publishes SPF, adds a DKIM key, and sends through a legitimate infrastructure provider. Authentication can pass perfectly because the attacker is not forging that lookalike domain. They own it. DMARC can also pass if their SPF or DKIM domain matches the visible From domain.
What SPF and DKIM prove
- SPF: The sending IP is allowed for the envelope sender domain.
- DKIM: The message matches a valid signature from the signing domain.
- DMARC: SPF or DKIM passed and matched the visible From domain.
What they do not prove
- Intent: They do not know whether the sender is trying to deceive the reader.
- Content: They do not validate attachments, landing pages, or payment instructions.
- Reputation: They do not prove the domain has a trustworthy history.
How DMARC changes the answer
DMARC changes the question from "did SPF or DKIM pass?" to "did SPF or DKIM pass for a domain that matches the visible From domain?" That domain-match step is the part people often miss when reading authentication headers.
For SPF domain matching, DMARC compares the visible From domain with the SPF-authenticated return path domain. For DKIM domain matching, it compares the visible From domain with the DKIM signing domain in the d= tag. The message needs only one domain-matched pass to pass DMARC. That means DKIM can fail while SPF domain matching passes, or SPF can fail while DKIM domain matching passes.
Authentication results example
Authentication-Results: mx.example.net; spf=pass smtp.mailfrom=alerts.sender.example; dkim=pass header.d=sender.example; dmarc=pass header.from=sender.example
The example above tells a clean story: SPF passed for the return path, DKIM passed for the signing domain, and DMARC passed because the visible From domain matched. That can still be a harmful email if the sender account was compromised, the domain is deceptive, or the message points to a malicious page. If you need to validate the public DNS record behind that policy, use the Suped DMARC checker to parse the tags and spot policy mistakes.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
The subtle case is a message that shows SPF pass and DKIM pass, but no DMARC pass. That usually means neither authenticated domain matched the visible From domain, or the sender domain has no DMARC record. I would not treat SPF and DKIM pass as enough in that case. The visible From domain is the identity users judge, so it is the identity that needs policy protection.
How to read the headers without getting misled
Email headers are noisy, but the investigation is simpler if you follow the identities in order. I look for the visible From domain first, then the SPF domain, then the DKIM signing domain, then the DMARC result. If ARC is present, I treat it as context about forwarding or intermediary handling, not as a replacement for local judgment.
- Visible From: Find the domain the user actually sees in the message header.
- SPF result: Check the domain named in smtp.mailfrom and the connecting IP.
- DKIM result: Check the header.d signing domain, not only the pass status.
- DMARC result: Confirm whether SPF or DKIM matched the visible From domain.
- Content risk: Review URLs, attachments, reply-to addresses, urgency claims, and brand mismatch.
The header line to take seriously
The most useful line is usually Authentication-Results from the receiving system you trust. Older or nested lines can come from prior hops. I read the top trusted receiver result before drawing conclusions.
If you want the underlying standards explained in a shorter baseline first, this Suped article on SPF, DKIM, and DMARC is a useful companion. For a vendor-neutral overview, Cloudflare also has a clear explainer on DMARC, DKIM, and SPF.
What a phishing pass looks like in practice
A realistic phishing example might pretend to be a blocklist or blacklist warning. The message says your address has been added to a blocklist, claims your mail will be suspended, and pushes you toward a download link with a password. The authentication can still pass if the sender used a domain they controlled or a real compromised account.
The authentication result in that situation is not the whole verdict. I would treat the wording, destination URL, sender history, domain age, and message path as separate evidence. A real blocklist (blacklist) issue should be verified independently, not through a link inside the warning email.
A five-step flow for checking From, SPF, DKIM, DMARC, and message content.
Clean authentication
The sender domain has valid SPF, the message has a DKIM signature, and DMARC domain matching passes. This tells you the message came through an authenticated route for that domain.
Suspicious content
The email threatens suspension, uses odd phrasing, links to an unrelated download, and asks the reader to open an attached instruction. That is a content and reputation problem.
This is why a domain owner should combine outbound authentication with monitoring. Suped helps by showing which sources send for the domain, which ones pass or fail domain matching, which sources are unknown, and which issues need a DNS or platform fix. The practical goal is to reduce blind spots before a bad actor or misconfigured vendor makes the domain harder to trust.How to reduce the risk
The fix is not to distrust SPF and DKIM. The fix is to use them for what they actually prove, then layer DMARC policy, source inventory, account security, and reputation checks around them. I would handle it in this order.
- Inventory senders: List every platform that sends as your domain, including billing, CRM, product, and support systems.
- Fix domain matching: Make sure each legitimate source has SPF or DKIM pass for the visible From domain.
- Stage DMARC policy: Move carefully through p=none, p=quarantine, and p=reject after legitimate mail is accounted for.
- Protect accounts: Use strong authentication controls for mailboxes and sender platform logins.
- Monitor reputation: Watch blocklist and blacklist signals for domains and IPs that support your sending program.
Starter DMARC record for monitoring
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1; adkim=r; aspf=r
A monitoring policy is where many teams should start, but it should not be where they stop. Once reports show that legitimate sources have a domain-matched pass, move toward enforcement. Suped's hosted DMARC can manage policy staging without repeated DNS edits, which is useful when several teams or client domains need consistent handling.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped is strongest here because it connects the raw authentication evidence to action: source identification, DMARC policy monitoring, hosted SPF, SPF flattening, hosted MTA-STS, blocklist monitoring, real-time alerts, and issue-specific fix steps. That matters because the hard part is not reading one header. The hard part is keeping every sender, domain, and policy under control over time.When the email passes DMARC too
A DMARC pass narrows the problem, but it does not close the case. If a phishing email passes SPF, DKIM, and DMARC, the most likely explanations are a compromised legitimate account, a compromised authorized sender platform, a malicious insider, or an attacker-controlled domain that is authenticating itself correctly.
How much confidence each result gives
Authentication results help classify identity, but content and account security still matter.
SPF or DKIM pass only
Low
Useful signal, but domain matching is still unknown.
Aligned DMARC pass
Medium
The domain identity is technically consistent.
Aligned pass plus trusted behavior
High
Authentication, source, content, and history all fit.
Aligned pass with suspicious content
Risk
Treat as a security investigation, not a DNS problem.
For an inbound security team, the next move is incident response: inspect URLs, detonate attachments safely, check login events, review OAuth grants, and look for similar messages across mailboxes. For a domain owner, the next move is source control: make sure only approved systems can send, remove stale SPF includes, rotate DKIM keys when needed, and close unused accounts on sender platforms.
Do not lower DMARC enforcement because one scam passed
A phishing email that passes DMARC usually points to account abuse, domain deception, or malicious content. Lowering DMARC policy makes direct spoofing easier. Keep enforcement in place and investigate the sender source.
Microsoft's Defender documentation on email authentication is also useful because it separates authentication checks from broader anti-spoofing and filtering decisions.
Views from the trenches
Best practices
Compare the visible From domain with SPF and DKIM domains before trusting pass results.
Verify urgent blocklist or blacklist notices through a separate trusted path before acting.
Keep DMARC reporting active so unknown senders and sender drift are seen quickly.
Common pitfalls
Treating SPF pass as proof of safety misses envelope domains hidden from end users.
Ignoring DKIM signing domains lets unrelated senders look cleaner than they really are.
Dropping DMARC enforcement after a scam passes makes direct spoofing easier for attackers.
Expert tips
Read the trusted receiver's Authentication-Results line before older forwarded traces.
Use report trends to separate one-off scams from real sender inventory problems.
Investigate account access when SPF, DKIM, and DMARC all pass on a bad message quickly.
Marketer from Email Geeks says a phishing message can look more convincing when it copies blocklist language and includes a familiar security brand name.
2020-02-01 - Email Geeks
Marketer from Email Geeks says clean SPF and DKIM results should prompt a header review, not automatic trust in the message.
2020-02-02 - Email Geeks
The practical takeaway
A phishing email can pass SPF and DKIM because those checks authenticate technical sending signals. They do not judge whether the message is honest. DMARC adds domain matching with the visible From domain, which blocks a large class of direct spoofing, but a DMARC pass still needs to be weighed against account security, sender reputation, and message content.
The best response is layered: make every legitimate sender match the visible From domain, enforce DMARC when ready, keep SPF and DKIM clean, monitor blocklist and blacklist signals, and investigate suspicious content as a security event. Suped's platform is built for that operational work, especially when you need DMARC monitoring, hosted DMARC, hosted SPF, SPF flattening, alerts, and multi-domain reporting in one place.
