01 SMTP envelope
MAIL FROM domain
meridian.exampleReceiver connection IP (preview): 198.51.100.25
SPF policy permits 198.51.100.25 and fails other IPs in this example.
✳ Field lesson E1a / 8 min
Email authentication: what SPF, DKIM, and DMARC prove (and what they do not)
Email authentication validates domain provenance, not message safety: SPF checks whether the sending server IP is authorized for the envelope return-path domain, DKIM verifies a cryptographic signature over message headers and body, and DMARC requires the visible From domain to align with a passing SPF or DKIM check.
THE MAILROOM / AN EXPLORABLE MESSAGE
One message.
Three different questions.
Open the envelope. Follow the signature. Find the domain each check actually trusts.
ILLUSTRATIVE MAILROOMPAUSE · OPEN · COMPARE
Compose and sign
The sender chooses the envelope and visible From domains. A signing service may sign selected headers and the body with its domain key.
Payload preview. Receiver receipt is still pending.
SAME MESSAGE / SAME INSTANT
02 Visible identity
From header domain
meridian.exampleThis is the domain DMARC aligns with.
03 DKIM signature
Signing domain, d=
meridian.exampleSelector: mission. Covered: From, Subject, and the complete body.
04 Message content
Next satellite pass: 14:20 UTC. Use the approved mission console.
Current physical payload shown for learning; signing and receipt are separate events.
Sender generated: Next satellite pass: 14:20 UTC. Use the approved mission console.
SPF PENDING
Connecting host check has not completed.
Host → MAIL FROMStrict domain match: pending receiver check.
DKIM PENDING
Signature verification has not completed.
Signed content → d= domainStrict domain match: pending receiver check.
DMARC PENDING
Alignment has not been evaluated.
Aligned SPF pass OR aligned DKIM passThe receiver has not completed authentication. Message safety is a separate question.
Build your own message
Change one condition, replay, then inspect the first different result. Each sending domain has its own authorized origin server; this lab assumes its signing service can use the selected d= key.
Read every message and outcome
An ordinary mission update
Which domain does each check actually authenticate?
- Visible From: meridian.example. MAIL FROM: meridian.example. DKIM d=: meridian.example.
- The sender knows the message it generated. The originating server connects from the domain’s authorized IP.
- Signed content is preserved during transit.
- After receipt, SPF PASS: connecting IP 198.51.100.25; authorized IP 198.51.100.25.
- DKIM PASS: the modeled signature verifies with the published domain key.
- DMARC PASS. SPF and DKIM both supply aligned passes. Strict alignment here requires an exact domain match.
- Safety and human authorship are not established by these checks. This example publishes p=quarantine for failures; actual disposition remains a receiver decision.
Forwarded, bytes preserved
Can DMARC pass when SPF fails?
- Visible From: meridian.example. MAIL FROM: meridian.example. DKIM d=: meridian.example.
- The sender knows the message it generated. A forwarder preserves MAIL FROM and connects from 192.0.2.90, which is not in that domain’s SPF policy.
- Signed content is preserved during transit.
- After receipt, SPF FAIL: connecting IP 192.0.2.90; authorized IP 198.51.100.25.
- DKIM PASS: the modeled signature verifies with the published domain key.
- DMARC PASS. The aligned DKIM pass is sufficient, even though SPF fails. Strict alignment here requires an exact domain match.
- Safety and human authorship are not established by these checks. This example publishes p=quarantine for failures; actual disposition remains a receiver decision.
Body changed after signing
Does a broken signature necessarily make DMARC fail?
- Visible From: meridian.example. MAIL FROM: meridian.example. DKIM d=: meridian.example.
- The sender knows the message it generated. The originating server connects from the domain’s authorized IP.
- A relay changes signed body content after signing, making this modeled DKIM signature fail.
- After receipt, SPF PASS: connecting IP 198.51.100.25; authorized IP 198.51.100.25.
- DKIM FAIL: the signed body changed.
- DMARC PASS. The aligned SPF pass is sufficient, even without a passing DKIM signature. Strict alignment here requires an exact domain match.
- Safety and human authorship are not established by these checks. This example publishes p=quarantine for failures; actual disposition remains a receiver decision.
Forwarded and modified
What happens when neither path can supply an aligned pass?
- Visible From: meridian.example. MAIL FROM: meridian.example. DKIM d=: meridian.example.
- The sender knows the message it generated. A forwarder preserves MAIL FROM and connects from 192.0.2.90, which is not in that domain’s SPF policy.
- A relay changes signed body content after signing, making this modeled DKIM signature fail.
- After receipt, SPF FAIL: connecting IP 192.0.2.90; authorized IP 198.51.100.25.
- DKIM FAIL: the signed body changed.
- DMARC FAIL. Neither mechanism supplies an aligned pass for the visible From domain. Strict alignment here requires an exact domain match.
- Safety and human authorship are not established by these checks. This example publishes p=quarantine for failures; actual disposition remains a receiver decision.
Two passes, wrong domains
Do two authentication passes guarantee alignment?
- Visible From: meridian.example. MAIL FROM: mailer.example. DKIM d=: mailer.example.
- The sender knows the message it generated. The originating server connects from the domain’s authorized IP.
- Signed content is preserved during transit.
- After receipt, SPF PASS: connecting IP 198.51.100.40; authorized IP 198.51.100.40.
- DKIM PASS: the modeled signature verifies with the published domain key.
- DMARC FAIL. Neither mechanism supplies an aligned pass for the visible From domain. Strict alignment here requires an exact domain match.
- Safety and human authorship are not established by these checks. This example publishes p=quarantine for failures; actual disposition remains a receiver decision.
A lookalike passes everything
Does authenticating a lookalike domain make its message safe?
- Visible From: meridian-support.example. MAIL FROM: meridian-support.example. DKIM d=: meridian-support.example.
- The sender knows the message it generated. The originating server connects from the domain’s authorized IP.
- Signed content is preserved during transit.
- After receipt, SPF PASS: connecting IP 203.0.113.25; authorized IP 203.0.113.25.
- DKIM PASS: the modeled signature verifies with the published domain key.
- DMARC PASS. SPF and DKIM both supply aligned passes. Strict alignment here requires an exact domain match.
- Lookalike domain. Authentication can pass for this separate domain; the software request is still suspicious. This example publishes p=quarantine for failures; actual disposition remains a receiver decision.
No DKIM signature
Does DMARC require both mechanisms to pass?
- Visible From: meridian.example. MAIL FROM: meridian.example. DKIM d=: none.
- The sender knows the message it generated. The originating server connects from the domain’s authorized IP.
- The unsigned body is preserved during transit. No DKIM signature is present.
- After receipt, SPF PASS: connecting IP 198.51.100.25; authorized IP 198.51.100.25.
- DKIM NONE: there is no signature to verify.
- DMARC PASS. The aligned SPF pass is sufficient, even without a passing DKIM signature. Strict alignment here requires an exact domain match.
- Safety and human authorship are not established by these checks. This example publishes p=quarantine for failures; actual disposition remains a receiver decision.
A synthetic teaching model: one message, at most one signature, successful DNS lookups, nonempty MAIL FROM, and strict exact-domain alignment (aspf=s; adkim=s). It uses no real mail, keys, or cryptography. Forwarding preserves MAIL FROM here; ARC, SRS, multiple signatures, DNS errors, and relaxed alignment are outside this view. Timing and spatial layers are illustrative. The modeled policy is p=quarantine; the receiver decides actual disposition.
Mechanisms: SPF · RFC 7208, DKIM · RFC 6376, DMARC · RFC 9989.
Helpful first: Networks in one request: DNS, TCP, TLS, and HTTP
Key points
- SPF checks a host against a DNS policy. DKIM checks signed bytes with a public key. DMARC checks alignment of the Author Domain. No check proves that the mail is safe. No check proves that a person wrote the message.
- Distinguish the envelope
RFC5321.(bounce domain), theMailFrom DKIM-Signature d=domain, and the human-visibleRFC5322.header domainFrom - Explain why an attacker’s lookalike domain or a compromised partner mailbox can achieve a full DMARC pass while still delivering a phishing lure
One email message carries three different domain names
Why is email spoofing possible in the first place? Because base SMTP (RFC 5321) was designed in an era without built-in cryptographic identity. Every email message actually carries multiple domain identifiers that do not have to match by default: the SMTP envelope MAIL FROM (the bounce or return-path address used by mail servers), the visible From: header (RFC 5322, what the human recipient sees in their inbox UI), and, when signed, the DKIM signing domain (d=).
One email message carries three different domain names
SMTP envelope MAIL FROM
Visible From: header (RFC5322.From)
DKIM signing domain (d=)
Without email authentication, anyone on the internet can connect to a mail gateway, announce MAIL FROM:<bounce@other., and put From: sloane. in the message headers. SPF, DKIM, and DMARC close that gap by binding DNS policy and public-key cryptography to those three identifiers.
| Protocol | Identifier Checked | Mechanism in DNS | What a Pass Proves | What a Pass Does NOT Prove |
|---|---|---|---|---|
| SPF (RFC 7208) | SMTP Envelope MAIL FROM (and HELO) | TXT record listing authorized sending IPv4/IPv6 ranges and include: mechanisms | The connecting mail server IP is authorized to send on behalf of the MAIL FROM domain | Does not protect the visible From: header; breaks when mail is auto-forwarded |
| DKIM (RFC 6376) | DKIM- header d= domain and s= selector | TXT record at <selector>. publishing the RSA/Ed25519 public key | The signed headers and body hashes were signed by the holder of <d>’s private key and were not altered in transit | Does not prove <d> matches the visible From: header unless DMARC checks alignment |
| DMARC (RFC 7489 / 9989) | Visible From: header (RFC5322.) | TXT record at _ specifying alignment (adkim, aspf), policy (p=none|quarantine|reject), and rua reporting | At least one of SPF or DKIM passed AND its domain aligns with the visible From: domain | Does not prove the sender is honest, cannot block lookalike domains, and cannot stop a compromised real mailbox |
SPF authorizes a host to use the MAIL FROM domain
When a receiving mail gateway accepts an SMTP connection from IP 198. claiming MAIL FROM:<alerts@chronos., the receiver runs Sender Policy Framework (SPF). It queries DNS for the TXT record on chronos. (for example, v=spf1 ip4:198.) and checks whether 198. is on the authorized list.
If the IP matches, SPF returns pass. If the host at 203. connects instead, its IP is not in 198., so - makes SPF return fail. However, notice the blind spot: SPF checks the hidden envelope MAIL FROM domain, not the visible From: header displayed to the user. By itself, an attacker could pass SPF for MAIL FROM:<bounce@attacker. while still displaying From: ceo@chronos. in the inbox.
DKIM ties a signature to bytes
DomainKeys Identified Mail (DKIM) attaches a cryptographic digital signature in the DKIM- header. The sending server hashes the message body and selected headers (From, Subject, Date) and signs that hash with its private key, naming the signing domain (d=chronos.) and selector (s=orb2026).
The receiving mail server queries DNS for orb2026., retrieves the public key, and verifies the signature. If a relay changes the signed body, the computed body hash does not match bh=, and DKIM fails. Unlike SPF, DKIM survives normal email forwarding as long as intermediate relays do not modify the signed headers or body bytes.
DMARC alignment, and a pass is not safe
Domain-based Message Authentication, Reporting, and Conformance (DMARC) ties SPF and DKIM to the human-visible From: header through Identifier Alignment. For DMARC to pass, the message must achieve an aligned SPF pass (where MAIL FROM matches the visible From: domain) OR an aligned DKIM pass (where the DKIM d= domain matches the visible From: domain), under either strict (exact FQDNs match) or relaxed (organizational domains match) alignment. For example, DKIM d=mail. is in relaxed alignment with From: ceo@chronos. because both have the organizational domain chronos..
The domain owner publishes a DMARC policy as a DNS TXT record at _. An example record has v=DMARC1, p=quarantine, aspf=r, and adkim=r. If DMARC fails, the receiver checks the policy, which is p=none to monitor, p=quarantine to route to spam, or p=reject to block delivery. The policy is a preference, and the receiver makes the final decision. Some receivers send aggregate reports to the rua= address. Those reports count mail that passes and mail that fails.
Why DMARC pass never means "safe email" or "verified human"
During incident triage at Meridian, Threat Hunter Nyx frequently hears: "How did this phishing email reach the inbox when SPF, DKIM, and DMARC all passed?" There are two simple reasons. First, if an attacker registers a lookalike domain such as chronos-, sets up their own SPF record, signs mail with their own DKIM key, and publishes their own DMARC policy, then mail from admin@chronos- will achieve a 100% legitimate DMARC pass for chronos-.
Second, if a real vendor mailbox or an internal employee account is compromised via a stolen session token, the attacker sends mail through the real mail servers, which dutifully sign the message with the organization’s real DKIM key. Email authentication proves domain transport provenance, never human identity or payload safety.
A mailing list can cause an authorized message to fail these checks. A forwarder can cause an authorized message to fail these checks. The lesson "Monitor, then enforce" explains the watch before enforcement.
CHECK YOUR JUDGMENT
An engineer at Meridian Space & Robotics (chronos.orbital ) receives an email from support@chronos-orbital-help.net asking them to download a diagnostic patch. The mail gateway logs show spf=pass, dkim=pass, and dmarc=pass for chronos-orbital-help.net . Which conclusion is accurate?
Put your learning to work ↗