The From line in your inbox is a suggestion, not a fact. Anyone can type any name into it. The mail system carries it anyway. I run AliasFleet, a service that gives every website its own forwarding address. SPF, DKIM and DMARC were built to catch forgeries, and each one checks something narrower than most people assume.
Two addresses hide inside every message
Every message carries two sender addresses. You only ever see one.
The first lives in the envelope, the routing instructions servers pass along: under SMTP, the sending server opens with a MAIL FROM command naming the envelope sender, the return path for bounces.
The second lives in the message itself: the From header defined by RFC 5322, the one your mail app shows you and nothing else.
Nothing ties the two together: a server can announce one domain in the envelope, write a different domain in the From line, and the message still counts as valid SMTP. Microsoft's overview of email authentication puts it bluntly: SMTP makes no effort to validate that the claimed sender is who they say they are.
MAIL FROM: <sender@attacker-domain.example>
From: "Your Bank Security" <security@your-bank.example>
Envelope says one domain, screen says another, and you see only the screen. The three checks below each close part of that gap. None closes all of it.
SPF checks the envelope, not the name you see
SPF answers a single question: is this server allowed to send mail for the envelope domain?
The domain owner publishes a DNS TXT record of its authorised sending servers:
v=spf1 include:spf.protection.outlook.com -all
The receiving server looks up the SPF record for the MAIL FROM domain, then checks the sending server against the list. Seven results are possible: pass, fail, softfail, neutral, none, temperror and permerror. Microsoft's SPF setup guide explains the ending: -all is a hard fail for unlisted servers, ~all a soft fail, meaning probably not authorised.
SPF never looks at the From header.
An attacker can register a domain, publish a correct SPF record for it, then send mail with a bank's address in the From line. SPF passes, though it checked the wrong address from your point of view.
Forwarding breaks SPF too: the forwarder becomes the sending server, is not in the original domain's SPF record, and so a genuine message fails.
One more limit. An SPF record gets 10 DNS lookups. If the includes chain into further lookups, the record can burn through the budget and come back a permanent error. A domain gets one SPF record, not several.
DKIM checks the seal, not the sender
DKIM asks something else: was this message changed after it was signed, and who signed it?
The sending domain signs chosen headers plus the body with a private key, the signature rides along in a DKIM-Signature header, and the receiver pulls the matching public key from DNS to check it, as Google's DKIM setup guide describes.
Two tags carry the identity: d= names the signing domain, s= the selector picking the right public key when a domain runs several. Microsoft's DKIM setup guide adds that one message can carry several DKIM signatures, as when a sending service and the customer's domain both sign.
DKIM does not prove the part you care about, because the signing domain need not match the From domain. An attacker can sign with their own domain, put a bank in the From line, and pass. DKIM says nothing about intent either: a valid signature on a phishing message proves it was not altered in transit, not that it is safe.
DKIM has one edge over SPF: forwarding leaves it alone unless an intermediary changes a signed part. A mailing list rewriting a signed subject line, or sticking a footer on a signed body, breaks the signature, which is why the third check exists.
DMARC ties the two checks to the From line
DMARC is the first check that looks at the address you actually see, taking the SPF and DKIM results and adding the requirement both lack: alignment. The domain behind a passing SPF or DKIM check must line up with the From domain: same organisational domain in relaxed mode, identical in strict mode.
A message passes DMARC when at least one aligned check passes, closing the exact hole above: the attacker's own-domain SPF pass and DKIM signature stop helping, since neither aligns with the bank in the From line.
The domain owner publishes a DMARC policy in DNS telling receivers what to do with failures:
v=DMARC1; p=reject; rua=mailto:reports@example.com; pct=100;
The p= tag sets the policy: none reports without acting, quarantine treats the message as spam, reject rejects it. pct= sets the share of failing mail covered, letting a domain ramp from monitoring to enforcement. rua= tells receivers where to send aggregate reports, periodic XML summaries of what passed and failed. Start at p=none, as Google's DMARC setup guide recommends, tightening once the reports show genuine mail authenticating cleanly.
Three limits matter.
First, DMARC does not see lookalike domains: a message from support@your-bank-support.example, display name "Your Bank", can pass every check for its own domain, because DMARC authenticates domains, not visual similarity.
Second, DMARC does not cover display-name tricks, where the attacker puts a trusted name such as 'Your Bank' in the display name while the actual address is their own.
Third, a receiver is not obliged to follow the published policy. RFC 9989 says it may follow the requested handling. Most receivers blend the result with reputation and content signals instead.
A note for readers meeting older references: DMARC now lives in RFC 9989, published on the Standards Track in 2026, obsoleting RFC 7489. The DMARC.org overview records the same change; policies and the alignment model are unchanged.
| Check | What it verifies | What it does not prove |
|---|---|---|
| SPF | Sending server is authorised for the envelope domain | Anything about the From header |
| DKIM | Signed parts were not altered, and who signed them | That the signer matches the From domain, or is trustworthy |
| DMARC | An SPF or DKIM pass aligns with the From domain | Safety, identity of the human sender, or anything about lookalike domains |
The test the protocols do not give you
The protocols verify domains. They cannot tell you who you gave an address to.
Give every service its own email alias, one forwarding address per site, and the address a message arrives at becomes evidence. A message claiming to be from your bank, arriving at the alias you gave only to a bookshop, is forged. Only the bookshop ever had that address. The sender never did. The leak-tracing method works the same way. The To line names the source.
The limits, stated plainly. Aliases do not stop anyone spoofing your own address. They do not prove a sender is genuine. A forged message can still reach the right alias if the attacker knows it or guesses it.
So treat the alias as a tripwire, not a verdict. Pause the alias receiving forged mail. That channel dies. The rest of your mail keeps working. The set-up guide walks through the three methods in about two minutes each, the docs cover product setup, and the pricing page lists the free tier with 10 active aliases.
What the receiver actually does with a failed check
No receiver treats an authentication failure as a single on-off switch.
The result lands in the Authentication-Results header, which records the three verdicts, and then the receiver weighs it against other signals: the sending domain's reputation, your history with that sender, content analysis, resemblance to known phishing patterns. A DMARC failure at p=reject from a trusted domain may still land in spam. A DMARC pass from a brand-new domain with no reputation may still land in spam.
Forwards and mailing lists muddy the picture, because a list that modifies a message breaks DKIM and fails SPF, which can fail DMARC for genuine mail.
ARC, the Authenticated Received Chain, exists for this case. Each intermediary attaches its own signed record of the authentication result it saw, so the final receiver can weigh the original verdict instead of only the broken one. ARC is a chain of testimony, not a fresh verification, and receivers decide how much to trust it.
Google's sender guidelines show the enforcement side: senders to Gmail need SPF or DKIM, bulk senders need all three, and unauthenticated mail may be marked as spam or rejected.
What to do when a spoofed-looking message lands
First, never use the message to check the message. Do not click its links. Do not reply. Do not call any number it prints. Open a fresh tab, type the organisation's address yourself, or open its app. That one habit defeats most spoofing. The forged message needs you inside its version of the world.
Second, look at the headers for evidence. In Gmail, open the message and choose Show original. Google's header guide covers the same step for other providers. Find the Authentication-Results line. A dmarc=fail on a message claiming to be from your bank is strong evidence it is forged. A dmarc=pass is weaker than it looks. Check the From domain is the organisation's real domain, character by character, not a lookalike.
Third, treat urgency as a signal, not a reason. A message claiming your account is locked? Go to the organisation directly. Never click.
Fourth, if you already clicked or entered details, work the breach checklist. Change the password on the real site, and everywhere you reused it. Turn on two-factor authentication. Check Have I Been Pwned for the address. The breach-response guide has the full sequence.
What the checks still leave open
The three checks made exact-domain impersonation harder. They did not make the From line trustworthy. A criminal domain with correct SPF, DKIM and DMARC records passes all three checks for its own domain. The reader sees a convincing display name.
The display name does the heavy lifting. Readers scan the name, not the domain. That is why lookalikes work.
One uncertainty I could not resolve. Receivers do not publish the exact weight they give a DMARC failure against reputation and content signals. No article can rank those inputs with confidence. Receivers combine them. The combination varies by provider and sender history.
That gap stays open, and the reader-side habits above matter more than any single verdict.
Top comments (0)