Why do phishing emails pass SPF and DKIM checks?
SPF and DKIM answer one question: did this message really come from the domain that claims to have sent it? They do not answer is this message honest? A phishing email sent from an attacker's own domain, or relayed through a legitimate cloud platform the attacker signed up for, will pass SPF and DKIM cleanly — because, technically, nobody forged anything. Authentication verifies identity, not intent.
Quick Takeaways
- SPF checks the envelope sender (Return-Path) domain, not the "From" address a human reads.
- DKIM checks that a signature is valid for the domain in the signature's
d=tag — any domain the attacker controls. - Attackers who register a lookalike domain can publish perfectly valid SPF, DKIM, and DMARC records for it.
- Mail relayed through a legitimate SaaS platform is authenticated as that platform, not as the brand being impersonated.
- DMARC is the only one of the three that ties authentication to the visible "From" address, through alignment.
- DMARC protects the domains you publish it on — it can never stop a phisher using a domain you do not own.
What do SPF and DKIM actually verify?
They verify a domain, and each checks a different domain than the one your users see.
SPF looks at the envelope sender — the MAIL FROM address used during the SMTP conversation, which shows up as Return-Path in the headers. It asks the DNS of that domain, "is this sending IP on your authorized list?" The address a recipient reads in their mail client is the From: header, which SPF never inspects. The two can be completely different domains and SPF will still pass.
DKIM attaches a cryptographic signature to the message. The signature names the signing domain in its d= tag, and the receiving server fetches that domain's public key from DNS to check the signature. A valid DKIM signature proves that the owner of d=attackerdomain.com signed the message and that it was not modified in transit. It proves nothing about the From: header either — and a mismatch between the two is exactly the kind of DKIM alignment failure DMARC exists to catch.
So an attacker who owns a domain, sets up mail for it properly, and sends you a lie has passed both checks honestly. Nothing was spoofed. You can see this yourself: run any domain through an SPF record check or a DKIM check and you are inspecting configuration, not credibility.
Can a phishing domain have valid SPF, DKIM, and DMARC?
Yes, and good ones usually do. Registering netflix-careers-example.com (a lookalike, or "cousin," domain) takes minutes. Publishing SPF, DKIM, and even a strict p=reject DMARC policy on it takes an afternoon. Every authentication check then passes, because every record is genuinely owned and correctly configured by the person who registered the domain.
This is the part that surprises people: DMARC only protects the exact domains you publish it on. Your p=reject policy on yourcompany.com tells the world to discard mail that fails alignment for yourcompany.com. It says nothing about yourc0mpany.com, yourcompany-hr.com, or yourcompany.co. Those are different domains, controlled by someone else, with their own DNS. This is why email impersonation using lookalike domains remains effective against organizations with flawless authentication.
Full DMARC enforcement still matters enormously — it closes the exact-domain spoofing route, which is the cheapest attack of all. It just is not the whole perimeter.
Why does mail sent through a legitimate platform pass?
Because it is legitimate mail — from the platform's point of view.
When a message goes out through a hosted marketing, CRM, or HR platform, that platform signs it with its own DKIM key and sends it from its own authorized IP ranges. Authentication passes for the platform's domain. If the attacker also sets a plausible display name and a From: address on a domain they control, the message arrives fully authenticated, from reputable infrastructure with a clean sending reputation, and lands in the inbox rather than the spam folder.
A campaign disclosed on 6 July 2026 shows the pattern at scale. Security researcher Will Thomas of Team Cymru documented an operation impersonating recruiters at more than 30 well-known brands to steal Google account credentials from marketing professionals, according to BleepingComputer's report. The lures were fake job interviews, complete with the names and photographs of real recruiters at the companies being impersonated. Victims were redirected through legitimate cloud services — a hosted HR platform among them — before reaching a fake hiring page. That page rendered a counterfeit Google sign-in popup entirely in HTML and CSS, a "browser-in-the-browser" technique, to harvest credentials. The operation had reportedly been running for at least five months.
Notice where the defenses were: nothing in that chain required forging a domain. Reputation-based filtering sees a trusted platform. Authentication sees a valid signature. The deception lives in the display name, the redirect chain, and a fake popup — none of which SPF, DKIM, or DMARC can see.
What actually stops authenticated phishing?
Layer controls that judge the message, not just the sending domain.
1. Get to DMARC enforcement first. p=reject on every domain you own — including parked and legacy domains — removes exact-domain spoofing from the attacker's menu and makes lookalikes the only option, which is more expensive and more detectable. Check where you stand with a DMARC record lookup.
2. Watch for lookalike registrations. Monitor for newly registered domains close to your brand. A cousin domain is usually registered days before it is used.
3. Treat display names as untrusted. The friendly name in a mail client is free-text set by the sender. Many gateways can flag external senders whose display name matches an internal person.
4. Flag first-contact and redirect chains. A first-time sender, an unexpected calendar link, or a redirect through several services before a login page are all far stronger signals than an authentication result.
5. Make credential theft survivable. Phishing-resistant MFA (passkeys or hardware keys) breaks the credential-harvesting model even when a user reaches the fake page and types their password.
6. Train for the current lure, not last year's. Recruiting and hiring pretexts, spear phishing against a named individual, and fake sign-in popups all beat "look for bad spelling" advice.
Palisade handles the first layer for you: it takes each client domain from p=none to enforcement automatically, reads the DMARC reports so nobody has to parse XML, and keeps every legitimate sender aligned so enforcement never breaks real mail. Run any domain through the free Email Security Score to see its current posture — SPF, DKIM, DMARC policy, and what an attacker could still do with it today.
Frequently asked questions
If a message passes DMARC, is it safe?
No. A DMARC pass means the From: domain was authenticated and aligned. It is evidence about identity, not intent. Mail from a domain the attacker legitimately owns can pass DMARC perfectly.
Does a p=reject policy stop lookalike domains?
No. Your policy is published in your domain's DNS and applies only to your domain. A lookalike is a separate registration with its own DNS and its own policy.
Can attackers get a valid DKIM signature for my domain?
Only if they can publish a DNS record on your domain or steal your private key. What they usually do instead is sign with a domain they own — which is why alignment, not signature validity, is the check that matters.
Why did the phishing email land in the inbox instead of spam?
Because it was sent from infrastructure with a good reputation and it authenticated correctly. Filters weigh both heavily. Email spoofing that forges a domain is far easier for a filter to reject than an honest message with a dishonest purpose.
Should MSPs still push clients to enforcement?
Yes — it is the single highest-leverage control, and it is finite work with a permanent result. Just be honest with clients that it closes one attack path, not all of them.