Email security & phishing analysis

When it applies

Two authorized jobs (tradecraft-scope-roe): (a) defensive — dissect a reported phishing email or BEC attempt, extract IOCs, and recommend tenant controls (defense-* context); (b) offensive — assess whether an in-scope domain can be spoofed (SPF/DKIM/DMARC posture) as findings for a report. Sending simulated phishing is a separate, pentest-only track — load social-eng-methodology first and never run it against a bug-bounty target. Never re-deliver malicious samples to real users, and never mass-test third-party domains.

Why it works

Spoofing succeeds when a domain's authentication records are missing, weak (~all, p=none), or misaligned — the receiving server then has no cryptographic reason to reject a forged From. And even with perfect auth, the display name and Reply-To are unauthenticated, which is what BEC abuses. Reading full original headers exposes the truth the mail client hides.

Method

1. Full original headers ("show original" / view source). Read the Received chain bottom-up — only the hops added by your infrastructure are trustworthy; early hops are sender-supplied. Check From vs Return-Path vs Reply-To consistency and the Authentication-Results header added by the receiving server.
2. Auth records of the sender domain:

   dig TXT example.com                 # SPF — note -all (hard fail) vs ~all (soft) vs missing;
                                       # >10 DNS lookups voids the record entirely
   dig TXT _dmarc.example.com          # DMARC — p=none only monitors; also check sp= (subdomains)
                                       # and rua (reporting); note relaxed vs strict alignment
   dig TXT <selector>._domainkey.example.com   # DKIM — selectors come from the DKIM-Signature header
   

3. Content & URLs. Defang and detonate links in a sandbox (urlscan.io), not in a browser. Compare link text vs href; check lookalike/punycode domains against the real brand.
4. Attachments. Static analysis / sandbox only — never open on a live host; route through defense-malware-triage.
5. BEC pattern check. Display-name impersonation of an exec, urgency + payment/wire/gift-card framing, Reply-To redirected to a free-mail or lookalike domain, thread hijacking.
6. Tenant control review (defensive engagements): anti-phishing policy, external-sender tagging, MFA coverage, and OAuth app consent grants — consent phishing rides legitimate identity providers, so audit authorized third-party apps (ties into web-account-takeover).
7. Weaponize the IOCs — sender addresses, reply-to, URLs/domains, attachment hashes feed defense-detection-engineering / defense-threat-hunting so the finding becomes a detection.

Gotchas

• p=none is not protection — it only reports; likewise ~all lets spoofed mail through as "soft fail". Only -all + p=reject (or quarantine) actually blocks.
• Subdomains are separate — without sp= in the DMARC record, mail.example.com may be spoofable when example.com isn't.
• Display-name spoofing passes every check — auth validates the domain, not the human name. The real signal is the From address domain and Reply-To.
• Missing DKIM selector — you can't query DKIM without the selector; pull it from the DKIM-Signature header's s= tag, or try common ones (google, selector1, default).
• Forwarded mailing lists break SPF legitimately — don't flag a false positive; alignment and DKIM survival matter more there.
• Never click or detonate outside a sandbox, and never send test phishing to third parties without explicit written authorization.

Verify success

A written verdict per domain (SPF policy, DKIM validity, DMARC enforcement + alignment, spoofable yes/no with the exact gap), plus — for sample analysis — a complete IOC list and concrete tenant recommendations, each traceable to a header line or DNS record.

References

RFC 7208 (SPF) / 6376 (DKIM) / 7489 (DMARC); urlscan.io; M365/Google anti-phishing policy docs.

---

Portions adapted from reverse-skill by zhaoxuya520, MIT License.