Email & Phishing

Email was designed in 1982, fifteen years before "phishing" was a word. SMTP ships mail with no authentication — any server can connect to any other and claim to be from any domain. The modern defences (SPF, DKIM, DMARC) are all bolted-on checks that answer the question: did the domain in the From: header actually authorise this message? The playground drops you into a triage queue with those verdicts visible; the visualizer puts them in a three-row panel you can flip through email by email.

Why authentication was ever needed

When Alice's server sends mail claiming to be from jamie@acme-corp.com, nothing on the SMTP wire proves that claim. The receiving server could simply trust it — and for twenty years, most did. That trust was worth billions of dollars to spammers, and the industry bolted on three layers of proof:

• SPF (Sender Policy Framework, RFC 7208) — a DNS TXT record at acme-corp.com listing the IPs allowed to send from that domain. The receiving server checks "did this connection come from one of those IPs?"
• DKIM (DomainKeys Identified Mail, RFC 6376) — the sending server signs a canonicalised chunk of the headers + body with a private key. The public key lives at selector._domainkey.acme-corp.com as a DNS TXT. The receiver fetches it and verifies the signature.
• DMARC (RFC 7489) — a policy record at _dmarc.acme-corp.com saying "I require that SPF or DKIM pass and that the passing domain aligns with the From: header. If that's not true, quarantine or reject."

DMARC is the verdict the filter actually enforces. SPF alone doesn't catch forwarding. DKIM alone doesn't catch replay. Alignment is what turns them into "is this really from who it says it's from?"

Reading an Authentication-Results header

A mail gateway stamps its verdict on every inbound message:

Authentication-Results: mx.acme-corp.com;
  spf=pass smtp.mailfrom=figma.com;
  dkim=pass header.i=@figma.com;
  dmarc=pass (p=REJECT aligned=dkim)

Pedagogical shape: one line per mechanism, each with a verdict (pass | fail | softfail | neutral | none) and a short context field (which domain SPF checked, which DKIM selector was used, which DMARC policy applied). The playground's right-hand pane surfaces the same block — click "Show raw header" to see it in full.

Aligned-DKIM is stronger than SPF-based DMARC. A DKIM signature is cryptographic: you can't forge it without the private key. SPF is a list of IPs: anyone renting a Mailchimp server on the same ranges can pass it. When the two verdicts disagree, trust DKIM.

Spotting a phish the receiver didn't catch

Authentication doesn't cover everything. The filter can tell you who sent this, but not whether you should trust what they said. Five things to spot with the naked eye:

1. Display-name spoofing. The display name is free text — "Jamie Chen (CEO)" <ceo-support@randomsender.net> will be rendered as just "Jamie Chen (CEO)" in most clients. Always look at the envelope address.
2. Look-alike domains. rnicrosoft.com vs microsoft.com. acme-cor.com vs acme-corp.com. The look-alike may pass SPF for itself — SPF doesn't prevent registering a similar name.
3. HTML href mismatch. <a href="https://attacker.example">Click here to verify</a> with the visible text showing a trustworthy URL. Hover before clicking; enterprise clients often surface the real href on hover.
4. Urgent + threatening tone. "Your account will be locked in 1 hour." "Wire this today or you'll lose the contract." Urgency is a social-engineering lever. Legitimate processes almost never turn on minutes.
5. Unusual request shape. Gift-cards-as-favour, password resets you didn't trigger, invoice changes from new email addresses. Anything that routes value (money, credentials, access) out of the usual channel is suspect by default.

Triage — choosing the right lever

The playground gives you four actions:

• Release — deliver to the user's inbox. Cheap if the message is legit; catastrophic if it's phish. Never release anything a filter quarantined without reading the headers first.
• User-quarantine — moves the message to one user's Junk folder or personal hold queue. Blast radius: one user. Best default for ambiguous mail and obvious spam.
• Org-quarantine — block the sender or pattern at the gateway for the whole company. Blast radius: everyone. Use when you have high confidence in a phishing campaign hitting multiple users.
• Escalate — file a security ticket. The right answer when a phish is confirmed, especially if it has a payload (attachment, credential form, internal knowledge).

There's a real cost matrix here. Releasing a phish is a direct compromise vector. Org-quarantining legit mail blocks real business. The scoring rubric in the playground rewards the combination that treats each message at its true cost: safer on phish, cheaper on legit, Junk-folder on spam.

Gotchas that trip junior helpdesk

• Forwarded mail breaks SPF but not DKIM. When a user forwards a legit message through personal@gmail.com, the new connection's IP isn't on the original domain's SPF list — spf=fail. DKIM still checks out because the signature covers the original headers+body. A spf=fail, dkim=pass, dmarc=pass (aligned=dkim) triple is the forwarding signature; don't treat it as a phish.
• Mailing lists rewrite the From: header. Many lists replace From: "Alice" <alice@example.com> with From: "Alice via List" <list@openmail.org>. This is deliberate: DMARC strict mode would reject everyone else's mail if the list kept the original From:. Look for List-Id: or List-Unsubscribe: headers.
• Subdomains have their own DMARC policy. acme-corp.com can p=REJECT but marketing.acme-corp.com could p=NONE. The published policy for the domain in From: is what gets enforced.
• DMARC p=none is not a safety net. Half of Fortune 500 domains still publish p=none — meaning DMARC reports failures but doesn't quarantine them. Filter vendors layer heuristics on top; don't assume enforcement.

Real products you'll see in the field

• Microsoft 365 Defender (formerly ATP) — the native Microsoft stack; most corporate email lands here. Its quarantine portal shows an identical SPF/DKIM/DMARC triple.
• Google Workspace / Gmail — built-in filtering, plus the postmaster tools for monitoring your own domain's DMARC reports.
• Proofpoint, Mimecast, Abnormal Security — third-party gateways that sit in front of O365 or Google Workspace, layering reputation, sandboxing, and user-behaviour analytics on top of the standard headers.

Playground and visualizer

The playground pane drops you into an 8-message triage queue. The auth pills on the right-hand pane mirror what your real gateway's admin console shows. Work through the messages, pick a triage action for each, and compare your total against the scoring rubric baked into the level. The visualizer panel shows the same SPF/DKIM/DMARC verdicts as a three-row SVG dashboard — pick an email from the dropdown and read the "overall verdict" banner to internalise what a given DMARC outcome actually means for your trust in the message.