Email Authentication

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 hr@brightwell-industries.com. 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:

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 scammer@randomdomain.com. 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.com can 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.