Email Security
Email Authentication
SPF, DKIM, and DMARC: what these security checks do, what "pass" and "fail" mean, and why attackers still get through
For education only. We do not guarantee that this guide is accurate, complete, or up to date. Research the topic yourself and check current, reliable sources before acting.
In this guide
Email authentication is the set of three protocols (SPF, DKIM, and DMARC) that let receiving mail servers check whether a message really came from the domain it claims. The checks verify the technical sender, not the trustworthiness of the domain itself, which is the gap attackers continue to exploit. This article covers what each protocol does, what a "pass" actually proves, and why a perfectly authenticated email can still be phishing.
The Email From HR That Wasn't
Jamal pulled the email that started it all. Manufacturing company. Twelve employees had updated their direct deposit information after receiving what looked like an HR notice.
By the next payday, $86,400 in salary payments had gone to accounts the company didn't control.
The email had come from [email protected]. The company's real domain. The signature matched the HR director's. Nothing looked wrong.
He checked the headers. The email hadn't come from Brightwell's servers at all. First hop was a server in another country. Someone had just typed the HR address in the From field and hit send.
He ran the domain through an authentication check. No SPF record listing approved servers. No DKIM signatures. No DMARC policy.
Their domain was wide open. Anyone could send email claiming to be from Brightwell Industries, and receiving mail servers had no way to know it was fake.
This story is fictional, but the patterns are real.
What does email authentication do?
Because email was designed without identity verification, security experts later created three systems to check if emails are legitimate: SPF, DKIM, and DMARC.
Together, these answer one question: Did this email really come from the domain it claims?
They don't answer: Is this domain trustworthy?
That's the gap attackers exploit.
SPF: Checking the Server
Standard: RFC 7208[2]
What it is: A list of servers allowed to send email for a domain.
How it works: When you send email, it goes through a mail server. SPF lets domain owners publish a list of approved servers. Receiving systems check: "Is this server on the approved list?"
What "pass" means: The sending server is on the approved list.
What it doesn't mean: The email is safe or the domain is legitimate.
Example: If criminals register arnazon-security.com and add their server to the SPF list, emails from that server pass SPF. The check confirms the email came from an approved server for that domain. It can't know the domain is a scam.
The catch most people miss: SPF actually checks the Return-Path (envelope sender) domain, not the visible From address. That's why DMARC adds "alignment." It requires the From domain to match either the Return-Path domain (SPF alignment) or the DKIM signing domain (DKIM alignment). Without alignment, SPF or DKIM can pass for a domain that has nothing to do with what the user sees in the From field.
DKIM: Checking the Signature
Standard: RFC 6376[3]
What it is: A digital signature proving the email wasn't modified.
How it works: The sending server signs a chosen set of headers plus the message body using the domain's private key. Receiving servers verify the signature using a public key published in DNS. If anything in the signed portion changed in transit, verification fails.
What "pass" means: The email was signed by the claimed domain and the signed headers and body haven't been tampered with.
What it doesn't mean: The content is true or the sender is trustworthy.
Example: A criminal sends a phishing email from their own domain with proper DKIM. The signature is valid because they control the domain. DKIM confirms the email wasn't modified in transit. It doesn't know the email is a scam.
DMARC: Enforcing the Rules
Standard: RFC 7489[4]
What it is: A policy telling receiving servers what to do when SPF or DKIM fails.
How it works: Domain owners publish a policy: ignore failures, send failures to spam, or reject failures entirely. DMARC also requires "alignment," meaning the domain in the visible From address must match the domain that passed SPF or DKIM.
The three policies:
| Policy | What happens to failures |
|---|---|
p=none |
Nothing. Monitor only. |
p=quarantine |
Send to spam |
p=reject |
Block completely |
The problem: Most domains use p=none, which provides no protection. Even when authentication fails, the email still arrives.
Why DMARC matters now: Since February 2024, Google and Yahoo have required bulk senders (5,000+ messages per day to consumer accounts) to publish a DMARC policy at the sending domain. The minimum is p=none, so the requirement is effectively a publication mandate rather than an enforcement one, but it pushed millions of previously unprotected domains into the DMARC reporting ecosystem.[5]
How do you read the results?
In email headers, you'll see an Authentication-Results line:
Authentication-Results: mx.company.com;
spf=pass smtp.mailfrom=sender-domain.com;
dkim=pass header.d=sender-domain.com;
dmarc=pass header.from=sender-domain.com
All pass: The email came from the domain it claims. But that domain might be malicious.
Failures: Something didn't verify. Depending on the DMARC policy, the email might still arrive.
Key insight: "Pass" means the technical check succeeded. It doesn't mean the email is safe.
Why do attackers still get through?
Lookalike domains: Register arnazon.com instead of amazon.com. Set up proper SPF, DKIM, and DMARC. All emails from this domain will pass every check.
Unicode and Punycode lookalikes: Attackers also exploit international domain names. The Cyrillic "а" (U+0430) looks identical to the Latin "a" (U+0061), so аmazon.com (with a Cyrillic first letter) renders the same as the real domain in many fonts. Under the hood these are encoded as Punycode (an xn-- prefixed ASCII form), but most email clients display the Unicode form. The attacker's domain is technically different, passes its own authentication, and looks indistinguishable to the reader.
Display name tricks: The From field has two parts: a display name and an address. An email can show "Amazon Security" as the name while the actual address is [email protected]. Many email apps only show the display name. Pretext-driven social engineering leans on this gap, since most users react to the name they recognize before reading the address.
Weak policies: Most domains don't enforce DMARC. Even if authentication fails, the email often arrives anyway.
Account compromise: If attackers steal login credentials for a real email account through phishing or credential stuffing, all their messages have valid authentication because they're using the real infrastructure.
Email replay attacks: DKIM proves an email hasn't been modified since sending. It doesn't prevent that email from being resent to new recipients. Attackers exploit this by getting legitimate services to send them signed emails containing attacker-controlled content, then replaying those emails at scale.
In one attack against an Ethereum developer, the attacker registered an OAuth application with Google using a phishing message as the app's name. Google sent a legitimate security alert about this new app, signed with Google's DKIM key, containing the attacker's phishing text. The attacker then replayed this signed email to targets. It passed every authentication check, appeared in the same Gmail thread as real Google security alerts, and fooled even security experts. Google's own infrastructure had been weaponized against its users.[1]
The key vulnerability: DKIM signatures don't bind to the recipient. The signed To header and body remained the same, so the signature stayed valid even when the message was forwarded to victims who weren't the original addressee.
Key Takeaways
- Authentication verifies the domain, not the intent. SPF, DKIM, and DMARC confirm an email came from where it claims. They can't know if that domain is malicious.
- Lookalike domains pass every check.
arnazon.comcan have perfect authentication because the attacker controls it. - Most domains don't enforce DMARC. Even when checks fail, emails often arrive because policies are set to "monitor only."
- Display names lie. The friendly name you see ("Bank Security Team") can be anything. Always check the actual email address.
- "Pass" is not the same as "safe." Authentication is one signal, not proof of legitimacy.
What's next: Email Investigation covers how to read headers in practice, trace where an email really came from, and preserve evidence properly.
Key Terms
SPF (Sender Policy Framework): A list of servers authorized to send email for a domain.
DKIM (DomainKeys Identified Mail): A digital signature, covering selected headers and the message body, that proves an email hasn't been modified since the signing domain sent it.
DMARC (Domain-based Message Authentication, Reporting, and Conformance): A policy that tells receiving servers what to do when authentication fails.
Authentication-Results: The header showing whether an email passed SPF, DKIM, and DMARC.
Lookalike domain: A domain designed to look like a legitimate one (arnazon.com, paypa1.com).
Display name: The friendly name shown in the From field, separate from the actual email address.
Email replay attack: Resending a legitimately signed email to new recipients; the DKIM signature remains valid because the content wasn't changed.
References
1. All Gmail users at risk from clever replay attack — Malwarebytes, April 2025. Documents the OAuth-app-name DKIM replay attack first reported by Ethereum Name Service lead Nick Johnson.
2. RFC 7208 — Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 — April 2014. Specifies SPF; verifiers check the MAIL FROM identity (envelope sender), not the visible From header.
3. RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures — September 2011. Specifies DKIM; the signature asserts that the signed portion of the message has not changed but, per the spec, "asserts nothing else about 'protecting' the end-to-end integrity of the message."
4. RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC) — March 2015. Defines p=none (monitor only), p=quarantine (treat as suspicious), and p=reject (reject during the SMTP transaction) in §6.3.
5. Email sender guidelines — Google. Requires SPF, DKIM, and a DMARC policy (minimum p=none) for senders of more than 5,000 messages per day to consumer Gmail accounts; effective February 2024.
CHECK YOUR UNDERSTANDING
Email Authentication Quiz
1. You receive a phishing report from an employee. When you check the email headers, you see "SPF: pass, DKIM: pass, DMARC: pass." The employee assumes this means the email is safe. Is that correct?
- Yes, passing all three checks means the email is trustworthy
- No. Passing authentication means the email really came from the domain it claims, but the domain itself could be malicious (like amaz0n-security.com)
- No, it means the checks are broken and should be reconfigured
- Yes, DMARC pass specifically verifies the sender is not a criminal
Show answer and explanation
No. Passing authentication means the email really came from the domain it claims, but the domain itself could be malicious (like amaz0n-security.com)
Email authentication verifies the domain, not the sender's intent. An attacker who registers "amaz0n-security.com" can configure SPF, DKIM, and DMARC perfectly. The email legitimately comes from that domain. Authentication answers "did this domain really send it?" not "is this domain trustworthy?"
2. Your company's domain has DMARC set to "p=none." The security team receives DMARC reports showing that 200 emails per week are failing authentication checks but still being delivered to recipients. A manager asks why those emails aren't being blocked. What's the explanation?
- The emails are being blocked, but with a delay
- p=none means the domain is only monitoring failures, not blocking them. Failed emails still arrive at their destination. Only p=reject would block them.
- DMARC can only block emails on weekdays
- The receiving email servers are ignoring the DMARC policy
Show answer and explanation
p=none means the domain is only monitoring failures, not blocking them. Failed emails still arrive at their destination. Only p=reject would block them.
DMARC p=none is monitor-only mode: it generates reports about authentication failures but takes no action to stop them. Most organizations start here to avoid accidentally blocking legitimate email. The problem is that many never progress to p=quarantine or p=reject, leaving their domain unprotected against spoofing.
3. You receive an email that passes SPF validation, but the visible "From" header shows [email protected] while the Return-Path shows [email protected]. A colleague says this proves the email is spoofed. Are they right?
- Yes, any mismatch between From and Return-Path means the email is spoofed
- No. SPF checks the Return-Path domain, not the visible From. This mismatch is normal when companies use third-party email services. DMARC alignment is what catches this gap.
- Yes, the Return-Path should always match the From header exactly
- No, but only because the email passed SPF
Show answer and explanation
No. SPF checks the Return-Path domain, not the visible From. This mismatch is normal when companies use third-party email services. DMARC alignment is what catches this gap.
SPF validates the Return-Path (envelope sender), not the visible From header. When companies use Mailchimp, Salesforce, or other services to send email, the Return-Path will be the service's domain. This is expected and legitimate. DMARC adds "alignment" checking to catch cases where the visible From doesn't match the authenticated domain.