DMARC Analyzer

TL;DR

• Phishing is the social-engineering attack class in which an attacker impersonates a trusted party to extract credentials, financial data, session cookies, deliver malware, or trigger fraudulent action. It is the #1 initial-access vector for breaches per the Verizon DBIR (≈80% of breaches involve a human element).
• Phishing > spoofing. Spoofing is one technique a phishing campaign may use. A phishing message may also originate from a legitimately-attacker-owned lookalike domain (with valid DMARC for the attacker), a compromised legitimate account, or a third-party SaaS service the attacker signed up for as the victim brand.
• DMARC at p=reject blocks exactly ONE phishing variant — direct domain spoofing. It does NOT block lookalike-domain phishing, display-name phishing, IDN homograph phishing, cousin-domain phishing, compromised-account phishing, third- party-service phishing, or out-of-band channels (smishing, vishing, quishing).
• The phishing taxonomy has eight canonical variants: mass phishing, spear phishing, whaling (executive-targeted), clone phishing (replicating a real message with a malicious link substituted), HTTPS phishing (lookalike domain with valid TLS), smishing (SMS), vishing (voice call), and quishing (QR code).
• The phishing kill chain has six stages: reconnaissance, weaponization, delivery, exploitation, installation/persistence, and actions on objective. Defender countermeasures attach to each stage; no single control covers the whole chain.
• Adversary-in-the-Middle (AitM) phishing (Evilginx, Modlishka, Muraena, EvilProxy, Tycoon 2FA) proxies the victim session to the real login page and steals both the password AND the OTP / push approval. SMS-OTP and push-notification MFA do NOT stop AitM. Phishing-resistant MFA (FIDO2 / WebAuthn / passkeys) is the only cryptographically-sound defense — the WebAuthn ceremony binds to the origin (real URL).
• NIST SP 800-63B AAL3 mandates phishing-resistant authenticators. CISA, FBI, NSA, and UK NCSC have all issued formal guidance since 2022 to migrate from SMS-OTP / voice-OTP / push-only toward FIDO2 / passkeys.
• The six-layer defense-in-depth stack is: (1) email authentication (SPF / DKIM / DMARC at p=reject), (2) secure email gateway (SEG) with anti-impersonation + URL rewriting + attachment sandboxing, (3) phishing-resistant MFA, (4) conditional access + zero-trust network architecture, (5) endpoint detection & response (EDR), and (6) recurrent user training with simulated phishing exercises.
• The detection workflow combines Authentication-Results header inspection, URL hover-inspection, display-name verification, and behavioural red flags (urgency cues, unusual request, off-channel verification request, requests for OTP / passwords / gift cards / wire transfers).
• Phishing maps to MITRE ATT&CK T1566 with three sub-techniques: T1566.001 Spearphishing Attachment, T1566.002 Spearphishing Link, T1566.003 Spearphishing via Service. Related techniques: T1078 Valid Accounts (post-compromise), T1556.006 Modify Authentication Process: MFA, T1539 Steal Web Session Cookie (the AitM outcome).

1. What phishing is

Phishing is a social-engineering attack in which an attacker impersonates a trusted party — a colleague, an executive, a vendor, a bank, a courier, a tax authority, a SaaS provider, or law enforcement — to extract credentials, financial data, session cookies, multi-factor authentication codes, or to deliver malware, or to trigger a fraudulent action by the recipient (wire transfer, gift-card purchase, MFA approval, granting remote-access). The classic phishing email combines four ingredients:

• A plausible pretext. "Your Microsoft 365 password expires today." "DHL parcel awaiting delivery — confirm address." "Pending invoice from your accounting team." "Action required — verify your account to avoid suspension."
• A forged or lookalike sender. The From: header is spoofed to read a trusted brand, or registered from a lookalike domain (microsoft-security.com, dhl-tracking.info, paypa1.com), or sent from a compromised legitimate mailbox.
• An urgency cue. "Within 24 hours." "Immediate action required." "Failure to verify will result in account suspension." Urgency suppresses reflective thought and triggers System-1 fast-response cognition (per the Kahneman Thinking, Fast and Slow dual-process model).
• A call-to-action. A link to an attacker-controlled landing page, an attachment to open, a phone number to call, a QR code to scan, an MFA push to approve.

Phishing is the #1 initial-access vector for breaches. The Verizon Data Breach Investigations Report (DBIR), published annually, reports that approximately 80% of breaches involve a human element — and the largest single human-element vector is phishing. The Anti-Phishing Working Group (APWG) quarterly reports document millions of phishing URLs per quarter, with the count rising year-over-year. The FBI Internet Crime Complaint Center (IC3) annual Internet Crime Reports document phishing as the most- reported cybercrime category by volume — 298,878 complaints in calendar year 2023 alone.

In MITRE ATT&CK T1566 (Phishing) taxonomy phishing decomposes into three sub-techniques:

• T1566.001 Spearphishing Attachment — phishing message carries a malicious attachment (Office macro, ISO image, LNK shortcut, password-protected archive).
• T1566.002 Spearphishing Link — phishing message carries a malicious URL to a credential- harvesting page, drive-by-download exploit, or AitM proxy.
• T1566.003 Spearphishing via Service — phishing delivered through a third-party messaging service (LinkedIn InMail, Twitter / X DM, Facebook Messenger, Slack, Microsoft Teams, Discord) that is NOT email and therefore NOT covered by SPF / DKIM / DMARC.

Phishing is distinct from spoofing. Email spoofing is the protocol-level technique of forging the apparent sender; phishing is the broader campaign that may USE spoofing as one delivery vector among many. See help_email_spoofing.php for the full spoofing- technique catalogue. Phishing is also distinct from Business Email Compromise (BEC): BEC is the financial-fraud outcome variant of phishing, focused exclusively on wire transfer / invoice / payroll / gift-card fraud. See help_business_email_compromise.php for the BEC operational playbook.

2. The phishing taxonomy (eight canonical variants)

Phishing decomposes into eight canonical variants by audience targeting, delivery channel, and message-construction pattern. Defenders need a vocabulary for each so that incident reports, threat-intel feeds, and SEG rule sets can attribute incoming campaigns to a specific class.

2.1 Mass phishing

Variant: The broadcast-style phishing campaign — the same generic message sent to hundreds of thousands or millions of recipients.

Attacker workflow: Acquire bulk email lists from data-breach dumps or open-source scraping. Compose a generic pretext (IRS tax refund, parcel delivery, Microsoft 365 password expiry, Apple ID verification, Netflix billing). Send via bulletproof-hosted SMTP service or compromised email infrastructure. Conversion rate is typically 3-10% click-through and 0.1-1% credential entry; volume compensates.

Defense: Receiver-side anti-spam classifiers (Bayesian + ML, content- pattern matching, URL reputation feeds, sender-IP reputation) catch 95-99% of mass phishing before inbox delivery. DMARC at p=reject catches direct-domain-spoofed variants. The residual that reaches inboxes is filtered by SEG anti-phishing modules.

DMARC role: Blocks direct-domain-spoofed variants where the attacker forges From: ceo@your-bank.example. Does NOT block lookalike-domain mass campaigns (the attacker registers their-bank-security.com and sends with valid DMARC).

2.2 Spear phishing

Variant: Targeted phishing aimed at a specific individual or small group, tailored after reconnaissance.

Attacker workflow: Open-source reconnaissance against LinkedIn, the company website, press releases, social-media — harvest name, role, manager, colleagues, current projects, vendor relationships, timezone, vacation schedule. Compose a tailored pretext that references real context. Conversion rates jump to 10-30%+ because the message defeats generic "this email is suspicious" pattern-matching.

Defense: Anti-spam classifiers underperform on spear phishing because the volume is low (1 message, not 1 million) and the content is unique. The defense relies on display-name impersonation rules (alert when display name matches a VIP roster but sender address is external), executive-name watchlists at the SEG, mandatory "External Sender" tagging, and user-side training to verify identity via a known-good out-of-band channel before acting on the message.

DMARC role: Identical to mass phishing — blocks direct domain spoofing of the company From: header; does NOT block lookalike or display-name spear phishing. The DMARC-blocked variants represent only a fraction of the spear-phishing surface area.

2.3 Whaling (executive-targeted spear phishing)

Variant: Spear phishing whose target IS the executive — the CEO, CFO, CISO, General Counsel, or board members. Distinct from the BEC variant in which the attacker IMPERSONATES the executive — in whaling, the executive is the victim.

Attacker workflow: The reconnaissance phase is exhaustive — the attacker may scrape the executive's public speaking calendar, conference appearances, recent press quotes, board memberships, and personal social media. The pretext is constructed around timely real context — a board agenda item, a recent public statement, a real upcoming travel itinerary. The payload is high-value: M&A documents, board materials, financial reports, source code, IP, or wire-transfer authority.

Defense: Executive-specific email-security policies — mandatory phishing-resistant MFA enrollment for the C-suite, dedicated SEG quarantine queue monitored by a security analyst, mandatory external-channel verification for any request involving money / sensitive data / system access, restricted public exposure of executive email addresses, executive privacy training.

DMARC role: Identical to spear phishing — blocks direct domain spoofing only; the residual lookalike and display-name surface is the larger threat.

2.4 Clone phishing

Variant: The attacker takes a legitimate message previously received by the target — typically a recurring vendor email, a newsletter, a project status update — and clones it with one specific element substituted (a link, an attachment, a Reply-To header).

Attacker workflow: The attacker must first compromise a legitimate mailbox in the target's communication graph (a vendor, a partner, a colleague) to obtain a sample of a real recurring message. The attacker then duplicates the message with a malicious link or attachment, sends it from a compromised account or spoofed domain, and adds a "resending — please use this updated version" line. The recipient sees a message identical to one they previously received and trusts the "updated version" pretext.

Defense: SEG anomaly detection on identical-content patterns (the cloned message has the same body as a previously-delivered message but a different sender or different link target), Vendor Email Compromise (VEC) detection on compromised-account-originating messages, and user training to verify any "updated version" request via known-good out-of-band channel.

DMARC role: If the clone originates from a COMPROMISED legitimate account at the vendor, DMARC PASSES — the message is signed by the legitimate vendor domain. This is a VEC variant; see help_business_email_compromise.php §6 on Vendor Email Compromise.

2.5 HTTPS phishing

Variant: Phishing in which the landing page is hosted on a domain with valid TLS certificate — the green padlock that historically signalled "trust this site". Modern phishing kits universally deploy valid TLS via Let's Encrypt or similar free CA, so the padlock has zero anti-phishing signal value today.

Attacker workflow: Register the lookalike domain (typically via a bulletproof registrar that ignores trademark takedown requests for hours-to-days), obtain a TLS certificate from Let's Encrypt (free, automated, no validation beyond DNS / HTTP control of the domain), deploy the phishing kit (e.g. 16shop, Caffeine, NakedPages), point DNS at the phishing host.

Defense: URL-reputation feeds (Google Safe Browsing, Microsoft SmartScreen, Cisco Umbrella, OpenDNS, Cloudflare Gateway), browser warning systems, URL-rewriting at the SEG (the SEG replaces every URL in inbound mail with a sandboxed proxy URL that performs reputation lookup at click time), and user training that "the padlock means encrypted, not safe".

DMARC role: DMARC governs the EMAIL DELIVERY only — once the user clicks the link, DMARC is no longer in scope. DMARC does not influence whether the landing-page domain has valid TLS.

2.6 Smishing (SMS phishing)

Variant: Phishing delivered by SMS text message. The attacker impersonates a courier (DHL, UPS, FedEx, USPS, Royal Mail, Deutsche Post DHL), a bank, a tax authority (IRS, HMRC, Finanzamt), or a known service (Netflix, Apple, Amazon, PayPal). The SMS contains a link to a phishing landing page or a phone number to call.

Attacker workflow: Acquire bulk phone-number lists, send SMS via compromised SMS gateways, SMS-as-a-service platforms in jurisdictions with weak enforcement, or via SIM-boxes (banks of SIM cards) installed at low-cost in target countries.

Defense: Carrier-level SMS filtering (T-Mobile Scam Shield, Verizon Call Filter, AT&T Active Armor), mobile-OS link warnings, organisational policies prohibiting credential entry from SMS-delivered links, user training to verify any "your package is held" / "your account is locked" SMS via the known-good URL of the real service (typed into the browser address bar, NOT clicked from the SMS).

DMARC role: ZERO. DMARC is an EMAIL standard; SMS is out-of-band.

2.7 Vishing (voice phishing)

Variant: Phishing delivered by phone call. The attacker impersonates IT support, the bank fraud team, a courier driver, law enforcement, or a colleague, and walks the victim through "verifying" their account.

Attacker workflow: Vishing campaigns typically combine multiple stages — an initial smishing message ("your bank has detected fraud — call this number") routes the victim to the attacker call centre. The attacker walks the victim through "verifying" by entering credentials on a phishing page, reading an OTP aloud, installing remote-access software (TeamViewer, AnyDesk, Quick Assist), or wiring money "to a safe holding account". The 2023 MGM Resorts breach was initiated by a vishing call to the IT helpdesk impersonating an employee — the attacker requested an MFA reset; the helpdesk complied without verifying identity.

Defense: Mandatory call-back via known-good numbers (the bank's number on the back of the credit card, the IT helpdesk number on the company intranet — NOT the number provided in the inbound message), organisational helpdesk policies that require additional verification before MFA reset (manager confirmation, in- person verification, voice-biometric callback), do-not-call registry enrollment, user training that the bank / IT / law enforcement will never call to ask for a password / OTP / wire transfer.

DMARC role: ZERO. DMARC is an EMAIL standard; voice calls are out- of-band.

2.8 Quishing (QR-code phishing)

Variant: Phishing in which the malicious URL is embedded in a QR code image attached to or embedded inline in an email or printed in a physical document. The QR code defeats URL-rewriting at the SEG (the SEG sees an image, not a URL) and routes the victim to the phishing landing page when scanned from the recipient's mobile camera.

Attacker workflow: Embed the QR code in a PDF attachment or inline PNG. Pretext is typically "please scan the QR code with your mobile device to verify your account" or "Microsoft Authenticator setup — scan this QR code on your phone". The mobile device often does not have the same security controls as the desktop, so URL warnings, EDR, and SEG URL-rewriting do not apply at the click moment.

Defense: SEG QR-code OCR scanning (the SEG image-processes inbound attachments, extracts QR codes, decodes the URL, and applies URL-reputation rules), mobile EDR / MDM with URL warnings, user training that legitimate IT will not require a QR-code scan from the corporate desktop to the personal phone, and a published list of organisationally-blessed QR-code contexts (only this specific HR portal sends QR codes for MFA setup, only this specific procurement form uses QR codes for vendor onboarding).

DMARC role: Direct domain spoofing of the message carrying the quishing QR code IS blocked by DMARC at p=reject. The QR code itself is not within DMARC's scope.

3. The phishing kill chain (six stages)

The phishing kill chain is the six-stage model documenting how a phishing campaign moves from attacker preparation to victim exploitation. It is derived from the Lockheed Martin Cyber Kill Chain (CKC) terminology and applied to email-borne campaigns. Defender countermeasures attach to each stage; no single control covers the whole chain.

3.1 Stage 1 — Reconnaissance

Attacker workflow: Harvest target email addresses from LinkedIn, the company website, press releases, conference attendee lists, data-breach dumps (HaveIBeenPwned, Dehashed), Shodan / Censys for exposed services, social-media activity (X / Twitter, Instagram, Facebook), and public DNS for subdomains. Build an organisational chart, identify VIPs, identify finance / HR / IT contacts, identify vendor relationships, identify project names and timelines.

Defense: Reduce attack surface — minimise public exposure of organisational charts, restrict who can publish on the company website without review, require executive-protection training on social-media exposure, monitor data-breach dumps for company-domain credentials, lock down DNS subdomain enumeration where possible.

3.2 Stage 2 — Weaponization

Attacker workflow: Register a lookalike or cousin domain (typically via a bulletproof registrar in a jurisdiction with weak trademark enforcement). Publish valid SPF / DKIM / DMARC for the attacker domain (so the message passes receiver-side authentication). Register a phishing-kit hosting provider (often Namecheap, Hostinger, Cloudflare-fronted bulletproof). Craft the message body + landing page + payload. Configure URL-redirect chains to evade reputation feeds. Provision AitM proxy infrastructure if targeting MFA-protected services.

Defense: Brand-monitoring services (Cybercrime Information Center, Spamhaus DBL, PhishTank, commercial vendors like RiskIQ, ZeroFox, BrandShield) that watch for lookalike-domain registrations against your trademark. Defensive registrations of high-risk variants in your name. Threat-intel feeds that publish newly-observed phishing infrastructure (Cisco Talos, Mandiant, CrowdStrike).

3.3 Stage 3 — Delivery

Attacker workflow: Send the phishing email, SMS, or initiate the voice call. Email delivery uses one of: envelope-From spoofing (defeated by SPF at receiver), From-header spoofing (defeated by DMARC at p=reject), display-name spoofing (NOT defeated by DMARC), or legitimate sending from the attacker domain. The attacker may use compromised SMTP infrastructure, residential botnets, free SMTP-as-a-service tiers, or compromised legitimate accounts.

Defense: Email authentication stack at the receiver — SPF enforcement, DKIM verification, DMARC at p=reject for the recipient's domain. Receiver-side anti-spam classifiers. SEG anti-phishing modules. URL-reputation rewriting at the SEG. Attachment sandbox detonation for executable / Office / ISO / LNK content types.

3.4 Stage 4 — Exploitation

Attacker workflow: The victim clicks the link, opens the attachment, dials the number, or scans the QR code. Credential phishing landing pages prompt for username / password and MFA code. AitM kits proxy the victim session to the real Microsoft 365 / Google / Okta login page in real time and steal both the password AND the OTP / push approval. Malware-delivery phishing executes a payload (Cobalt Strike beacon, IcedID, Qbot, Emotet, Bumblebee, Gootloader).

Defense: Phishing-resistant MFA (FIDO2 / WebAuthn / passkeys) — the WebAuthn ceremony binds to the origin (the real URL the user typed), so an attacker-controlled lookalike URL cannot complete the cryptographic challenge. Conditional access policies that bind the session to a managed device, IP range, or risk score. Browser warning systems (Chrome Safe Browsing, Edge SmartScreen). EDR on the endpoint for malware payloads.

3.5 Stage 5 — Installation / Persistence

Attacker workflow: Exchange captured credentials or session cookies for persistent access — OAuth app consent (the attacker registers a malicious OAuth app and tricks the victim into consenting; the OAuth token persists across password resets), mailbox forwarding rules (the attacker sets up a hidden forwarding rule on the compromised mailbox to exfiltrate future mail), conditional-access bypass via legacy authentication (IMAP / POP3 / SMTP-AUTH that often bypasses modern conditional-access rules), MFA reset via helpdesk social engineering (the MGM Resorts vector), valid-account credentials (MITRE T1078).

Defense: Disable legacy authentication (Microsoft Exchange Online Conditional Access > Block Legacy Authentication; Google Workspace > Less-secure-app access disabled). Monitor for new OAuth consent grants. Monitor for new mailbox forwarding rules. Alert on impossible-travel sign-ins. Enforce conditional access that requires managed device. Helpdesk verification procedures for MFA reset (manager confirmation, in-person verification, voice-biometric callback).

3.6 Stage 6 — Actions on Objective

Attacker workflow: Achieve the campaign goal — credential harvesting (sold on dark-web markets), business email compromise wire fraud, ransomware delivery (the LockBit / BlackCat / RansomHub / Cl0p families typically arrive via initial-access broker re-sale of phishing-harvested credentials), intellectual-property theft, persistent espionage, cryptocurrency theft (Snowflake-style data-warehouse attacks from compromised credentials).

Defense: Data-loss prevention (DLP) on egress channels, EDR on endpoints, network egress filtering, immutable backups for ransomware recovery, paid threat-intel watching for company data on dark-web markets, prompt incident-response activation when any of the upstream stages are detected.

4. How DMARC defends against phishing

DMARC is the email-authentication layer that ties SPF and DKIM to the visible From: header. When deployed at p=reject with aligned SPF and DKIM, DMARC blocks direct domain spoofing — the variant in which the attacker forges the From: header to read an address at your domain without controlling your domain. This is the ONE phishing variant DMARC stops at the SMTP transaction.

Layer: Email authentication at the receiver.

What it stops: Direct domain From-header spoofing where the attacker forges From: ceo@your-company.example without controlling your-company.example. The receiver looks up _dmarc.your-company.example, confirms p=reject, verifies SPF or DKIM authentication AGAINST your-company.example, and rejects the message at the SMTP transaction (or quarantines it under p=quarantine).

What it does NOT stop: See section 5 — DMARC has a substantial gap surface area. The summary: anything that does not forge YOUR domain into the visible From: header is not blocked.

How to deploy: Publish SPF and DKIM for every legitimate sending source first. Publish DMARC at p=none to gather aggregate (RUA) reports without blocking any mail. Analyse RUA reports for unauthorised sending sources, fix legitimate senders, then advance through p=quarantine to p=reject over 4-12 weeks per the rollout playbook in help_dmarc_policy_rollout.php.

The DMARC defense is the foundational layer of the phishing-prevention stack. It is the only layer that operates at the SMTP transaction — before the message reaches the inbox, before the user sees the message, before any human decision is required. Every other layer (SEG, MFA, training) is a downstream control that operates AFTER the message has reached the user. Catching direct domain spoofing at the protocol layer is high-leverage because no human decision is involved.

The canonical DMARC record for production phishing protection is:

_dmarc.your-company.example.  TXT  "v=DMARC1; p=reject; sp=reject;
                                    rua=mailto:dmarc-rua@your-company.example;
                                    ruf=mailto:dmarc-ruf@your-company.example;
                                    fo=1; adkim=s; aspf=s; pct=100;
                                    np=reject"

See help_dmarc_records_explained.php for the tag-by-tag reference. Key choices: p=reject for the apex policy, sp=reject for the subdomain policy (blocks subdomain-spoofing variants), np=reject for the never-existed- subdomain policy (RFC 9091; blocks attacker-registered subdomains on otherwise unused subdomain space), fo=1 for failure reports on any authentication failure, and strict alignment (adkim=s aspf=s) to prevent organizational-domain inheritance from weakening the policy.

5. What DMARC does NOT stop

DMARC at p=reject is foundational but insufficient for phishing prevention. The defender must understand exactly which phishing variants DMARC leaves uncovered so that downstream controls can be sized accordingly:

• Lookalike-domain phishing. The attacker registers your-company-security.com, publishes valid SPF / DKIM / DMARC for the attacker domain, and sends with green-checkmark authentication. DMARC for your-company.com cannot defend against messages that do not claim to be from your-company.com.
• Display-name phishing. The attacker uses From: "CEO Name" <ceoname.urgent2024@gmail.com>. The From: domain is gmail.com (legitimately attacker-controlled) and passes its own DMARC. The display name "CEO Name" is a free-text field with no protocol verification.
• IDN homograph phishing. The attacker registers vіctim.example using Cyrillic і (U+0456) instead of Latin i. The Punycode form is xn--vctim-3vd.example — technically distinct from victim.example. DMARC passes for the IDN domain.
• Cousin-domain phishing. The attacker registers your-company.co (different TLD from .com), your-company-help.com, or get-your-company-support.com. Each is a different valid domain.
• Compromised-account phishing. The attacker has stolen credentials for real-employee@your-company.example and sends FROM that mailbox. DMARC passes because the authentication is legitimate. This is the Vendor Email Compromise (VEC) variant; see help_business_email_compromise.php §6.
• Third-party-service phishing. The attacker signs up for a marketing SaaS (MailChimp, SendGrid, Constant Contact) as YourCompany Marketing, the SaaS DKIM-signs and SPF-authenticates from the SaaS sending infrastructure, and the message passes DMARC because the attacker is sending from a different domain entirely (the SaaS-bounce-handling domain).
• Out-of-band channels. Smishing (SMS), vishing (voice), quishing (QR code), Slack / Teams / LinkedIn direct messages, WhatsApp, Telegram, in-person. DMARC is an email standard and provides ZERO defense outside of email delivery.
• Display rendering attacks beyond display name. Unicode bidirectional override (RTL override) attacks that visually mangle the rendered From: address. Some mail clients (notably older Outlook versions) render these unsafely.

The gap surface area is large. Each gap requires a different downstream control — see sections 6-11 for the defense-in-depth stack.

6. Secure email gateway (SEG) anti-phishing controls

The secure email gateway is the second defense layer — operating AFTER DMARC at the receiver but BEFORE inbox delivery to the user. Examples: Microsoft Defender for Office 365, Google Workspace anti-phishing controls (Advanced Protection + BeyondCorp), Proofpoint Email Protection, Mimecast Email Security, Abnormal Security, Avanan, IRONSCALES, Sublime, Material Security, Trustifi.

Layer: Receiver-side message scanning between SMTP receipt and inbox delivery.

What it stops: Lookalike-domain detection (alert when sender domain is one edit-distance from a known partner / executive domain), display-name impersonation rules (alert when display name matches VIP roster but sender address is external), URL rewriting (replace every URL in inbound mail with a sandboxed proxy URL that performs reputation lookup at click time), attachment sandbox detonation (execute Office macros, ISO contents, LNK shortcuts in a sandbox before delivery), reputation feeds (IP reputation, URL reputation, file-hash reputation, Bayesian content-pattern scoring), header anomaly detection (Reply-To mismatch, unexpected Received chain, X-Mailer signature mismatch).

What it does NOT stop: Zero-day phishing kits before reputation feeds catch up (the first hour of a campaign — particularly clone phishing from compromised vendor accounts where reputation is legitimate), out-of-band channels that bypass email entirely.

How to deploy: Treat SEG as a layer ABOVE the native email platform's built-in filtering — Microsoft 365 + a third-party SEG, or Google Workspace + a third-party SEG. Configure executive-name watchlists with the company VIP roster. Enable URL rewriting for ALL inbound mail. Enable attachment sandboxing for executable / Office / ISO / LNK / RAR / 7z content types. Configure DMARC-failure quarantine actions (don't silently drop; quarantine for analyst review). Monitor false-positive rates and tune rules quarterly.

7. Phishing-resistant MFA (FIDO2 / WebAuthn / passkeys)

Phishing-resistant MFA is multi-factor authentication that uses cryptographic device-bound credentials which the user cannot inadvertently disclose to an attacker over a phishing page. It defeats Adversary-in-the-Middle (AitM) phishing kits that have made SMS-OTP, voice-OTP, and push-notification MFA broadly inadequate against modern phishing.

Layer: Authentication ceremony at the relying party (the actual login service).

What it stops: Adversary-in-the-Middle (AitM) phishing — even if the user enters credentials on a phishing page, the WebAuthn ceremony binds to the origin (the actual URL the user typed) via the Relying Party ID. An attacker- controlled lookalike URL CANNOT complete the cryptographic challenge because the origin does not match. The attacker cannot replay the WebAuthn assertion against the real service because the assertion is bound to the lookalike origin, not the real one.

What it does NOT stop: Helpdesk social-engineering attacks that bypass MFA entirely (the MGM Resorts vector). Lateral movement after credential capture from a non-MFA-protected service. Out-of-band channels.

How to deploy: The two canonical implementations are:

• FIDO2 / WebAuthn hardware security keys — YubiKey (5 series), SoloKey, Feitian, Google Titan, OnlyKey. The user plugs the key into USB-A / USB-C / Lightning or taps NFC against a mobile device to complete the challenge.
• Passkeys — FIDO2 credentials stored in the operating-system keychain. Apple iCloud Keychain (sync across Apple devices), Google Password Manager (sync across Chrome / Android), Microsoft Account (sync across Windows / Edge), 1Password, Bitwarden, Dashlane. The user authenticates with Face ID / Touch ID / Windows Hello / PIN, and the OS performs the WebAuthn ceremony on the user's behalf.

NIST SP 800-63B Authenticator Assurance Level AAL3 mandates phishing-resistant authenticators. Federal agencies (under CISA Binding Operational Directive 18-01 and the May 2021 Executive Order 14028 on Improving the Nation's Cybersecurity) are migrating to FIDO2 / passkeys. CISA Cybersecurity Advisory AA22-279A (October 2022) documents AitM attacks and recommends phishing-resistant MFA. UK NCSC, Australian ASD, and BSI (Germany) have issued analogous guidance.

Deployment priority: Roll out phishing-resistant MFA to the C-suite first (whaling target audience), then to IT / security / finance / HR (high-value account audience), then to all employees. SMS-OTP and push-only MFA should be EXPLICITLY DEPRECATED for any account with sensitive access.

The 2022 Cloudflare incident documented exactly this defense in action. Cloudflare was targeted by the same Twilio-style AitM phishing campaign that compromised Twilio, Okta, and others. Cloudflare staff who had FIDO2 keys could not be phished — the cryptographic origin binding defeated the AitM proxy. Staff on SMS or push MFA were phished. Cloudflare published the public post-incident report documenting both what worked (FIDO2 keys) and what did not (push MFA).

8. User-side red flags and training

User training is the last line of defense — after DMARC, after SEG, after MFA. It is not the strongest layer (any layer that depends on human judgment is weaker than a layer that operates at the protocol level), but it is the layer that catches the residual phishing that gets through all upstream controls. Effective phishing training combines simulated phishing campaigns with periodic refresher education on red flags.

8.1 Message-content red flags

• Urgency cues. "Within 24 hours." "Immediate action required." "Failure to verify will result in account suspension." Urgency suppresses reflective thought.
• Unusual sender requests. The CEO requesting a wire transfer outside the normal procurement workflow. HR requesting your direct-deposit bank details via email. IT requesting your password.
• Off-channel verification refusals. The message includes explicit "do not call my office number — I am in a meeting" or "do not forward this — it is confidential" or "respond only via the link below — do not reply to this email".
• Generic greetings. "Dear Valued Customer" / "Dear User" when the legitimate service knows your name.
• Pretexts that bypass authority. "Skip the procurement system for this one — board-approved exception." "Use a personal phone instead of the company line." "Don't mention this to anyone."

8.2 Sender-field red flags

• Display-name vs From-address mismatch. "CEO Name" <ceoname.urgent2024@gmail.com> — display name claims executive, address is free webmail.
• Punycode / IDN homograph. Raw header shows xn--vctim-3vd.example; rendered name looks like victim.example.
• Reply-To mismatch. From: header is one address; Reply-To is a different attacker-controlled address.
• External-sender tag missing or inconsistent. Most SEGs add an "External Sender" tag to inbound mail; the absence of the tag (or unexpected presence) is a red flag.

8.3 URL red flags

• Hover-mismatch. Hover (do NOT click) the link; the displayed anchor text is one URL, the actual href is another.
• Unfamiliar TLD. Legitimate Microsoft URLs end in microsoft.com / microsoftonline.com / live.com / office.com / microsoft365.com / sharepoint.com / office365.com / azure.com; a URL ending in microsoft-365-security.info / msftlogin.online / login-microsoft.click is a red flag.
• URL-shortener obfuscation. bit.ly / tinyurl / t.co / lnkd.in hiding the destination.
• Punycode / IDN in URL. xn-- prefix in the displayed URL.

8.4 Simulated-phishing training

The canonical training tool is the simulated phishing campaign — KnowBe4, Cofense PhishMe, Hoxhunt, Microsoft Defender Attack Simulator, Google reCAPTCHA Enterprise, Proofpoint Security Awareness. The training pattern is: send a realistic phishing email to all employees on a randomised schedule, track who clicks, deliver just-in-time training to clickers, report click rate trends to leadership, identify repeat clickers for targeted intervention. The industry benchmark click rate for first-time training is ≈10-30%; after 12-24 months of quarterly campaigns the rate typically drops to 1-5%.

9. Detecting a phishing email forensically

The forensic detection workflow combines Authentication-Results header inspection (per RFC 8601), URL hover-inspection, display-name verification, and behavioural indicators. This is the workflow used by the SOC analyst when an employee reports a suspicious email, and by the incident-response team when a campaign is detected post-click.

9.1 Step 1 — View raw message source

• Outlook desktop: File > Properties > Internet headers.
• Outlook web: Open message > "..." menu > View > View message source.
• Gmail: Open message > three-dot menu > Show original.
• Apple Mail: View > Message > Raw Source.
• Thunderbird: Other Actions > View Source.

9.2 Step 2 — Inspect Authentication-Results

The Authentication-Results header (RFC 8601) records the receiver-side verdict:

Authentication-Results: mx.google.com;
       spf=fail (google.com: domain of bounce@phisher.example
                 does not designate 198.51.100.42 as permitted sender)
                 smtp.mailfrom=bounce@phisher.example;
       dkim=none (no signature);
       dmarc=fail (p=REJECT sp=REJECT dis=REJECT)
                  header.from=your-company.example

Key fields to check: dmarc= verdict (pass / fail / temperror / permerror), header.from= domain (must match the displayed From: address), spf= verdict, dkim= verdict. A dmarc=fail on inbound mail claiming to be from your domain is the smoking gun for direct domain spoofing.

9.3 Step 3 — Inspect From: header for IDN homograph

Look at the raw From: header (not the rendered version). Punycode-form (xn--) is a strong indicator. Visually-identical Cyrillic / Greek substitutions in the displayed glyphs are the IDN homograph red flag — Cyrillic а vs Latin a, Cyrillic е vs Latin e, Cyrillic о vs Latin o.

9.4 Step 4 — URL hover-inspection

Hover (do NOT click) every link. Inspect the actual href target shown in the browser status bar or mail-client tooltip. Mismatch between displayed link text and actual target is the classic phishing signature. If the SEG has rewritten URLs, the rewritten URL is the SAFE form — it routes through the SEG's URL-reputation proxy.

9.5 Step 5 — Reply-To header

A phishing campaign often sets the Reply-To header to an attacker-controlled webmail address while the From: header looks legitimate. The Reply-To header determines where REPLIES go, not where the message claims to be FROM.

9.6 Step 6 — Received chain

The Received: header chain documents every relay hop. Unexpected hops (a message claiming to be from your CFO that traversed a bulletproof-hosted SMTP relay in Eastern Europe before landing) are a red flag.

9.7 Step 7 — Attachment inspection

Attachments to scrutinise: .htm / .html (often credential-harvesting forms that execute locally), .iso / .img (mount as drive, deliver LNK / EXE), .lnk (shortcut files with hidden PowerShell command lines), .js / .vbs / .wsf (scripts), password-protected .zip / .rar / .7z (sandbox-evasion via password requirement), .docm / .xlsm / .pptm (macro-enabled Office documents).

The DMARC Analyzer Email Header Analyzer automates steps 1-7 against a pasted raw header dump — surfacing the Authentication-Results verdict, IDN / Punycode form detection, Reply-To mismatches, Received chain anomalies, and DKIM signature validation. Paste the full raw header from any suspicious message into the tool and review the forensic verdict before deciding whether the message is phishing.

10. Real-world phishing examples

Publicly-documented phishing incidents that map onto the eight-variant taxonomy and the six-stage kill chain. Each illustrates how a specific phishing variant succeeded and what defensive control was missing.

10.1 The Google + Facebook USD 100M BEC (2013-2015)

Evaldas Rimasauskas, a Lithuanian citizen, impersonated Quanta Computer — a Taiwanese hardware vendor that both Google and Facebook used — by registering a Latvian shell company under the name "Quanta Computer" and sending invoices to Google and Facebook accounts-payable departments. Over two years, the campaign extracted approximately USD 23M from Google and USD 75M from Facebook. The invoices were sent from a lookalike domain controlled by the attacker. DMARC would not have helped — the messages came from an attacker domain with valid authentication. The missing control: out-of-channel verification with the real vendor (a call to Quanta's actual accounts-receivable team) before paying invoices for new bank account details. Rimasauskas was extradited to the U.S., pleaded guilty in 2019, and sentenced to 5 years in federal prison.

10.2 Twitter Vishing Breach (July 2020)

Attackers used a vishing campaign against Twitter customer-support employees, impersonating Twitter IT support during the COVID-era work-from-home pattern. The attackers obtained credentials to internal Twitter admin tools and used them to take over high-profile accounts (Barack Obama, Joe Biden, Elon Musk, Bill Gates, Apple, Uber) and post a cryptocurrency-scam tweet that extracted approximately USD 121,000 in Bitcoin from followers. DMARC was not in scope — the attack was vishing (voice), not email. The missing controls: phishing- resistant MFA for internal admin tools (instead of SMS-OTP), helpdesk verification procedures, and dedicated executive-account access policies. The primary attacker, Graham Ivan Clark, was 17 years old.

10.3 Uber Push-Bombing Breach (September 2022)

The Lapsus$ group (now-disbanded) compromised an Uber contractor by purchasing credentials on the dark web, then push-bombed the contractor with continuous Microsoft Authenticator push notifications until the contractor approved one out of fatigue. The attacker then contacted the contractor via WhatsApp impersonating Uber IT and asked them to approve the push to "stop the notifications". The contractor approved. The attacker obtained corporate VPN access and laterally moved to Uber's GCP, AWS, OneLogin, Slack, and HackerOne accounts. The missing controls: phishing-resistant MFA (FIDO2 keys would have defeated push-bombing because the cryptographic challenge cannot be completed by an attacker), number-matching push (the user must enter a number displayed on the login page into the push notification), and conditional access blocking impossible-travel sign-ins.

10.4 MGM Resorts Vishing Breach (September 2023)

The Scattered Spider / Octo Tempest group placed a vishing call to the MGM Resorts IT helpdesk impersonating an employee they had identified on LinkedIn and Facebook. The attacker requested an MFA reset; the helpdesk complied without verifying identity beyond the publicly-available name and birthday. The attacker obtained access, escalated to ransomware deployment by the BlackCat / ALPHV affiliate. The estimated impact was USD 100M+ in operational disruption. DMARC was not in scope — the attack was vishing, not email. The missing controls: helpdesk verification procedures (manager confirmation, voice- biometric callback, in-person verification, callback to the known-good employee phone number), and phishing-resistant MFA for any account with privileged access.

10.5 Snowflake Customer Credential Theft (2024)

Attackers (UNC5537, attributed by Mandiant) obtained Snowflake customer credentials from infostealer-malware-infected personal devices belonging to Snowflake customer employees who had reused credentials across personal and work accounts. Snowflake itself was not breached — Snowflake DID NOT MANDATE MFA for customer accounts. Affected customers included Ticketmaster, Santander, Advance Auto Parts, AT&T, Neiman Marcus, and others. Hundreds of millions of customer records were exfiltrated. DMARC was not in scope — the credentials came from infostealer-infected personal devices, not phishing. The missing controls: mandatory MFA at the SaaS-platform level (Snowflake later mandated MFA by default), credential reuse detection, infostealer detection at the endpoint, conditional access policies binding the session to a managed device.

10.6 The AitM Microsoft 365 Campaign (2022-ongoing)

Continuing campaigns by multiple threat groups (Storm-1167, Storm-1283, Octo Tempest, others) use AitM phishing kits (Evilginx2, NakedPages, Tycoon 2FA, Mamba 2FA, ONNX Store) to harvest Microsoft 365 credentials AND MFA codes via reverse-proxy phishing pages. The campaigns send a credential-harvesting phishing email (often impersonating Microsoft, DocuSign, Adobe, or a known vendor); the victim enters credentials on the AitM proxy; the kit replays to the real Microsoft 365 login; both the password and the MFA token / push approval are captured; the kit exfiltrates the session cookie. The attacker pastes the cookie into their own browser and bypasses MFA. DMARC blocks the direct-domain-spoofing variant of the lure email; SEG URL-reputation feeds catch known phishing infrastructure; phishing-resistant MFA (FIDO2 / passkeys) defeats the AitM ceremony entirely.

11. Defense-in-depth recommendations (six-layer stack)

No single control stops every phishing variant. The six-layer defense-in-depth stack is the canonical phishing-prevention architecture:

11.1 Layer 1 — Email authentication (SPF / DKIM / DMARC at p=reject)

• Publish SPF for every legitimate sending source; keep the SPF record under the RFC 7208 10-DNS-lookup limit (see help_spf_lookup_limit.php).
• Publish DKIM for every legitimate sender; rotate keys every 6 months (see help_dkim_key_rotation.php).
• Publish DMARC at p=reject sp=reject np=reject adkim=s aspf=s pct=100 with monitoring (RUA + RUF) addresses.
• Apply identical hardening to every parked / non-sending / brand domain owned by the organisation (the parked-domain pattern from help_dmarc_multi_domain_strategy.php).

11.2 Layer 2 — Secure email gateway (SEG) anti-phishing

• URL rewriting on all inbound mail.
• Attachment sandbox detonation for executable / Office / ISO / LNK / RAR / 7z content types.
• Display-name impersonation rules with executive watchlist.
• Lookalike-domain detection (edit-distance alerts against partner / executive domains).
• External-sender tagging on every inbound message.
• Vendor Email Compromise (VEC) detection on compromised-account anomalies.

11.3 Layer 3 — Phishing-resistant MFA (FIDO2 / WebAuthn / passkeys)

• Mandate FIDO2 / passkeys for all C-suite, IT, security, finance, HR, and admin accounts.
• Migrate the broader user base from SMS-OTP / push-only to passkeys (operating-system keychain) over 6-12 months.
• Enable number-matching push as an INTERIM control while passkeys roll out.
• Disable legacy authentication (IMAP / POP3 / SMTP-AUTH) that bypasses MFA.

11.4 Layer 4 — Conditional access + zero-trust

• Bind sessions to managed devices (Microsoft Intune / Jamf / Workspace ONE compliance state).
• Block impossible-travel sign-ins.
• Block sign-ins from anonymising VPN / Tor / known bulletproof ASNs.
• Step-up authentication for sensitive operations (downloading mailbox, creating OAuth app, modifying mail forwarding rules, MFA changes).

11.5 Layer 5 — Endpoint detection & response (EDR)

• Microsoft Defender for Endpoint / CrowdStrike Falcon / SentinelOne / Cisco Secure Endpoint / Carbon Black on every workstation and server.
• Behavioural detection for post-click malware execution (LOLBin abuse, suspicious PowerShell, Cobalt Strike beacon, IcedID, Qbot, Emotet).
• Browser isolation for high-risk URL clicks.
• Mobile EDR / MDM for smartphones and tablets.

11.6 Layer 6 — Recurrent user training

• Simulated phishing campaigns on a randomised quarterly schedule.
• Just-in-time training for clickers.
• Annual mandatory security awareness module covering phishing taxonomy and red flags.
• Public report-phishing button in the mail client (Outlook Report Message add-in, Gmail "Report phishing", Proofpoint Report Suspicious, IRONSCALES, KnowBe4 PAB).
• Recognition / reward for employees who correctly report real phishing.

Each layer has a specific role; none is sufficient alone. The defense-in-depth principle: an attacker must defeat ALL six layers to succeed. Probability of catastrophic compromise drops sharply with each independent layer added.

12. Phishing incident response checklist

When a phishing incident IS detected — either pre-click (the SOC analyst identifies the campaign in the SEG quarantine queue) or post-click (the user reports they entered credentials, or anomaly detection flags a sign-in from a new device / country / impossible-travel pattern) — the incident-response workflow is:

1. Contain. Disable the compromised account at the IdP (Azure AD / Entra ID / Okta / Workspace). Revoke all active sessions (Azure AD > Revoke sessions; Workspace > Sign user out). Revoke all OAuth grants. Force MFA re-enrollment with phishing-resistant authenticator.
2. Reset credentials. Force password reset; require new password to differ from previous passwords. Audit for password-reuse on other corporate accounts.
3. Inventory persistence. Check for new OAuth consent grants; revoke any not previously approved. Check for new mailbox forwarding rules and inbox rules (Microsoft 365: Exchange admin center > Recipients > Mailboxes > pick user > Manage mailbox forwarding; Workspace: Admin > Apps > Google Workspace > Gmail > Routing). Check for new app passwords. Check for new application-specific authentication tokens.
4. Audit access. Pull Microsoft 365 Unified Audit Log / Workspace audit log for the compromised account. Identify accessed files, downloaded data, sent mail (lateral phishing from the compromised account is common), and modified configuration. Quantify data exposure.
5. Lateral movement check. If the compromised account had access to sensitive systems (file shares, code repositories, customer data, financial systems, ticketing systems), search those systems for attacker activity in the compromise window.
6. Communicate. Notify the user, their manager, the security team, and (per playbook) legal / compliance / executive leadership. Customer-data-exfiltration triggers regulatory notification (GDPR Article 33: 72 hours; HIPAA: 60 days; PCI-DSS; state breach laws).
7. Recover. Restore data from immutable backup if exfiltrated or destroyed. Roll back malicious configuration changes. Reissue credentials and tokens. Re-onboard the user with phishing-resistant MFA.
8. Lessons learned. Document root cause (which control failed?), update playbooks, brief leadership, schedule blameless post- mortem, update simulated-phishing training to cover the specific variant.

The U.S. CISA #StopRansomware guidance and the FBI Internet Crime Complaint Center (IC3) are the authoritative incident-reporting channels for U.S. victims. Equivalent national CERTs apply elsewhere — BSI CERT-Bund (Germany), NCSC (UK), ASD ACSC (Australia), CCCS (Canada). For wire-transfer BEC variants the FBI Financial Fraud Kill Chain (FFKC) — see help_business_email_compromise.php §7 — is the canonical fast-recovery procedure.

13. FAQ

What is phishing in simple terms?

Phishing is a social-engineering attack delivered by email (or by SMS, voice call, QR code, or instant message) in which an attacker impersonates a trusted party to extract credentials, financial data, session cookies, or to deliver malware, or to trigger a fraudulent action by the recipient (wire transfer, MFA approval, gift-card purchase). The classic phishing email uses a plausible pretext, a forged or lookalike sender, an urgency cue, and a call-to-action that routes the victim to an attacker-controlled site or attachment. Phishing is broader than email spoofing: a phishing message may originate from a legitimately-attacker-owned lookalike domain with valid DMARC, from a compromised legitimate account, or via a third-party SaaS service the attacker has signed up for. Phishing is the #1 initial-access vector for breaches according to the Verizon DBIR (≈80% of breaches involve a human element across the 2023-2024 reports). In MITRE ATT&CK it is T1566, with three sub-techniques: T1566.001 Spearphishing Attachment, T1566.002 Spearphishing Link, T1566.003 Spearphishing via Service.

Does DMARC stop phishing?

DMARC at p=reject with aligned SPF and DKIM stops ONE specific phishing variant — direct domain spoofing in which the attacker forges the visible From: header to read an address at YOUR domain without controlling your domain. DMARC does NOT stop: (1) lookalike-domain phishing (attacker registers victim-corp.example, a different valid domain with valid DMARC for the attacker), (2) display-name phishing (attacker puts "CEO Name" in the display name with a free-webmail From: address), (3) IDN homograph phishing (attacker registers vіctim.example using Cyrillic і), (4) cousin- domain phishing (victim.co instead of victim.com), (5) compromised-account phishing (attacker sends from a legitimate sender@victim.example mailbox they have stolen credentials for — DMARC passes because authentication is legitimate), (6) third-party-service phishing (attacker signs up for a marketing SaaS as victim, the SaaS DKIM-signs and the message passes DMARC), (7) smishing / vishing / quishing (out-of-band channels DMARC does not cover at all). DMARC is foundational and necessary but NOT sufficient for phishing prevention. The defense-in-depth stack pairs DMARC with secure-email-gateway controls, phishing-resistant MFA, URL rewriting, sandbox detonation, lookalike-domain monitoring, and user training.

What is phishing-resistant MFA and why does it matter?

Phishing-resistant MFA is multi-factor authentication that uses cryptographic device-bound credentials which the user cannot inadvertently disclose to an attacker over a phishing page. The two canonical implementations are FIDO2 / WebAuthn security keys (hardware tokens like YubiKey, SoloKey, or platform- integrated authenticators) and passkeys (FIDO2 credentials stored in the operating system keychain — Apple iCloud Keychain, Google Password Manager, Microsoft Account, 1Password). Phishing-resistant MFA defeats Adversary-in- the-Middle (AitM) phishing kits like Evilginx, Modlishka, and Muraena which proxy the victim browser session to the real Microsoft 365 / Google login page and steal both the password AND the OTP / push notification in real time. WebAuthn binds the authentication ceremony to the origin (the actual URL the user typed) via the Relying Party ID — an attacker-controlled lookalike URL cannot complete the cryptographic challenge because the origin does not match. NIST SP 800-63B Authenticator Assurance Level AAL3 requires phishing-resistant MFA. CISA, the FBI, NSA, and the UK NCSC have all issued formal guidance since 2022 directing organisations to migrate away from SMS-OTP, voice-OTP, and push-notification-only MFA toward FIDO2 / passkeys for phishing-resistant protection. The 2022 Cloudflare Cloudflare-publishes- Twilio-Okta-style attacks documented exactly this phishing-resistant-MFA defense in action — Cloudflare staff who had FIDO2 keys could not be phished; staff on SMS or push MFA were.

What is the difference between mass phishing and spear phishing?

Mass phishing (also called "bulk phishing" or "phishing as a service") is the broadcast-style phishing campaign in which the attacker sends the same generic message to hundreds of thousands or millions of recipients hoping a small percentage click — the canonical IRS-tax-refund / DHL-parcel-delivery / Microsoft-365-password-expiry email blast. The conversion rate is low (≈3-10% click rate, ≈0.1-1% credential entry) but volume compensates. Spear phishing (T1566 with the "Spearphishing" qualifier) is the targeted variant in which the attacker tailors the message to a specific individual or small group, often after open-source reconnaissance against LinkedIn, the company website, press releases, and social-media. Spear phishing has dramatically higher conversion (10-30%+) because the message references real colleagues, real projects, and plausible context. Whaling is the executive-targeted sub- variant of spear phishing — the CEO, CFO, CISO, or board members are the targets. The DMARC defense is identical for all three variants — direct domain spoofing at the From: header is blocked at p=reject regardless of who the message targets — but the downstream controls (display-name impersonation rules, SEG anomaly detection on executive-name watchlists, phishing-resistant MFA enrollment for high-value accounts) need to be tuned for the audience.

How do I detect a phishing email forensically?

The forensic detection workflow combines Authentication-Results header inspection (RFC 8601), URL inspection, display-name inspection, and behavioural indicators. Step 1: View the raw message source (Outlook File > Properties > Internet headers; Gmail three-dot menu > Show original; Apple Mail View > Message > Raw Source). Step 2: Inspect the Authentication-Results header for the dmarc=, spf=, and dkim= verdicts. dmarc=pass with header.from matching the displayed From: address is the green-light indicator; dmarc=fail or header.from mismatch is the canonical spoofing signature. Step 3: Inspect the From: header for IDN homograph attacks — Punycode-form (xn--...) in the header is a strong indicator; visually-identical Cyrillic/Greek substitutions in the displayed glyphs are the IDN homograph red flag. Step 4: Hover (do NOT click) every link in the message and inspect the actual href target. Mismatch between the displayed link text and the target URL is the classic phishing signature. Step 5: Check the Reply-To header — a phishing campaign often sets Reply-To to an attacker-controlled webmail address while the From: header looks legitimate. Step 6: Inspect attachments — .htm, .html, .iso, .lnk, .js, .vbs, and password-protected ZIP archives are all phishing red flags. The DMARC Analyzer Email Header Analyzer (header_analyzer.php) automates steps 1-6 against a pasted raw header dump.

What is Adversary-in-the-Middle (AitM) phishing?

Adversary-in-the-Middle (AitM) phishing is the modern evolution of credential phishing that defeats most non-phishing-resistant MFA. Instead of presenting a static fake login page to the victim, the AitM kit (Evilginx, Modlishka, Muraena, EvilProxy, Tycoon 2FA, NakedPages) runs a reverse-proxy that fetches the REAL Microsoft 365 / Google / Okta login page in real time and presents it to the victim — pixel-perfect, complete with valid TLS for the lookalike domain. When the victim enters their password and the OTP / push approval, the kit captures BOTH and replays them to the real service to obtain a session cookie. The kit then exfiltrates the session cookie to the attacker, who pastes it into their own browser and bypasses MFA entirely. AitM kits are commodity-priced (USD 100-500 / month as a service) and require no cryptographic skill from the attacker — they are point-and-click. Phishing-resistant MFA (FIDO2 / WebAuthn / passkeys) defeats AitM because the cryptographic challenge is bound to the origin (the actual URL the user typed) — an attacker-controlled lookalike URL cannot complete the WebAuthn ceremony. Conditional Access policies that bind the session to a managed device, IP range, or risk score also reduce AitM impact even with non- phishing-resistant MFA. CISA published the canonical advisory AA22-279A in October 2022 documenting AitM attacks and recommending phishing-resistant MFA.

What are smishing and vishing?

Smishing is SMS phishing — phishing delivered by text message instead of email. The attacker sends an SMS impersonating a bank, courier (DHL, UPS, FedEx, USPS, Royal Mail, Deutsche Post), tax authority (IRS, HMRC, Finanzamt), or known service (Netflix, Apple, Amazon) with a link to an attacker-controlled site. Vishing is voice phishing — phishing delivered by phone call. The attacker calls the victim impersonating IT support, the bank fraud team, a courier driver, or law enforcement, and walks the victim through "verifying" their account by entering credentials on a phishing page, reading an OTP aloud, installing remote-access software (TeamViewer, AnyDesk, Quick Assist), or transferring money. Both smishing and vishing are OUT-OF-BAND from email — DMARC, SPF, DKIM provide ZERO defense against them. Defense layers: carrier-level SMS spam filtering, mobile-OS link-warning, do-not-call registry enrollment, organisational policies prohibiting credential disclosure over phone, mandatory call-back via known-good numbers for any "IT support" request, and user training that the IT helpdesk will never call to ask for a password or OTP. The 2023 MGM Resorts breach was initiated by a vishing call to the IT helpdesk impersonating an employee — the attacker requested an MFA reset; the helpdesk complied without verifying.

What is the phishing kill chain?

The phishing kill chain is the six-stage model documenting how a phishing campaign moves from attacker preparation to victim exploitation, derived from Lockheed Martin Cyber Kill Chain (CKC) terminology and applied to email-borne campaigns. Stage 1 — Reconnaissance: attacker harvests target email addresses, organisational charts, project names, press releases, social-media activity (LinkedIn, X / Twitter, Instagram). Stage 2 — Weaponization: attacker registers a lookalike or cousin domain, sets up SPF/DKIM/DMARC for the attacker domain, registers a phishing-kit hosting provider, and crafts the message + landing page + payload. Stage 3 — Delivery: attacker sends the email, SMS, or initiates the voice call. Email delivery may use envelope-From spoofing (defeated by SPF at receiver), From-header spoofing (defeated by DMARC), display-name spoofing (NOT defeated by DMARC), or legitimate sending from the attacker domain. Stage 4 — Exploitation: victim clicks the link, opens the attachment, dials the number, or scans the QR code. AitM kits proxy the victim session to the real service. Stage 5 — Installation / Persistence: attacker exchanges captured credentials or session cookies for persistent access — OAuth app consent, mailbox forwarding rules, conditional-access bypass, MFA reset, valid-account credentials (MITRE T1078). Stage 6 — Actions on Objective: credential harvesting (sold on dark-web markets), business email compromise wire fraud, ransomware delivery, intellectual-property theft, persistent espionage. Defender countermeasures map to each stage: DMARC blocks Stage-3 direct domain spoofing; SEG controls block Stage-3 lookalike delivery; phishing-resistant MFA blocks Stage-4 credential capture; conditional access + behavioural analytics block Stage-5 persistence; data-loss prevention + EDR block Stage-6 exfiltration.

14. Related guides

• Email spoofing explained — the TECHNIQUE-level deep dive on protocol forgery of the sender. Phishing USES spoofing as one delivery vector; this is its parent reference. Covers the seven canonical spoofing techniques (direct domain, envelope MAIL FROM, display-name, lookalike, IDN homograph, cousin, subdomain takeover) plus Authentication-Results detection.
• DKIM failures explained — the PHISHING-ATTACK-DKIM-VERDICT- FAILURE-AS-ENTERPRISE-SECURITY- DETECTION-SIGNAL companion to this anti-phishing defender-side reference. Where THIS page documents the multi- layer enterprise anti-phishing defence stack (DMARC enforcement, secure email gateway URL rewriting, attachment sandboxing, user-training programmes, SOC triage workflow, executive impersonation detection), the DKIM- failures-explained spoke documents the receiver-side DKIM-verdict-failure signal class catalogue that surfaces in Authentication-Results headers AND in per-row RUA aggregate-report XML as the EARLIEST observable telemetry of phishing-delivery attempts. Concretely, the spoke documents FOUR DKIM-failure- as-phishing-detection-signal dimensions for enterprise SOC consumption: (i) dkim=fail signature mismatch on inbound mail purporting to be from the protected brand as the direct-author-domain- phishing signal class — when a phishing attacker forges From: support@<brand> but cannot generate a valid DKIM signature under any published brand selector, the receiver-side Authentication-Results surfaces dkim=fail (signature did not verify); the spoke documents how SIEM correlation engines convert this verdict into an inbound-phishing detection alert by joining Authentication-Results telemetry with SEG quarantine-decision metadata; (ii) dkim=none on lookalike-domain phishing as the cousin-domain impersonation signal class — when an attacker registers <brand>-support.com or secure-<brand>.com and sends without DKIM infrastructure, the receiver surfaces dkim=none; the spoke documents how SEG and SOAR pipelines combine the unsigned-author-domain signal with newly-registered-domain WHOIS lookups, IDN-homograph detection, and recipient-engagement- history baseline to escalate cousin- domain phishing without waiting for user-reported abuse; (iii) body-hash-mismatch on legitimate brand-signed mail as the post-delivery man-in-the-middle phishing-content- injection signal class — when a hostile relay (e.g., compromised upstream mail-routing service, BGP- hijacked transit, malicious O365 tenant mail-flow connector) modifies legitimate brand-signed mail to swap URLs for phishing landing pages or rewrite wire-transfer routing numbers, the receiver-side body-hash recomputation diverges from the original-signer's bh= tag — the spoke documents this body- hash-mismatch class as a DISTINCT phishing-detection signal from header- From forgery because the SOC remediation pivot is forensic-MTA- trace investigation, not user- education or DMARC-tuning; and (iv) dkim=permerror selector NXDOMAIN as the DNS-infrastructure- compromise phishing-precondition signal class — when an attacker hijacks the brand's DNS infrastructure (registrar credential theft, DNS-cache poisoning, BGP redirection) and injects NXDOMAIN responses for legitimate brand DKIM selector lookups, legitimate brand- signed mail surfaces dkim=permerror (no key for signature) at receivers — the spoke documents this permerror class as a critical SOC-escalation signal because DNS-infrastructure compromise is the precondition for the most- damaging direct-domain-takeover phishing campaigns the multi-layer defence stack this page documents is designed to prevent. Read the DKIM-failures-explained spoke alongside this anti-phishing defender-side reference when the enterprise SOC needs the receiver- side verdict-class taxonomy that distinguishes genuine sender- configuration faults from active phishing-attack telemetry warranting IR escalation under the six-layer defence stack this page enumerates.
• Business Email Compromise (BEC) playbook — the FINANCIAL-FRAUD outcome variant of phishing. CEO fraud, invoice fraud, payroll diversion, gift-card scam, M&A fraud, Vendor Email Compromise. FBI IC3 reports BEC as the highest-financial-loss email crime — USD 2.9 B in 2023 alone.
• How attackers bypass weak DMARC — security-research catalogue of 22 concrete attacker techniques across four classes: direct From-identity attacks, weak-configuration attacks, authentication-mechanism attacks, infrastructure attacks DMARC cannot stop. The attacker-side dual to this defender-side page.
• DMARC myths and misconceptions debunked — debunks 18 common DMARC myths including "DMARC stops all phishing" (no — see section 5 of this page). Reset your team's mental model before rolling out DMARC.
• DMARC record tags explained — tag-by-tag reference for v=DMARC1, p=, sp=, np=, rua=, ruf=, fo=, adkim=, aspf=, pct=. The DMARC record reference cited from every section of this page.
• DMARC for SaaS senders — the multi-tenant-platform anti-phishing-isolation pattern — the per-deployment deep dive on the SaaS-multi-tenant-platform operator persona and the SPECIFIC phishing vectors that SaaS-platform deployments introduce that single-tenant operator deployments do not face. Where THIS page documents the defender-side anti-phishing playbook for a single operator protecting a single brand from spoof-by-attacker, the SaaS-senders spoke documents the materially-distinct anti-phishing challenge the SaaS-platform operator faces: shared-IP cross-tenant attribution (an attacker who compromises tenant B's authenticated SaaS session can send phishing FROM tenant A's brand using the shared SaaS-platform sending IP — because the SaaS platform's outbound MTA signs with the PLATFORM's d= domain in the worst case and the attacker's intra-platform spoof never crosses an inter-tenant DMARC-authentication boundary), per-tenant DKIM-key isolation (the SaaS platform must implement per-tenant DKIM key separation so the residual cross-tenant-brand-impersonation surface is closed at the cryptographic-signing layer), per-tenant SPF-envelope-sender isolation (each tenant gets a distinct @<tenant-id>.<saas>.com envelope-from that the customer's SPF record explicitly authorises via an include:<tenant-id>.<saas>.com mechanism, not the SaaS platform's catch-all include:<saas>.com), and per-tenant brand-asset isolation in the BIMI logo-rendering pipeline (the SaaS platform must implement per-tenant SVG-Tiny-PS / VMC-bundle validation so tenant A's brand cannot be impersonated through tenant B's logo upload). Read the SaaS-senders spoke when an operator at a SaaS platform asks "how do we protect tenant A's brand from being phished THROUGH our shared multi-tenant infrastructure" or when a customer asks "what does my SaaS provider's anti-phishing posture look like for MY brand" — the spoke documents the multi-tenant-platform-anti-phishing-isolation pattern that complements the single-tenant defender-side playbook THIS page documents at the threat-vector level.
• DMARC for transactional email — the TRANSACTIONAL-DOMAIN-AS-PHISHING-CAMPAIGN- IMPERSONATION-TARGET-WITH-ELEVATED-CLICK-AND- CREDENTIAL-CAPTURE-RATE-DUE-TO-USER-TRUST-IN- TRANSACTIONAL-MAIL-CLASS companion documenting the per-ESP transactional-sender deployment whose customer-domain From-headers (password-reset notifications from no-reply@<bank>.com, shipping notifications from orders@<retailer>.com, MFA codes from auth@<provider>.com, receipts from billing@<saas>.com, account-action confirmations from security@<tenant>.com) are the canonical highest-value targets for phishing campaigns specifically BECAUSE of the established user-trust pattern that transactional mail benefits from. Where THIS page documents the defender-side anti-phishing playbook for a single operator protecting a single brand from spoof-by-attacker, the DMARC-for-transactional-email spoke documents the materially-elevated threat profile transactional- mail-class senders face that promotional / marketing / corporate-internal senders do not encounter at the same intensity: (i) transactional mail is the mail class users have been most aggressively trained to act on — password-reset emails, MFA codes, receipt confirmations, shipping notifications are precisely the user-action patterns phishing campaigns leverage because the user has been habituated to click through transactional mail without scrutiny (the "verify your password reset" social-engineering primitive); (ii) transactional-mail spoofing has higher credential-capture conversion rate than marketing-mail spoofing — the defender's RUA-stream surfaces phishing-campaign source_ip rows targeting transactional-mail From: headers at materially higher volume than marketing-mail From: headers, requiring an elevated p=reject enforcement urgency for transactional-mail-class sending domains; (iii) transactional ESPs operate on shared- customer egress IP pools that attackers can attempt to abuse via account-takeover of a legitimate ESP customer — when a phishing campaign succeeds in obtaining valid SendGrid / Mailgun / SES API credentials from a legitimate ESP customer (via the phishing-collected credentials from a previous phishing campaign, completing the closed loop), the attacker can send DMARC-aligned phishing mail FROM the compromised customer's domain via the legitimate ESP's shared egress IPs — the DMARC-for- transactional-email spoke documents the per-ESP anomaly-detection patterns operators use to identify this attack class in their own RUA-stream BEFORE the receiver's anti-phishing defenses surface it; (iv) transactional- mail-class subdomain carve-outs ( notifications.<brand>.com / mail.<brand>.com / email.<brand>.com / per-ESP bounce subdomains) increase the attack surface for sp= subdomain spoofing — the DMARC-for-transactional-email spoke documents the canonical subdomain-isolation pattern transactional ESPs deploy AND the sp=reject subdomain-policy enforcement discipline that closes the subdomain-spoofing-via-transactional-subdomain attack vector THIS page surfaces at the threat-mechanic level. Read the DMARC-for-transactional-email spoke alongside this page when an operator is rolling out defender-side anti-phishing protection for a domain that egresses transactional mail through a third-party ESP — the spoke is the authoritative per-ESP operator-discipline reference for the transactional-mail-class- elevated-threat-profile mitigation that this single-tenant defender-side playbook page recommends adopting in section 5's per-segment anti-phishing posture.
• DMARC alignment explained — strict vs relaxed alignment, the organizational-domain inheritance per RFC 7489 §3.2, and the implications for subdomain spoofing.
• DMARC policy rollout playbook — operational deployment from p=none through p=quarantine to p=reject without breaking legitimate sending. The path from "spoofing detected, not blocked" to "spoofing rejected at the SMTP transaction".
• DMARC deployment checklist — 24-item operator quick-reference covering SPF + DKIM + DMARC publication, ARC, BIMI prerequisites, monitoring, and post-rollout verification.
• DMARC monitoring — ongoing operations: aggregate (RUA) report analysis, forensic (RUF) report triage, alert thresholds, and source-IP attribution for incident response.
• DMARC aggregate (RUA) reports — the EMPIRICAL-OBSERVABILITY-SURFACE- FOR-DEFENSE-IN-DEPTH-PHISHING-PROTECTION companion to this phishing-protection defense-in-depth umbrella reference. Where THIS page documents the broader defense-in-depth STACK (SPF + DKIM + DMARC + BIMI + MTA-STS + secure-email-gateway anti-impersonation rules + user-awareness training) and the per-layer attack-class each control STRUCTURALLY denies, the DMARC- aggregate-reports spoke documents the RFC 7489 §7.2 XML reporting schema that materialises the per-message per- author-domain per-alignment-outcome evidence at four phishing-defense- observability coupling dimensions: (i) per-source-IP per-row <row><source_ip> evidence as direct-domain-spoofing attribution layer — the per-row source_ip child element catalogued in the per-receiver per-day per-row aggregate-report XML stream IS the operational attribution layer that maps detected direct-domain spoofing attempts (per-message DMARC- fail evidence) to per-source-IP per- ASN per-geolocation attacker infrastructure — without the per-row per-source_ip evidence the RUA spoke documents, the phishing-protection umbrella's "alignment denies direct- domain spoofing" claim is UNFALSIFIABLE; (ii) per-row <policy_evaluated><dkim/spf> verdict as defense-in-depth-layer-by- layer attack-class detection evidence — the per-row policy_evaluated.dkim and policy_evaluated.spf verdict sub-elements catalogued in the RUA XML schema spoke partition the per-message phishing-defense outcome into THREE distinct attack-class detection regimes (DKIM-aligned-pass- only = SPF-broken-at-forwarder-hop, SPF-aligned-pass-only = DKIM- unsigned/broken, both-fail = direct spoofing attempt) — the per-row verdict evidence the RUA spoke documents IS the per-defense-layer attack-class telemetry the phishing- protection umbrella's defense-in-depth coverage claim depends on; (iii) per-day per-receiver per-author- domain DMARC-pass-rate as Phase-2-to- Phase-3 rollout-advancement evidence baseline — the canonical DMARC rollout from p=none → p=quarantine → p=reject the phishing- protection umbrella references as the "alignment's policy-layer enforcement contract" is gated on a ≥99% legitimate-mail-DMARC-pass-rate baseline computed by aggregating per-row policy_evaluated.disposition counts the RUA spoke documents the schema of — without the RUA XML stream the per-tenant operator CANNOT empirically observe the rollout- advancement-gate threshold; (iv) per-row <identifiers><envelope_from> + <identifiers><header_from> evidence as exact-domain-vs-lookalike- attack-class detection partition — the per-row identifiers sub-element the RUA XML schema spoke documents carries BOTH the envelope-MAIL-FROM domain AND the RFC 5322 Header-From: domain per-row, enabling per-receiver per-author-domain detection of exact- domain-spoofing attempts (header_from = the protected author-domain, no aligned signature) DISTINCT from lookalike-domain attempts (header_from = an attacker-registered look-alike that DMARC evaluates against the lookalike's own policy) — the partition the RUA evidence enables IS the foundation the phishing- protection umbrella's "alignment closes exact-domain attacks, lookalike- domain attacks require complementary defenses" claim rests on. Read the DMARC-aggregate-reports spoke alongside this defense-in-depth phishing protection umbrella when the operator's phishing-defense programme needs the per-message per-author-domain per- attack-class empirical telemetry the umbrella's defense-in-depth coverage claim depends on at every per-receiver per-day reporting cycle.
• DMARC multi-domain strategy — the cross-domain DMARC coordination playbook. The parked-domain pattern explicitly blocks attackers from sending FROM your unused brand domains.
• SPF explained — the canonical SPF pillar. Covers mechanism types, qualifiers, and the 10-DNS-lookup limit.
• Why SPF alone is insufficient — the PHISHING-DEFENSE-SEVEN- CANONICAL-TECHNIQUE-CATALOGUE-AS-LOAD- BEARING-OPERATIONAL-PROOF-FOR-SPF-ALONE- IS-INSUFFICIENT-DEFENSE-IN-DEPTH- MOTIVATION companion to this phishing- defense threat-catalogue reference. Where THIS page documents the seven-canonical- phishing-technique catalogue (display- name spoofing, IDN homograph, lookalike- domain, compromised-SaaS-sender, reply-to swap, mailing-list-relay impersonation, BEC-style executive impersonation) and the Authentication-Results-based detection workflow that catches them, the why-SPF- alone-is-insufficient spoke is the per- publisher-per-receiver defense-in-depth motivation reference whose per-attack- class arguments map directly to per- canonical-phishing-technique operational- evidence at FOUR per-technique-class-vs- SPF-alone-gap rebuttal-evidence dimensions: (i) per-attacker per- message display-name-spoofing technique as load-bearing proof-evidence for SPF- cannot-detect-header-From-spoofing gap — per-attacker per-message display-name-spoofing attacks pass per- source-IP envelope-MAIL-FROM SPF-aligned- pass when the attacker controls a per- source-IP envelope-MAIL-FROM that authenticates via SPF but spoofs the per-message visible-header-From friendly- name; per-source-IP SPF-alone publication discipline cannot reach the per-message header-From layer; (ii) per- attacker per-domain IDN-homograph-or- lookalike-domain technique as load- bearing proof-evidence for SPF-record- publishing-per-publisher-domain-alone- leaves-near-neighbor-domain-attack- surface-gap — per-attacker per- homograph-domain SPF-record publication on an attacker-controlled near-neighbor domain (xn--paypa1-... vs paypal.com) passes per-source-IP SPF-aligned-pass for the attacker-published per-homograph- domain; per-source-IP SPF-alone-on-the- legitimate-publisher-domain cannot defend against per-attacker per- homograph-domain-published per-attacker- independent SPF-record publication; (iii) per-forwarder per-message mailing- list-relay impersonation technique as load-bearing proof-evidence for SPF- breaks-under-forwarding RFC 7208 §10.4 gap — per-forwarder per-message mailing-list-relay second-hop attacks break per-source-IP envelope-MAIL-FROM SPF-aligned-pass on the second-hop when the per-forwarder per-message envelope- MAIL-FROM-rewrite (SRS-or-non-SRS) shifts the per-source-IP authorization context; per-source-IP SPF-alone cannot defend the per-publisher per-receiver per- forwarder-hop legitimate-message- delivery without per-publisher per- message DKIM-side cryptographic-trust- anchor verification; (iv) per- attacker per-compromised-account SaaS- sender technique as load-bearing proof- evidence for SPF-cannot-detect- compromised-legitimate-sender gap — per-attacker per-message compromised- SaaS-sender attacks pass per-source-IP envelope-MAIL-FROM SPF-aligned-pass because the per-source-IP per-publisher per-SaaS-sender authorization is per- publisher published-as-legitimate; per- source-IP SPF-alone cannot defend against per-publisher per-receiver per- compromised-account attacks without per- publisher per-attacker-tampered-message DKIM-side cryptographic-trust-anchor verification gates.
• SPF include: vs ip4: vs a: vs mx: decision tree — the SPOOFING-DEFENSE-IP-PROVIDING-MECHANISM-CHOICE-AS-AUTHORIZATION- SURFACE-MINIMIZATION companion to this phishing-protection threat-catalogue reference. Where THIS page documents the seven-canonical-phishing-technique catalogue (display-name spoofing, IDN homograph, lookalike-domain, compromised- SaaS-sender, reply-to swap, mailing-list-relay impersonation, BEC-style executive impersonation) and the Authentication-Results-based detection workflow that catches them, the include-vs-ip4-vs-a-vs-mx decision-tree spoke is the UPSTREAM-AUTHORIZATION-SURFACE-MINIMIZATION companion documenting the FOUR structurally-distinct SPF IP-providing mechanism choices whose authorization-set blast-radius profile bounds the operator's ENVELOPE-LAYER spoofing-defense posture: (i) ip4: / ip6: direct CIDR enumeration is the SMALLEST authorized-IP set and therefore the LOWEST spoofing-attack-surface choice — a domain whose SPF authors only ip4: / ip6: blocks restricts envelope-layer authorization to a finite, operator- owned set of IPs, leaving the seven-phishing-technique catalogue's compromised-SaaS-sender vector with NO envelope-layer footing (because no SaaS IPs are included); (ii) include: delegated authorization is the LARGEST blast-radius choice because the operator transitively trusts whatever IPs the included SaaS publishes — a SaaS-sender envelope-IP-set compromise (the compromised-SaaS-sender technique catalogued on THIS page) produces spoofed messages envelope-layer-indistinguishable from legitimate vendor traffic, and the operator's only structural defenses are (a) minimising the number of include: chains in the SPF record (reducing the SaaS- compromise surface), and (b) ensuring DMARC-alignment-with-DKIM is the independent second factor that catches envelope-only spoofs; (iii) a:<name> and bare a name-based authorization couples envelope-layer trust to A/AAAA-record dynamics — operators using a: face a STRUCTURAL DRIFT RISK whenever the named host's A/AAAA records change without the operator's awareness, which is the same DNS-MISCONFIGURATION attack-surface the seven-technique catalogue's lookalike-domain technique exploits at the From-header layer; (iv) mx:<name> and bare mx MX-server-based authorization couples envelope-layer trust to the inbound MX topology — operators using mx: face the same drift risk as a: compounded by MX-record changes, and the receive-side MX servers that mx: authorises are often NOT the same servers that legitimately SEND outbound mail (which is a structural-mismatch sub-class of the envelope-authorization- broader-than-the-actual-sending-IP-set spoofing surface). The operator's SPF-IP-providing-mechanism choice therefore IS PART OF the spoofing- defense posture: minimising the authorized-IP set (preferring ip4: / ip6: over include: / a: / mx: where operationally feasible) is the ENVELOPE-LAYER attack-surface-minimization complement to the message- identity-layer spoofing-defenses this page's seven-technique catalogue and Authentication-Results-detection workflow treats. Read the four-IP- providing-mechanism decision-tree spoke alongside this phishing- protection threat-catalogue reference when the operator audits the SPF record as part of a periodic spoofing-defense posture review, when a new SaaS sender is proposed for inclusion (the include:-chain extension decision is a spoofing-surface expansion the operator must price against the legitimate-sending need), or when an incident-response investigation traces a spoofed message to an envelope-layer authorization the operator did not realise was in force (a stale include: chain pointing at a defunct SaaS vendor, a renumbered a: name, an overly-permissive mx: wildcard).
• SPF lookup limit and flattening — the RFC 7208 §4.6.4 10-DNS-lookup limit deep dive.
• SPF qualifiers explained - the PHISHING-CAMPAIGN-EXPLOITATION-OF- PUBLISHER-SOFT-FAIL-PERMISSIVENESS companion reference. Where THIS page documents the operator-side phishing- protection discipline catalogue (DMARC enforcement, BIMI display indicators, third-party-vendor isolation, executive- domain monitoring, brand-monitoring services), the dedicated SPF-qualifiers- explained spoke documents the STRUCTURALLY-LOAD-BEARING publisher-side qualifier-prefix choice whose four coordination dimensions identify the publisher's per-mail-stream SPF-leg attacker-exploitation-window surface that the phishing-defense framework on this page rests on: (i) publisher publishing terminating -all (HardFail) is the strongest publisher- side commitment against attacker-spoofed IPs - the SPF leg of any phishing campaign originating from an attacker- controlled IP not matched by the publisher's authorised-sender list produces spf=fail at the receiver, contributing to the receiver's DMARC-fail verdict and triggering the publisher's p=reject enforcement when honored; the SPF-qualifiers spoke documents the HardFail-as-strongest-attacker-defense operator-commitment contract and the per-mail-stream-profile criteria for choosing -all as the terminal-qualifier-prefix; (ii) publisher publishing terminating ~all (SoftFail, RFC 7208 §10.1 operator-default during DMARC rollout) is the PHISHING-CAMPAIGN- EXPLOITABLE permissiveness window - phishing campaigns originating from attacker-controlled IPs produce spf=softfail verdicts that many receivers treat as ALIGNMENT- NEUTRAL rather than message-rejecting, permitting the phishing message to reach the recipient's inbox even when the SPF leg structurally fails - the publisher's continued use of ~all past the p=quarantine tier is itself a phishing-defense-degradation operational gap this page's protection discipline catalogue identifies as a ramp-completion mandatory audit item; the SPF-qualifiers spoke documents the SoftFail-as-phishing- exploitable-window per-policy-tier operator-discipline and the ramp- completion criteria for migrating ~all to -all; (iii) publisher publishing terminating ?all (Neutral) or +all (Pass) is the AUTHENTICATION-DEFEAT operator-mistake-class that STRUCTURALLY DEFEATS the SPF leg's phishing-defense contribution - +all authorises the entire IPv4/IPv6 Internet to send mail as the publisher's domain producing spf=pass for every phishing campaign IP, while ?all produces spf=neutral treated as non-rejecting by the receiver - the publisher has structurally DISARMED the SPF half of the phishing- defense alignment-conjunction this page depends on, leaving the DKIM leg as the SOLE phishing-defense path; the SPF-qualifiers spoke documents the +all/?all- publisher-defeat-of-SPF-phishing-defense operator-mistake-class and the audit discipline this page's phishing- protection framework requires the publisher to satisfy before treating the SPF leg as a phishing-defense control; and (iv) per-mechanism qualifier prefixes (not just the terminating all) modulate attacker-exploitation windows per-third- party-include source - publisher publishing ~include:legacysaas.example.com commits SoftFail for legacy-SaaS-routed traffic while +include:firstparty.example.com (omitted-qualifier shorthand) commits Pass for first-party-routed traffic - a phishing campaign that registers a sender within the legacy-SaaS shared IP space exploits the SoftFail permissiveness of the ~include qualifier to reach recipients without SPF-rejection, even when the publisher's terminating all qualifier is the strict -all commitment; the SPF-qualifiers spoke documents the per-mechanism qualifier prefix discipline and the publisher-side audit framework for closing per-include attacker- exploitation windows by tightening per-include qualifier prefixes to the publisher's actual third-party-vendor trust posture this page's anti-phishing framework requires.
• Reverse DNS / PTR records for mail servers — the RECEIVER-SIDE-IP-IDENTITY-REPUTATION- AT-INBOUND-MX-BOUNDARY-AS-PHISHING-DEFENSE- LAYER companion to this anti-phishing defense-in-depth reference. Where THIS page documents the FOUR-LAYER message- identity-authentication-stack (SPF envelope-MAIL-FROM authorization, DKIM cryptographic message-body signature, DMARC alignment + policy enforcement, BIMI brand-trust visible signal), the reverse-DNS-PTR spoke documents the FIVE structurally-distinct angles on which the in-addr.arpa / ip6.arpa PTR-RR publication discipline functions as a PHISHING-DEFENSE-LAYER INDEPENDENT of the message-identity-layer this page treats: (i) RECEIVER-SIDE FCRDNS VERIFICATION PROTOCOL — every major mailbox-provider receiver (Gmail, Outlook.com, Yahoo, Apple iCloud, ProtonMail) performs Forward-Confirmed reverse DNS at inbound MX (PTR lookup on connecting IP, then forward-resolve returned PTR FQDN's A/AAAA records, then verify connecting IP appears in the forward-resolution set) per RFC 1912 §2.1 + RFC 5321 §4.1.1.9 — this verdict operates as a per-connecting-IP reputation signal STRUCTURALLY-INDEPENDENT of SPF / DKIM / DMARC; (ii) FCrDNS-FAIL VERDICT CONTRIBUTES TO PHISHING-CAMPAIGN DEFENSE EVEN WHEN MESSAGE-IDENTITY AUTHENTICATION PASSES — a phishing campaign operating through a compromised residential IP whose PTR is absent or has a residential- ISP-FQDN pattern produces a receiver-side FCrDNS-fail verdict that the receiver's anti-phishing layer weights as bot-net-signal even if the attacker has SUCCESSFULLY forged the message-identity-layer DMARC verdict (e.g., via §4.X infrastructure-evasion bypass); (iii) FCrDNS-PASS VERDICT DOES NOT BYPASS MESSAGE-IDENTITY AUTHENTICATION — the receiver's FCrDNS-pass verdict is a REPUTATION-INPUT to the inbound-MX decision, not an authentication- bypass — a legitimately-signed FCrDNS-passing message still must pass DMARC for inbox-placement; (iv) ANTI-PHISHING-DEFENSE BENEFIT OF FCrDNS-PUBLISHING DISCIPLINE — every legitimate outbound-mail-sending IP in the operator's outbound-MTA fleet SHOULD publish a forward-confirmed PTR-RR pointing at a tenant-specific FQDN whose forward resolution covers the connecting IP, so the receiver- side FCrDNS verdict at inbound MX produces a PASS classification — the absence of this discipline at any outbound MTA in the operator's fleet produces a receiver-side FCrDNS-fail verdict that the receiver's anti- phishing layer weights as low- reputation, degrading legitimate-mail inbox placement EVEN WHEN DMARC authentication passes; (v) FORENSIC- ATTRIBUTION OF ATTACK-IP — when an incident-response team investigates a phishing-campaign source-IP that SUCCESSFULLY delivered a forged- identity message, the in-addr.arpa PTR-RR lookup is the first step in IP-block-ownership attribution (whois lookup of the IP block, PTR delegation chain to the upstream ISP, the upstream ISP's abuse- contact for incident reporting) — the reverse-DNS-PTR spoke documents the operator-side discipline for publishing forward-confirmed PTR records that make legitimate outbound-mail-sending IPs attributable in this incident- response forensic workflow. Read the reverse-DNS-PTR spoke when constructing the comprehensive anti-phishing defense-in-depth treatment — the spoke documents the layer of defense that sits at the INBOUND-MX-TRANSPORT-LAYER reputation- gate stage, structurally upstream of the message-identity-layer DMARC evaluation this page's primary four-layer authentication-stack treats.
• DKIM explained — the canonical DKIM pillar. Covers selectors, canonicalization, signature algorithms (RSA, Ed25519), key sizes, and the d= signing domain.
• DKIM selectors explained — the PHISHING-DEFENSE-AGAINST-FORGOTTEN- AND-UNROTATED-SELECTOR-EXPLOITATION-AND- PER-PROVIDER-SELECTOR-NAMESPACE-HYGIENE- DISCIPLINE companion to this phishing- protection threat-catalogue reference. Where THIS page documents the seven- canonical-phishing-techniques catalogue (display-name spoofing, lookalike-domain attacks, Reply-To injection, envelope- MAIL-FROM forgery, Received-chain tampering, header-folding tricks, direct- domain spoofing) and the defense-in-depth STACK (DMARC + DKIM + SPF + BIMI + MTA-STS + SEG anti-impersonation), the DKIM- selectors-explained spoke is the PER- PROVIDER SELECTOR-NAMESPACE CATALOGUE companion documenting the canonical per- platform selector-name values (M365 selector1 / selector2, Google Workspace google._domainkey, AWS SES per-domain hash selectors, SendGrid / Mailgun / Mailchimp random-hex per- customer selectors) whose hygiene-and- rotation discipline closes a specific phishing-attack class the seven-canonical- catalogue treats: attackers exploiting FORGOTTEN / UNROTATED / ORPHANED selectors with compromised or weak keys. The four-axis PHISHING-DEFENSE-VS- SELECTOR-HYGIENE framework: (i) forgotten-selector exploitation defense — when a publisher rotates from an old selector to a new selector but FORGETS to remove the old selector's TXT record from DNS, an attacker who has obtained the OLD selector's private key (via past breach, supply-chain compromise of the original signing infrastructure, or insider exfiltration) can send DMARC- aligned phishing mail signed with the ABANDONED-BUT-STILL-PUBLISHED selector; the selectors-explained spoke documents the canonical rotation-hygiene discipline (after the propagation overlap window, REMOVE the old selector's TXT record from DNS so it returns NXDOMAIN at receiver-side verification) that closes this attack vector; (ii) weak- key-selector exploitation defense — when a publisher's old selector publishes an RSA-1024 or weaker key that modern attackers can factor or exhaust offline, attackers exploiting the recoverable key can sign phishing mail with the same selector; the selectors-explained spoke documents the per-platform RSA-2048-floor (or Ed25519) discipline that closes this attack vector; (iii) orphaned- ESP-customer-selector exploitation defense — when an operator offboards from an ESP (SendGrid, Mailgun, AWS SES) but FORGETS to remove the per-customer CNAME-delegated selector from DNS, an attacker who has obtained access to the ex-customer's ESP account (via credential leak from the old relationship) can send phishing mail through the ESP and the receiver-side DKIM verifier resolves the orphaned CNAME to the still-valid ESP-managed public key — DMARC-aligned phishing delivery; the selectors-explained spoke documents the canonical offboarding- hygiene discipline that closes this attack vector; (iv) per-tenant- selector-isolation in multi-tenant platforms — multi-tenant SaaS platforms (M365 tenant onboarding, Workspace tenant provisioning, ESP customer onboarding) must publish DISTINCT per-tenant selectors so a cross-tenant compromise (attacker compromises tenant B's signing infrastructure and extracts B's private key) cannot be used to sign DMARC- aligned phishing FROM tenant A's brand; the selectors-explained spoke documents the per-platform tenant-isolation discipline (M365's per-tenant .onmicrosoft.com selector namespace, ESP per-customer random-hex selector partitioning) that closes this cross-tenant attack vector. Read the DKIM-selectors-explained spoke alongside this phishing-protection reference when authoring the defender- side phishing-defense program's selector-hygiene policy — the spoke is the canonical per-provider namespace- catalogue that catalogues the operational-discipline checks closing the FORGOTTEN-SELECTOR / WEAK-KEY- SELECTOR / ORPHANED-ESP-SELECTOR / CROSS-TENANT-SELECTOR attack vectors that the seven-canonical-phishing- catalogue's DMARC-aligned-phishing sub-class structurally depends on.
• DKIM replay attacks — the byte-for-byte re-sending attack class that valid DKIM signatures cannot block. Includes the 2024 Google/Yahoo bulk-sender-disclosure context.
• DKIM-Signature header anatomy — the PHISHING-DEFENSE-MESSAGE-LAYER- AUTHENTICATION-PRIMITIVE-PER-DKIM-SIGNATURE- HEADER-TAG-BYTE-ANATOMY companion to this phishing-protection reference. Where THIS page documents the defense-in-depth stack spanning DMARC alignment + DKIM + SPF + BIMI + MTA-STS + secure-email-gateway anti-impersonation against the seven- canonical-phishing-attack-class catalogue, the DKIM-signatures-explained spoke is the per-tag BYTE-LEVEL HEADER ANATOMY canonical reference documenting the FOUR DKIM- Signature header tag-vs-phishing-defense coupling dimensions every stack layer structurally depends on: (i) d= signing-domain tag as DMARC-aligned-pass publication prerequisite — the per-message d=-tag publication is the publisher-controlled domain-identifier whose alignment with the RFC 5322 From: author-domain produces the DKIM-aligned-pass verdict that downstream phishing-defense layers (DMARC-aligned-pass-as-BIMI-display- eligibility prerequisite, DMARC-policy- enforcement-as-secure-email-gateway- bypass-suppression prerequisite) treat as load-bearing input — without the publisher-side d=-tag publication this spoke documents, NO phishing-defense layer on this page produces meaningful per-message verdicts; (ii) h= signed-header-list tag as header-injection- phishing-attack defense scope boundary — the per-publisher h=-tag publication (h=From:To:Subject:Date:Message-Id :Reply-To) determines which per- message headers participate in the cryptographic coverage; the canonical phishing-attack class of header-injection (X-Original-From override, From-Display- Name spoof, additional Reply-To substitution) PASSES DKIM verification when the injected headers sit outside the h= coverage scope — the spoke documents the per-publisher canonical best-practice of OVERSIGN publication (h=From:From:To:To: Subject:Subject:...) that closes the header-injection phishing-attack surface this page's defense-in-depth stack ultimately depends on; (iii) bh= body-hash tag as body-modification-phishing-attack defense primitive — the per- message bh=-tag SHA-256 body-hash is the cryptographic anchor against attacker-attempted body- modification phishing attacks (content- injection below the signed body, signature-stripping-and-replacement); the per-publisher l=-tag omission discipline this spoke documents is the canonical operationally-mature defense against the l=-tag-truncation phishing-attack class catalogued in this page's seven-canonical-phishing- attack catalogue; (iv) b= signature-value tag as DKIM- replay-phishing-attack defense boundary — the per-message b=-tag RSA-PKCS#1-v1_5 (or Ed25519 per RFC 8463) signature value is the cryptographic non-repudiation primitive the DKIM-replay-attacks spoke linked above catalogues as the attack surface; the per-message x=-tag expiration publication discipline this spoke documents is the canonical defense against the DKIM-replay-phishing- attack class. Read DKIM-signatures- explained as the per-tag byte-anatomy reference when scoping the message- layer-authentication-publication prerequisites for every layer of the phishing-defense-in-depth stack THIS page documents.
• DKIM cryptography basics (RFC 8301) — the PHISHING-DEFENSE-CRYPTOGRAPHIC- NON-REPUDIATION-AS-STRUCTURAL-ANTI- SPOOFING-PRIMITIVE companion to this phishing-protection reference. Where THIS page documents the seven-canonical- phishing-attack-class catalogue and the four-layer authentication-stack defense (SPF + DKIM + DMARC + BIMI) operators deploy to close the phishing-delivery attack surface, the DKIM cryptography basics spoke is the RFC 8301 cryptographic- primitive companion whose RSA-with-SHA- 256 / Ed25519-with-SHA-256 asymmetric- key cryptography is the STRUCTURAL anti- spoofing primitive the entire phishing- defense stack THIS page recommends depends on for its security guarantees. The PHISHING-DEFENSE-CRYPTOGRAPHIC-NON- REPUDIATION-AS-STRUCTURAL-ANTI-SPOOFING- PRIMITIVE cross-reference establishes FOUR structurally-distinct cryptographic- primitive-as-phishing-defense-foundation dimensions: (i) cryptographic- non-repudiation-as-anti-spoofing-foundation dimension — DKIM cryptographic signature verification per RFC 6376 §6 produces a dkim=pass verdict ONLY when the message was cryptographically signed by the holder of the private key corresponding to the publisher's DNS- published p=<base64-pubkey> tag value; this cryptographic-non- repudiation primitive is the STRUCTURAL anti-spoofing foundation that closes the envelope-vs-header-domain spoofing class the seven-canonical-phishing-catalogue on THIS page documents — an attacker WITHOUT access to the publisher's private key CANNOT forge a dkim=pass signature against the publisher's RFC5322.From domain; (ii) cryptographic-key-strength- determines-phishing-defense-strength dimension — DKIM cryptographic- key-strength minimum per RFC 8301 §3.1 is RSA-2048 (RSA-1024 has been compromised in published research; weak keys allow attacker-side cryptographic forgery); if the publisher's DKIM cryptographic-key-strength falls below the RFC 8301 minimum, the cryptographic- non-repudiation primitive collapses and the anti-spoofing foundation evaporates; the operator's phishing-defense posture is structurally bounded by the cryptographic-key-strength discipline documented in the DKIM cryptography basics spoke; (iii) cryptographic- algorithm-deprecation-vs-phishing-defense- evolution dimension — DKIM cryptographic-algorithm-deprecation per RFC 8301 §3.2 (SHA-1 sunset 2018-11-01) and the RFC 8463 Ed25519 algorithm- agility introduction structurally require operators to track cryptographic- algorithm-evolution as part of phishing- defense posture maintenance; legacy SHA-1 signers are silently downgraded to dkim=fail at modern verifiers, collapsing the DKIM leg of the four-layer authentication stack and opening the phishing-delivery attack surface; (iv) cryptographic- private-key-custody-as-phishing-defense- operational-control dimension — DKIM private-key custody per RFC 6376 normative semantics MUST be confined to the publisher's authorised outbound MTAs (private-key-leak via misconfigured cloud-storage bucket / committed-to- public-git / shared-with-third-party- ESP enables attacker-side cryptographic forgery against the publisher's RFC5322.From domain); the operator's phishing-defense posture is structurally bounded by the cryptographic-private- key-custody operational-control discipline documented in the DKIM cryptography basics spoke — a leaked DKIM private key is functionally equivalent to giving attackers a one-time pass against the entire four-layer authentication-stack defense THIS page recommends. Pair this page (the phishing-protection operator-defense reference) with the DKIM cryptography basics spoke (the RFC 8301 cryptographic-primitive reference) when an operator audits the structural anti-spoofing foundation of the phishing- defense posture and needs to apply the same cryptographic-non-repudiation / cryptographic-key-strength / cryptographic- algorithm-deprecation / cryptographic- private-key-custody disciplines as the load-bearing primitive layer the four- layer authentication-stack defense depends on for its security guarantees.
• DKIM troubleshooting (symptom-driven debugging) — the PHISHING-DEFENSE-DKIM-VERIFICATION- DIAGNOSTIC-LAYER companion documenting the operator-side symptom-driven diagnostic playbook for the DKIM-verification chain whose health is a load-bearing PHISHING- DEFENSE prerequisite for the four-layer authentication stack THIS page recommends. Where THIS page documents the seven- canonical-phishing-techniques catalogue (display-name spoofing, lookalike-domain attacks, Reply-To injection, envelope- MAIL-FROM forgery, Received-chain tampering, header-folding tricks, direct- domain spoofing) + the defense-in-depth STACK (DMARC + DKIM + SPF + BIMI + MTA-STS + SEG anti-impersonation), the DKIM-troubleshooting spoke is the SYMPTOM-DRIVEN OPERATOR PLAYBOOK that keeps the DKIM-side of the stack OPERATIONALLY HEALTHY against the silent- degradation modes that would otherwise widen the residual-attack-surface attackers exploit. The four-axis PHISHING-DEFENSE-VS-DKIM-TROUBLESHOOTING- DIAGNOSTIC-LAYER comparison exposes the structurally-distinct PHISHING-DEFENSE roles: (i) DKIM-pass-rate degradation widens the DIRECT-DOMAIN- SPOOFING residual-attack-surface — when DKIM-pass-rate drops on legitimate mail, DMARC enforcement at p=reject produces false-positive blocks on legitimate mail that DRIVE OPERATORS TO WEAKEN the DMARC policy back to p=quarantine or p=none — opening the direct-domain-spoofing residual-attack- surface attackers exploit; the DKIM- troubleshooting spoke is the operational defense against this silent-degradation mode; (ii) DKIM-signing-infra misconfiguration on the operator's own sending-infrastructure becomes a DELIVERABILITY-DEGRADATION channel attackers exploit — when legitimate operator-outbound mail consistently fails DKIM-verification at the receiver-side, the receiver's reputation system degrades the operator's sending-domain reputation; the DKIM- troubleshooting spoke's symptom-driven diagnostic ladder closes the operator- side root-cause-attribution loop before the reputation degradation enables attacker-impersonation campaigns with elevated inbox-placement rates; (iii) DKIM-key-rotation-window failures are an INCIDENT-RESPONSE-VECTOR for compromised-key phishing scenarios — when a publisher detects DKIM private- key compromise (a known phishing- amplification scenario), the DKIM- troubleshooting spoke documents the emergency-revocation procedure (publish empty-p= at the active selector, force-rotate ALL active selectors, audit per-selector forensic-report streams for attacker- amplified usage) the phishing-defense incident-response workflow consumes directly; (iv) DKIM-troubleshooting is the on-call operator's first-responder runbook for the SUSTAINED PHISHING- CAMPAIGN scenario — when a sustained phishing campaign targets the operator's domain (a SUSTAINED Stage 7 DMARC-alert-firing scenario), the DKIM- troubleshooting spoke is one of the three load-bearing operational playbooks the on-call operator follows (alongside DMARC-troubleshooting and SPF- troubleshooting) to keep the protected- domain's authentication-chain in HEALTHY OPERATING STATE while the attack campaign runs. Read the DKIM-troubleshooting spoke alongside this phishing-defense reference when designing the on-call incident-response runbook the operator follows during a sustained phishing campaign and when scoping the DEFENSE-IN-DEPTH operational discipline required to keep the DKIM-pass-rate above the DMARC-enforcement-readiness floor over time.
• ARC explained — Authenticated Received Chain (RFC 8617): the forwarding-survival mechanism for SPF and DKIM. Phishing-via-mailing-list is one of the ARC-relevant scenarios.
• Email authentication ecosystem (SPF, DKIM, DMARC, ARC, BIMI) — the cluster-intro pillar tying all four-layer authentication standards together.
• BIMI Verified Mark Certificates (VMC / CMC) — the trust-anchor reference for the brand-identity claim THIS page identifies as a structural anti-phishing signal. Where this page documents the seven-canonical-phishing-techniques catalogue and the Authentication-Results-based detection workflow, the BIMI certificates spoke documents the upstream verification process that produces the brand-logo visual signal mailbox providers (Gmail, Yahoo, Apple Mail, Fastmail) render in the inbox: the Verified Mark Certificate (VMC) is a publicly-trusted X.509 certificate issued ONLY by qualified CAs (DigiCert, Entrust) after verifying the trademark registration with a relevant IP office (USPTO, EUIPO, UKIPO, JPO), and the Common Mark Certificate (CMC) is the Apple-Mail-only variant for unregistered trademarks with prior-use evidence. Read this when designing the BRAND-IDENTITY-PRESERVATION layer of an anti-phishing program: BIMI gives recipients a visual signal that survives the protocol-layer authentication checks documented elsewhere on this page — DMARC enforcement + BIMI VMC together produce the inbox-displayed brand logo that recipients recognise as legitimate, raising the bar for attackers who CANNOT mint VMCs without CA-verified corporate-identity binding. The certificates page covers the issuance workflow, the indicator-uri / mark-type tag values that bind the certificate to the SVG asset, the dual-CA-vendor landscape, the renewal cadence, and the trademark-jurisdiction constraints — all the upstream operational prerequisites that the visual anti-phishing signal depends on.
• BIMI SVG Tiny Portable / Secure profile requirements — the BIMI logo-file format reference for the visual brand signal THIS page identifies as an anti-phishing affordance. Where the BIMI certificates spoke above covers the certificate-side trust-anchor, the BIMI SVG-requirements spoke covers the FILE-format constraints that ensure the brand logo renders consistently across every BIMI-honoring mailbox provider's rendering pipeline. The format is RFC-7264-style SVG Tiny 1.2 Portable / Secure (SVG-T-P/S): no scripts, no external references, no animation, no JavaScript event handlers, fixed viewBox="0 0 0 0" square aspect (1:1), file size capped at 32 KB post-optimisation, no external font references (text-as-paths only), and a per-element whitelist that excludes <foreignObject> / <script> / <use href="https://..."> external references. The constraints exist to PREVENT a sophisticated phishing-via-BIMI attack class: a BIMI logo that loads remote scripts or external images could exfil recipient pixels or render polymorphic content. The fixed-format constraint is itself an anti-phishing control. Read this when extending the anti-phishing program documented on this page to cover the visual-rendering attack surface: BIMI logos delivered to honest recipients must render identically across providers AND must not provide attackers with a late-stage execution channel inside the trusted mailbox-display rendering.
• CAA records explained — Certification Authority Authorization (RFC 8659). Where THIS page's seven-canonical-spoofing-technique catalogue and Authentication-Results detection workflow defend against PROTOCOL-layer message-identity attacks (forged From: headers, lookalike domains, IDN homographs), CAA defends against the orthogonal CERTIFICATE-ISSUANCE-layer attack vector where an adversary persuades a publicly-trusted Certificate Authority to issue a TLS certificate for the victim domain itself — enabling AiTM / phishing-via-HTTPS attacks where the attacker's reverse-proxy presents a valid green-padlock cert chain to the victim, defeating the TLS-as-identity-signal the recipient's browser relies on. RFC 8659 mandates every public CA query the CAA record at issuance time and reject orders the apex CAA does not authorise via an issue directive. A tightened CAA RR — listing only the one CA the brand actually uses, plus an iodef notification URL that alerts the security team when an unauthorised issuance is attempted — turns CA-side issuance into an attacker-visible failure with operator-side alerting, closing the sophisticated-phishing cert-acquisition vector that bypasses every layer of message-identity authentication this page documents. Pair CAA with Certificate Transparency log monitoring (covered in the CAA records page) for full detection-and-prevention coverage of cert-issuance attempts against your brand.
• Email security glossary — the threat-and-defense vocabulary glossary defining ~80 terms including phishing, spoofing, BEC, smishing, vishing, quishing, AitM, push-bombing, Vendor Email Compromise.
• Email deliverability fundamentals — the cross-cutting business-outcome reference. Phishing detection at the receiver feeds the deliverability funnel — DMARC-failed mail goes to spam or is rejected.
• DMARC forensic reports (RUF) — the PHISHING-CAMPAIGN-FORENSIC-EVIDENCE-CAPTURE-AND-INVESTIGATION companion reference. Where THIS page documents the SEVEN-CANONICAL-SPOOFING-TECHNIQUE catalogue (forged From:, envelope spoofing, display-name spoofing, lookalike domains, IDN homographs, cousin domains, subdomain takeover) and the Authentication-Results detection workflow (the receiver-side verdicts an operator queries to confirm a phishing attempt was recognized), the forensic-reports spoke is the PER-FAILED-MESSAGE EVIDENCE-CAPTURE companion documenting the rare-but-precious RUF samples that yield the per-message wire evidence phishing investigators need to characterise specific campaigns: each RUF sample (typically sent in ARF format by the ~5% of receivers that implement RUF emission — Comcast, Yahoo historically, GMX, Mail.ru, some boutique providers) captures the spoofed message's headers (the forged From: + Reply-To + Received: chain), the redacted body bytes (Subject + first N lines redacted to remove recipient PII per the spec's DSN-redaction guidance), the receiver-side Authentication-Results header showing exactly which auth check failed (SPF none / DKIM fail / DMARC alignment fail), and the timestamp + receiver-identity letting the investigator cross-reference the sample against RUA aggregate counts from the same window. Read the forensic-reports spoke alongside this page when scoping the per-incident investigation workflow: this page gives the DETECTION-AND-DEFENSE catalogue of phishing techniques the operator must defend against, the forensic-reports spoke gives the EVIDENCE-CAPTURE protocol through which the operator obtains the wire-level forensic material for any specific incident — together they form the catalogue (this page) + evidence-collection-and-investigation (the forensic-reports spoke) closure every anti-phishing program needs at p=quarantine and p=reject enforcement.
• MTA-STS for Microsoft 365 — the PHISHING-DEFENSE-MTA-LEVEL- MITM-AND-DOWNGRADE-INTERCEPT- PREVENTION-AT-EXCHANGE-ONLINE- RECEIVE-BOUNDARY companion reference. Where THIS page documents the message-layer phishing defense catalogue (Authentication-Results inspection, IDN/Punycode homograph detection, Reply-To divergence, attachment red-flag triage, link- hover discipline, From:-header validation), the MTA-STS-for- Microsoft-365 spoke documents the TRANSPORT-LAYER defense operating BELOW the message-layer surface this page catalogues. The M365 tenant's MTA-STS policy file enumerates the Exchange Online inbound MX hosts (*.mail.protection.outlook.com) with mode: enforce — sending MTAs that respect the policy REFUSE TO DELIVER any inbound mail to the protected tenant over non-TLS or non-policy-compliant TLS connections, closing the opportunistic-TLS-downgrade window an attacker controlling an upstream network segment can use to intercept, modify, and replay mail in transit. Read the M365 MTA-STS spoke alongside this page when scoping the END-TO-END anti-phishing posture — the message-layer defenses this page catalogues operate ABOVE the transport-layer defense the MTA-STS spoke documents, and a complete anti-phishing program protects BOTH the message wire-content (this page) AND the SMTP transport channel (the MTA-STS spoke).
• MTA-STS for Google Workspace — the PHISHING-DEFENSE-MTA-LEVEL- MITM-AND-DOWNGRADE-INTERCEPT- PREVENTION-AT-WORKSPACE-RECEIVE- BOUNDARY companion reference. Where THIS page documents the message-layer phishing defense catalogue (Authentication-Results inspection, IDN/ Punycode homograph detection, Reply-To divergence, attachment red-flag triage, link-hover discipline, From:-header validation), the MTA-STS-for-Google- Workspace spoke documents the TRANSPORT- LAYER defense operating BELOW the message-layer surface this page catalogues. The Workspace tenant's MTA-STS policy file enumerates the Workspace inbound MX hosts (the five- host aspmx.l.google.com + four altN.aspmx.l.google.com tier) with mode: enforce — sending MTAs that respect the policy REFUSE TO DELIVER any inbound mail to the protected tenant over non-TLS or non-policy-compliant TLS connections, closing the opportunistic-TLS-downgrade window an attacker controlling an upstream network segment can use to intercept, modify, and replay mail in transit. Read the Workspace MTA-STS spoke alongside this page when scoping the END-TO-END anti-phishing posture for Workspace-hosted recipient domains — the message-layer defenses this page catalogues operate ABOVE the transport- layer defense the MTA-STS spoke documents, and a complete anti-phishing program protects BOTH the message wire-content (this page) AND the SMTP transport channel (the MTA-STS spoke). Together with the parallel M365 MTA-STS spoke above, the two Workspace + M365 MTA-STS- cluster spokes form the CROSS-CLOUD ENTERPRISE-MAILBOX-PROVIDER TRANSPORT- LAYER-PHISHING-DEFENSE pair that operators scoping the defense-in-depth program across mixed-cloud recipient inventories consult for cloud-specific MTA-STS- deployment-discipline baselines.
• MTA-STS vs DANE for SMTP — the PHISHING-DEFENSE-IN-DEPTH- TRANSPORT-LAYER-MECHANISM-SELECTION- DECISION companion documenting the operator-side trust-model choice between the two RFC-standardised transport- layer-security mechanisms (MTA-STS RFC 8461 and DANE RFC 7672) that close the STARTTLS-strip / opportunistic-TLS- downgrade / forged-MTA-CA / BGP-hijack transport-layer phishing-delivery vectors enumerated in THIS page's defense-in-depth catalogue. Where THIS page documents the application-layer anti-phishing defense catalogue (Authentication-Results inspection, IDN / Punycode homograph detection, Reply-To divergence, cousin-domain typo-squat detection, lookalike-brand impersonation, DMARC alignment enforcement, BIMI VMC trust-anchor, MTA-STS policy enforcement at the receive boundary), the MTA-STS- vs-DANE comparison spoke documents the operator-facing DECISION REFERENCE that every defense-in-depth-program owner encounters when scoping the transport- layer-security component of the stack: MTA-STS (X.509-PKI-trust-model — the publisher serves the policy file behind a public-CA-issued certificate at the HTTPS endpoint mta-sts.<domain>/.well-known/mta-sts.txt, the receiver-side connecting MTA fetches and caches the policy according to the max_age: seconds value, and the per-MX-host STARTTLS handshake is enforced against the policy's mx:-list at SMTP- connection time) is deployable on any DNS zone with no DNSSEC prerequisite — the operator gains a phishing-defense- layer with no DNS-signing complexity; DANE (DNSSEC-trust-model — the publisher places a TLSA RR at _25._tcp.<mx-host> carrying the certificate-or-public-key fingerprint that the connecting receiver validates via a DNSSEC-signed DNS path) requires the operator's authoritative DNS zone to be DNSSEC-signed end-to- end — the operator gains a phishing- defense-layer with stronger trust-model guarantees (no public-CA-compromise attack surface, no per-CA-trust-store divergence between receivers) at the cost of DNSSEC-signing operational discipline. The defense-in-depth program owner reads the MTA-STS-vs-DANE comparison spoke to scope which of the two transport-layer mechanisms is the right fit for their organisation's DNS-infrastructure-maturity posture, and which of the phishing-attack-classes enumerated in THIS page's defense catalogue each mechanism actually closes at the SMTP-transport layer. Read the MTA-STS-vs-DANE comparison spoke alongside this phishing-defense catalogue when scoping the transport- layer-security component of the anti-phishing program — the comparison spoke is the OPERATOR-FACING DECISION REFERENCE for extending the defense-in-depth program from the application-layer (this page) into the SMTP-transport layer. Closes the threat-catalogue ↔ MTA-STS-cluster bridge whereby the SMTP-transport-layer phishing-defense layer THIS page identifies as one defense-in-depth component is the OPERATOR-FACING OUTCOME-SELECTION whose mechanism- choice the MTA-STS-vs-DANE comparison spoke documents.
• TLS-RPT report format (RFC 8460 §4 JSON schema deep dive) — the PHISHING-DEFENSE-IN-DEPTH-TRANSPORT-LAYER-FAILURE-EVIDENCE-CONSUMER-OF-PER-RECEIVER-AGGREGATE-JSON-REPORT-DATA companion documenting the per-field JSON schema ("organization-name" / "contact-info" / "report-id" / "date-range" / "policies" array with "policy"+"summary"+"failure-details" sub-records) of the aggregate JSON report receivers serialize and submit to the publisher's rua=-mailbox per RFC 8460 §4 schema, whose per-failure-record consumption is the load-bearing evidence input every phishing-incident investigation depends on when establishing whether a candidate phishing delivery rode an opportunistic-TLS-downgraded SMTP session at the receive boundary, across FOUR phishing-investigation TLS-RPT-JSON-consumer dimensions: (1) Per-incident failure-details[].result-type byte-token vocabulary as phishing-vector classification input — the RFC 8460 §4.3 enumeration (starttls-not-supported, certificate-host-mismatch, certificate-expired, certificate-not-trusted, validation-failure, tlsa-invalid, dnssec-invalid, dane-required, sts-policy-fetch-error, sts-policy-invalid, sts-webpki-invalid) is the load-bearing classification vocabulary that the phishing investigator pivots back to the defense-in-depth catalogue (section 4 of THIS page) for matching the JSON-reported receiver-side failure to the STARTTLS-strip / forged-MTA-CA / opportunistic-TLS-downgrade attack vector; (2) Per-RUA-window failure-details[].sending-mta-ip + receiving-mx-hostname tuple correlation with phishing-campaign per-source-IP attribution — the JSON per-failure-record sending-mta-ip field is the SMTP client IP that initiated the downgrade-affected session; correlating this tuple with the application-layer From-header-spoofed-domain at the same receive-window yields the load-bearing evidence that a phishing-campaign delivery used the cleartext channel for body harvesting + DKIM-signature replay; (3) Per-day summary.total-success-session-count vs summary.total-failure-session-count ratio as transport-layer-phishing-risk baseline — the RFC 8460 §4.3 per-policy summary integer fields are the load-bearing baseline metric for the operator's transport-layer-phishing-risk accounting; a sudden ratio shift (failure spike) at the publisher's rua=-mailbox is a leading indicator of an active downgrade-campaign against the publisher's published policy; (4) Per-policy-window policy.policy-string[] byte-content audit as publisher-side misconfiguration-vs-attacker-tampering discriminator — the JSON per-policy policy-string array contains the verbatim policy lines the receiver actually fetched from the publisher's MTA-STS or DANE publication; comparing the JSON-reported policy-string against the publisher's canonical policy is the load-bearing discriminator between operator misconfiguration (publisher-side byte-syntax-error) and active attacker policy-fetch-interception (BGP-hijack substitution). The JSON-report-consumption across these four dimensions is the load-bearing transport-layer evidence-input every phishing-investigation workflow documented in THIS page's section-4 catalogue structurally depends on.
• DANE explained (RFC 7672 DANE-for-SMTP) — the TRANSPORT-LAYER-DANE-TLSA-AS- DNSSEC-ANCHORED-DEFENSE-AGAINST-TLS- DOWNGRADE-AND-MITM-INTERCEPTION-IN- PHISHING-DELIVERY-CHANNEL companion reference. Where THIS page documents the seven canonical phishing techniques with section 4 enumerating the SMTP-transport-layer interception attack vectors (STARTTLS-strip, opportunistic-TLS-downgrade, forged- MTA-CA, BGP-hijack) that enable phishing campaigns to deliver MITM- intercepted-and-modified messages through the SMTP-transport layer, the DANE-explained spoke documents the STANDALONE RFC 7672 DANE-for-SMTP protocol whose DNSSEC-bound TLSA- record-publication + receiver-side TLSA-validation mechanics close those same transport-layer attack vectors through a STRUCTURALLY-DIFFERENT TRUST-MODEL ANCHOR than MTA-STS. Where the MTA-STS-vs-DANE comparison spoke (linked above) documents the operator-side DECISION between the two transport-security standards, the DANE-explained pillar is the STANDALONE DANE-PROTOCOL-MECHANICS REFERENCE the operator consumes BEFORE making that comparison-driven decision. DANE operates by binding the receiving MTA's TLS certificate (or its hash) to a DNSSEC-signed TLSA record published at _25._tcp.<mx-hostname> — when a sending MTA establishes STARTTLS to a DANE-publishing receiver, the sender validates the receiver's presented certificate against the DNSSEC-bound TLSA record rather than against the web-PKI certificate-authority trust-store that MTA-STS uses. The DNSSEC anchor provides cryptographic immunity to forged-MTA-CA attacks (an attacker cannot mint a valid certificate without compromising the DNSSEC root chain) and to opportunistic-TLS- downgrade (sender-side TLSA-presence observation MUST trigger TLS-required delivery semantics). Read the DANE- explained spoke when planning the transport-layer defense-in-depth posture for a domain whose authoritative DNS zone is DNSSEC- signed (the prerequisite for DANE deployment) — the byte-level TLSA record format, the certificate-usage / selector / matching-type byte fields, the cryptographic-trust model, and the receiver-side validation pipeline are the protocol-mechanics canonical reference for the DANE half of the transport-layer phishing-defense stack.
• DKIM canonicalization — the PHISHING-DEFENSE-BODY-IMMUTABILITY- CONTROL-AS-CRYPTOGRAPHIC-ANCHOR companion to this phishing-protection defense-in-depth catalogue. Where THIS page documents the layered phishing-defense control catalogue (envelope-MAIL-FROM SPF, application-layer DKIM + DMARC alignment, BIMI brand display, ARC chain forwarding survival, transport- layer MTA-STS + DANE), the DKIM- canonicalization spoke is the PER-MESSAGE BODY-AND-HEADER cryptographic-integrity- anchor whose `c=` tag value (the four RFC 6376 §3.4 combinations: `simple/simple`, `simple/relaxed`, `relaxed/simple`, `relaxed/relaxed`) is the load-bearing body-immutability control at FOUR phishing- delivery attack classes the receiver's DKIM- verifier rejects via canonicalization- constrained byte-shape verification: (i) MAN-IN-THE-MIDDLE BODY MODIFICATION WHERE ATTACKER INTERCEPTS LEGITIMATE SIGNED MAIL AND INJECTS PHISHING-PAYLOAD CONTENT BEFORE FORWARDING TO RECIPIENT — when an attacker compromises an intermediate SMTP hop (forwarder, anti-spam appliance, compromised mailbox-provider) and injects a phishing-payload URL into a legitimate signed message body, the DKIM body-hash verification (RFC 6376 §3.7) fails because the canonicalized body bytes no longer match the `bh=` tag value — the canonicalization choice (`simple` body canonicalization treats every byte as signed; `relaxed` body canonicalization applies §3.4.4 whitespace normalization but ALL meaningful content-bytes remain signed) determines the attacker's modification-detection sensitivity; (ii) HEADER-INJECTION ATTACKS WHERE ATTACKER REWRITES THE FROM:, SUBJECT:, OR REPLY-TO: HEADER OF A LEGITIMATELY SIGNED MESSAGE BEFORE FORWARDING — the `h=` signed-header-list tag enumerates which headers are protected; the canonicalization choice on the header half (`simple` vs `relaxed`, §3.4.1 vs §3.4.2) determines whether whitespace-only modifications survive but ANY content modification of a signed header fails verification — phishing-defense operators SHOULD sign at minimum From:, Subject:, Date:, Reply-To:, Message-ID, To:, Cc:, and Content-Type to close the canonical attacker-header-rewrite vector; (iii) DKIM-REPLAY ATTACKS WHERE ATTACKER CAPTURES A LEGITIMATELY SIGNED MESSAGE AND REBROADCASTS IT TO NEW RECIPIENTS WITHOUT BODY MODIFICATION — DKIM signature replay is the residual attack class canonicalization-strict signing does NOT defend against (the body and signed headers are byte-identical to the original, so DKIM verification passes by construction) — the canonicalization-side defense is to use `l=` body-length-limit tag in combination with the chosen canonicalization to bound the replay-modification scope, complemented by RFC 9103 `x=` expiration-tag publication for time-bounded replay-window limitation; (iv) CONTENT-FILTER REWRITE ATTACKS WHERE ATTACKER USES A COMPROMISED SAAS-TENANT'S MAIL-PROCESSING RULE TO REWRITE LEGITIMATE INBOUND PHISHING- RESISTANT MESSAGES BEFORE INBOX DELIVERY — when an attacker has compromised an intermediate SaaS-mailbox-tenant's mail- processing rules (Microsoft 365 Exchange transport rules, Google Workspace content filters), they can rewrite inbound message bodies to insert phishing-payload URLs AFTER receiver-side DKIM verification has passed — the canonicalization-side defense is to ensure receiver-side DKIM verification happens BEFORE any tenant- configurable post-receive modification, and the per-receiver inbox-display layer surfaces the DKIM-verified state to the user via BIMI brand indicator (delivered from this page's catalogue's brand-display control). Read the DKIM-canonicalization spoke alongside this phishing-protection defense-in-depth catalogue when authoring the operator's per-message body-immutability threat model — the spoke is the canonical RFC 6376 §3.4 reference whose four canonicalization combinations determine the per-publisher per-receiver body-and- header modification-detection sensitivity the phishing-defense control catalogue depends on for its application-layer body-immutability guarantee.
• DMARC for Microsoft 365 — the M365-TENANT-DEPLOYMENT-AS- PHISHING-DEFENSE-CONTROL-COVERAGE companion to this phishing-defense control-catalogue reference. Where THIS page documents the phishing- defense control catalogue (SPF + DKIM + DMARC + MTA-STS + TLS-RPT + BIMI + CAA layered defenses defeating direct- domain-spoofing / cousin-domain- impersonation / vendor-email- compromise / homograph From: / ARC-chain-stripping attack-vector classes), the M365-deployment spoke is the M365-TENANT cloud-mailbox- provider DEPLOYMENT-CONFIGURATION REFERENCE documenting how each per- M365-tenant configuration primitive implements a phishing-defense control from the catalogue THIS page enumerates. Concretely the spoke documents FOUR per-M365-tenant- configuration-vs-phishing-defense- control-coverage dimensions: (i) per-M365-tenant p=reject publication discipline implements the direct- domain-spoofing prevention control — the M365-deployment spoke documents the per-tenant _dmarc.<org-domain> TXT-RR p=reject publication discipline every Exchange Online operator must reach through the phased-enforcement ramp as the M365-tenant direct-domain- spoofing defense the phishing-defense control catalogue THIS page enumerates depends on; (ii) per-M365-tenant adkim=s-strict-mode publication discipline implements the cousin-domain-impersonation defense control — the M365- deployment spoke documents the per- M365-tenant adkim=s-strict-mode publication discipline every Exchange Online operator must apply as the M365-tenant per-organisational- domain structural defense against the cousin-domain-impersonation attacker class the phishing-defense control catalogue THIS page documents; (iii) per-M365- tenant aggregate-report stream consumption from rua=mailto: publication implements the vendor-email- compromise telemetry control — the M365-deployment spoke documents the per-tenant rua=-tag publication discipline every Exchange Online operator must apply because the per-source-IP per-day RUA evidence stream is the operator-side telemetry channel for detecting per-vendor legitimate-vendor compromise (LEGITIMATE vendor d=<vendor-domain> DKIM-pass with anomalous per-day volume spike) the phishing-defense control catalogue THIS page documents as the vendor-email- compromise attribution surface; and (iv) per-M365-tenant per-message policy_evaluated.dkim=fail DMARC-non-aligned verdict attribution implements the homograph From: detection control — the M365-deployment spoke documents the per-tenant per-row XML evidence stream every Exchange Online operator consults because the per-row <auth_results> DKIM d=-tag literal attribution surfaces the homograph From: lookalike-domain cryptographically-attestable evidence the phishing-defense control catalogue THIS page documents as the homograph-From- detection forensic-evidence surface. Read the M365-deployment spoke ALONGSIDE this phishing-defense control-catalogue reference when deploying the M365 cloud-only phishing-defense control set — the spoke documents how each per- M365-tenant configuration primitive implements the phishing-defense controls this page catalogues.
• DMARC policy modes — the P-EQUAL-POLICY-MODE-AS-LOAD- BEARING-RECEIVER-SIDE-ENFORCEMENT- CONTROL-FOR-EVERY-PHISHING-DEFENCE- OUTCOME-CATALOGUED-HERE companion to THIS anti-phishing control-catalogue. Where THIS page documents the multi- layer enterprise anti-phishing control set (user-training, SafeLinks-class URL-rewriting, anti- spoofing impersonation-detection, attachment sandboxing, post-delivery ZAP-class auto-purge, BIMI-VMC- gated brand-logo visual signal), the DMARC-policy-modes spoke is the publisher-side ENFORCEMENT DISCIPLINE documenting how each p=-tag value publishes the receiver-side disposition that gives the phishing-defence outcomes THIS page catalogues their load- bearing teeth at FOUR per-policy- mode-to-phishing-defence-outcome dimensions: (i) p=none + observability-only phishing defence — the policy-modes spoke documents how p=none publication gives the receiver-side anti- phishing stack THIS page catalogues per-message Authentication-Results evidence to score against the SafeLinks / impersonation-detection / ZAP-class controls but does NOT block any direct-domain spoofing message at SMTP-time — the publisher's anti-phishing defence is observability-only; (ii) p=quarantine + spam-folder phishing defence — the policy-modes spoke documents how p=quarantine publication instructs receivers to spam-fold direct-domain spoofing messages, which COMPLEMENTS the receiver-side anti-phishing controls THIS page catalogues (the spam folder is itself a phishing- defence outcome the page treats as load-bearing); (iii) p=reject + SMTP-bounce phishing defence — the policy-modes spoke documents how p=reject publication instructs receivers to SMTP-bounce direct-domain spoofing messages BEFORE the receiver-side anti-phishing controls THIS page catalogues ever see them — the strongest publisher- side phishing-defence outcome achievable through receiver-side DMARC enforcement; (iv) sp= + subdomain-phishing defence — the policy-modes spoke documents how sp= closes the per-subdomain attack-surface that attackers exploit when publishers publish p=reject at the org-domain but leave sp= defaulted, giving the phishing-defence outcomes THIS page catalogues sub-org-domain scope. Read THIS page when DESIGNING the multi-layer anti- phishing control set; read the DMARC-policy-modes spoke when scheduling WHICH receiver-side disposition gives the phishing- defence outcomes THIS page catalogues their load-bearing receiver-side teeth.
• Email Header Analyzer — paste a raw email header and the tool surfaces the Authentication-Results verdict, IDN/Punycode form detection, Received: chain anomalies, and Reply-To mismatches automatically — the forensic workflow from §9 in tool form.
• Domain Security Checker — verify your own domain's SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI, and CAA configuration in one place. Use BEFORE rolling out DMARC to gather a clean baseline.
• DNS Record Generator — generate publish-ready SPF, DKIM, DMARC, TLS-RPT, MTA-STS, CAA, and BIMI records for your domain.
• BIMI explained — the BRAND-LOGO-AT-INBOX-AS-RECEIVER- SIDE-ANTI-PHISHING-VISUAL-AUTHENTICITY- SIGNAL companion to this anti-phishing defender-side reference. Where THIS page catalogues the multi-layer enterprise anti- phishing defence stack (DMARC enforcement, secure email gateway URL rewriting, attachment sandboxing, user-training programmes, SOC triage workflow, executive impersonation detection), the BIMI-explained spoke documents the receiver-rendered authenticated-brand logo at the inbox-list surface as the recipient-perceivable visual authenticity signal that converts the DMARC-enforcement posture this page treats as a backend telemetry surface into a front-end visual cue end-users learn to rely on for at-a-glance brand-authenticity recognition. Concretely, the spoke documents FOUR per-recipient-visual- authenticity-signal dimensions for anti- phishing-aware brand teams: (i) the inbox-list brand-logo render as the end-user-perceivable BIMI-eligibility signal class — when an inbound message carries a passing DMARC verdict AND the brand's default._bimi publication points to a Tiny-PS SVG asset, BIMI-supporting mailbox providers (Gmail, Yahoo, Apple Mail with VMC) render the brand logo against the message preview; the spoke documents how this surface becomes the FRONT-END recipient anti- phishing signal whose ABSENCE on a purported brand message — even when the backend Authentication-Results header passes — trains recipients to recognise the unsigned cousin-domain phishing class this page catalogues; (ii) the VMC-gated blue-checkmark display as the verified-brand-identity signal class — when a brand obtains a Verified Mark Certificate from a BIMI- compliant CA (DigiCert, Entrust) proving registered-trademark ownership of the logo, Gmail and Apple Mail render an additional verified-brand-identity badge adjacent to the logo; the spoke documents how this VMC-gated surface elevates the anti-phishing visual signal from "logo rendered" to "trademark-authenticated brand identity" — distinguishing the protected brand from BIMI-publishing cousin-domain attackers attempting to publish lookalike logo assets without trademark proof; (iii) the BIMI- display-absence on legitimate brand mail as the DMARC-enforcement-posture- regression early-warning signal class — when a brand's outbound mail loses BIMI display eligibility at major mailbox providers (typically because the 90-day rolling DMARC pass-rate falls below provider-specific thresholds or the brand temporarily relaxes p= to none), the spoke documents how SOC dashboards subscribed to BIMI-display telemetry treat the logo-absence on legitimate-brand mail as an EARLY-WARNING signal of DMARC- enforcement-posture regression — well BEFORE the receiver-side phishing-attack success rates documented in this page's SOC workflow surface in incident reports; and (iv) the recipient-side brand-logo recognition cycle as the sustained-anti-phishing-resilience signal class — the spoke documents how repeated recipient exposure to the authenticated brand logo on legitimate mail builds the visual-recognition baseline that lets the user-training programmes catalogued in §6 of this page reach their full anti-phishing efficacy ceiling, because the trained recipient at-a-glance recognises the AUTHENTICATED brand display vs the unsigned-or-cousin-domain phishing attempt the multi-layer defence stack catalogued here is designed to deflect. Read the BIMI-explained spoke alongside this anti-phishing defender-side reference when the enterprise security team needs the receiver-side visual- signal surface that converts the technical anti-phishing stack this page documents into the recipient-perceivable brand-authenticity cue the broader anti- phishing programme depends on.
• DKIM best practices — the CANONICAL-DKIM-DEPLOYMENT- DISCIPLINE-AS-LOAD-BEARING-PRECONDITION- TO-EVERY-RECEIVER-SIDE-PHISHING- DETECTION-VERDICT companion to this anti-phishing defender-side reference. Where THIS page catalogues the multi- layer anti-phishing defence stack (DMARC enforcement, secure email gateway URL rewriting, attachment sandboxing, user training, SOC triage, executive impersonation detection), the DKIM-best-practices spoke documents the canonical DKIM publication-and-rotation discipline as the LOAD-BEARING precondition to every receiver-side phishing-detection verdict this page's defender-side stack consumes. Concretely, the spoke documents FOUR per-DKIM-best-practice- to-phishing-detection-precondition dimensions: (i) 2048-bit RSA key-strength floor as the receiver- side DKIM-strength-scoring precondition to dkim=pass DMARC-evaluation-input — the spoke documents how receiver-side DKIM key-strength scoring (Gmail, Yahoo, Microsoft) penalises 1024-bit and weaker keys, and how the 2048-bit RSA best-practice floor is the load-bearing precondition to the dkim=pass verdict the anti-phishing DMARC-enforcement layer this page's §3 depends on; (ii) periodic selector-rotation cadence as the per- tenant key-compromise blast-radius containment precondition — the spoke documents how the 90-day- to-12-month selector-rotation cadence is the canonical key-compromise blast- radius containment primitive — when an attacker compromises a brand's DKIM private key, the rotation cadence bounds the duration the attacker can produce passing brand-signed phishing mail before the receiver-side selector retirement invalidates the stolen key; (iii) c=relaxed/relaxed canonicalisation as the mailing-list- and-forwarder-survivable signature precondition — the spoke documents how c=relaxed/relaxed is the canonical mailing-list-and-forwarder- survivable canonicalisation choice that prevents the legitimate-brand-mail false-positive dkim=fail class — a class the anti-phishing SOC triage workflow this page's §9 catalogues must avoid drowning in to focus analyst time on genuine phishing signals; and (iv) per-tenant selector partitioning as the per- sending-service phishing-attribution precondition — the spoke documents how per-tenant / per- service selector partitioning enables the SOC's rua-aggregate-report per-selector phishing-attempt attribution analysis this page's §9 catalogues — without per-tenant selectors, the SOC cannot distinguish a compromised marketing-automation DKIM key from a compromised transactional-billing DKIM key in the rua aggregate-report stream. Read the DKIM-best-practices spoke alongside this anti-phishing defender-side reference when the receiver-side DKIM-signing posture must be hardened to support the anti-phishing detection layers this page documents.
• MTA-STS explained — the TRANSPORT-LAYER-TLS- ENFORCEMENT companion to this receiver-side multi-layer anti- phishing defense reference. Where THIS page documents the MESSAGE-LAYER anti-phishing defense stack (DMARC at enforcement, SPF + DKIM authentication, ARC-chain inspection, BIMI display gating, per-subdomain sp=/np= scoped defense, per-tenant DMARC- alignment), the MTA-STS-explained spoke documents the TRANSPORT- LAYER anti-phishing defense layer — namely the per-publisher RFC 8461 TLS-channel-integrity enforcement that protects the per-message authentication evidence this page documents from man-in-the-middle and STARTTLS-downgrade attacks that would otherwise strip or impersonate the per-message Authentication-Results evidence the per-receiver anti-phishing evaluation depends on, bridging the message-layer anti-phishing defense this page documents to the transport-layer anti- phishing defense the MTA-STS spoke documents at four cross- layer anti-phishing-control coupling dimensions: (i) per-publisher MTA-STS TLS- channel-integrity enforcement as load-bearing precondition for per-message DMARC-enforcement anti-phishing evidence- preservation — DMARC's per- message receiver-side Authentication-Results evidence (the spf=pass + dkim=pass + dmarc=pass verdict chain this page documents the anti-phishing programme depends on) is transmitted IN-BAND with the message itself; an active STARTTLS-downgrade attacker between the sending MTA and the receiving MX can strip the TLS handshake → strip the Authentication-Results header → inject attacker-controlled Authentication-Results values impersonating per-publisher DMARC-pass — defeating the per-receiver anti-phishing evaluation this page documents the cross-layer defense depends on; the per-publisher MTA-STS TLS-channel-integrity enforcement the MTA-STS spoke documents is the load-bearing transport-layer precondition for the message-layer evidence- preservation every anti- phishing programme this page documents structurally consumes; (ii) per-publisher MTA-STS TLS-channel-integrity enforcement as load-bearing complement to per-publisher DMARC enforcement against the active-MitM-attacker class of phishing threat — DMARC at enforcement (p=quarantine, p=reject) blocks the direct- domain-spoof phishing subset this page documents, but a sophisticated active-attacker operating an in-path MitM between sender and receiver can downgrade STARTTLS → intercept legitimate authenticated mail → modify content → re-deliver with attacker-controlled body + attacker-injected Authentication-Results values appearing to pass DMARC; per-publisher MTA-STS TLS- channel-integrity enforcement the MTA-STS spoke documents is the canonical anti-MitM defense complementing the per- publisher DMARC at enforcement anti-direct-spoof defense this page documents; (iii) per- publisher MTA-STS plus TLS-RPT publication discipline as defender-side cross-layer operational-evidence-feed complement to per-publisher rua-aggregate-XML evidence- feed — every per-publisher anti-phishing programme this page documents (SOC + IR + threat-intelligence + per- domain monitoring + per- executive-impersonation protection + per-recipient anti-phishing training) depends on per-receiver per- publisher-domain telemetry evidence; the per-publisher rua-aggregate-XML evidence- feed at the message-layer captures per-source-IP per- Header-From per-disposition evidence enabling phishing- campaign detection; the per- publisher MTA-STS-paired TLS-RPT-JSON evidence-feed at the transport-layer captures per-receiver per-MX-host TLS- handshake-failure + per- failure-class evidence enabling MitM-attack + STARTTLS-downgrade-attack + per-publisher-domain impersonation-via-transport- layer-collapse detection complementary to the rua- evidence stream this page's anti-phishing programme depends on; (iv) per- publisher cross-layer anti- phishing-control stack coordination as per-publisher operational-discipline scope — every per-publisher anti- phishing programme catalogue (message-layer DMARC + SPF + DKIM + BIMI + transport-layer MTA-STS + TLS-RPT + display- layer BIMI + identity-layer phishing-resistant-MFA + endpoint-layer EDR + network- layer SEG + receiver-layer user-training) consumes the same per-publisher per-domain publication-discipline as the load-bearing per-publisher defense-in-depth primitive; the MTA-STS-explained spoke is the canonical per-publisher transport-layer anti-phishing- control reference receiver- side anti-phishing analysts read alongside this page when scoping the per-publisher cross-layer anti-phishing- control-stack the per-receiver per-message anti-phishing evaluation consumes. Read the MTA-STS spoke alongside this receiver-side multi-layer anti-phishing reference when scoping the per-publisher cross-layer anti-phishing defense whose transport-layer TLS-channel-integrity enforcement is the load- bearing precondition for the message-layer evidence- preservation every receiver- side anti-phishing programme this page documents structurally consumes.
• MTA-STS policy file syntax — the PER-PUBLISHER-mta-sts.txt- POLICY-FILE-BYTE-LEVEL-PUBLICATION- AS-LOAD-BEARING-TRANSPORT-LAYER- ANTI-DOWNGRADE-PHISHING-CONTROL- PRIMITIVE companion to this receiver-side multi-layer anti- phishing defense reference. Where THIS page documents the receiver- side anti-phishing defense framework that consumes per- publisher SPF / DKIM / DMARC message-authentication evidence to defend against the four canonical phishing variants, the mta_sts_policy_syntax spoke documents the per-publisher TRANSPORT-LAYER MTA-STS POLICY-FILE BYTE-LEVEL PUBLICATION whose per-publisher https://mta-sts.<domain>/.well-known/mta-sts.txt publication-discipline is the per-publisher LOAD-BEARING ANTI- DOWNGRADE-ATTACK PRIMITIVE that prevents the per-publisher per- receiver-side message- authentication evidence the receiver- side anti-phishing-defense framework consumes from being SILENTLY STRIPPED by an in-flight TLS- downgrade-attack. FOUR structurally- distinct PER-MTA-STS-mta-sts.txt- FIELD-VS-PER-CANONICAL-PHISHING- VARIANT-DEFENSE-COVERAGE dimensions the per-receiver anti-phishing- defense framework THIS page documents structurally consumes when the per-publisher operator extends the message-authentication defense layer with the per- publisher transport-layer mta- sts.txt-publication-discipline the policy-syntax spoke catalogues: (i) per-publisher version: STSv1 + mode: enforce mta- sts.txt publication AS LOAD- BEARING-PER-PUBLISHER-PER-RECEIVER- TLS-DOWNGRADE-ATTACK-PREVENTION- PRIMITIVE AGAINST THE ARC-VALIDATED- FORWARDER PHISHING VARIANT — the per-publisher mode: enforce mta- sts.txt-publication the policy- syntax spoke documents commits the per-receiver MTA-STS-aware sending MTA to REJECT opportunistic-TLS fallback for the per-publisher per-mx-pattern destination, preventing an in-flight man-in-the- middle attacker from STRIPPING STARTTLS-negotiation to inject a forged per-message ARC-sealed rescue-rewrite that would otherwise elevate a per-message phishing attempt to dkim-aligned-pass via a forged ARC chain; (ii) per- publisher mx:-field per-mx-pattern enumeration AS LOAD- BEARING-PER-PUBLISHER-PER-RECEIVER- MAIL-FLOW-AUTHORIZATION-INVARIANT AGAINST THE DISPLAY-NAME-SPOOFING- VIA-LOOKALIKE-MX PHISHING VARIANT — the per-publisher mx:-field per-mx- pattern publication the policy- syntax spoke documents commits the per-receiver MTA-STS-aware sending MTA to REJECT TLS-handshake completion to ANY mx-hostname NOT matching the per-publisher per- mx-pattern enumeration, preventing a per-publisher per-domain- impersonating attacker from injecting a lookalike-MX-hostname (e.g., maill.<publisher-domain> with double-l typo, or aspmx.l.googlemail.com with googlemai!l unicode- substitution) into the per- publisher receiver-side mail-flow path; (iii) per-publisher _mta-sts.<domain> TXT-record + per-publisher mta- sts.txt-policy-id rotation AS LOAD- BEARING-PER-PUBLISHER-PER-RECEIVER- POLICY-FRESHNESS-INVARIANT AGAINST THE COMPROMISED-THIRD-PARTY-ESP PHISHING VARIANT — the per-publisher _mta-sts.<domain> TXT-record + mta-sts.txt-policy- id rotation discipline the policy- syntax spoke documents is the per- publisher transport-layer invalidation-primitive enabling rapid per-publisher per-receiver per-mx-pattern policy-update during a per-publisher compromised-third- party-ESP per-source-IP incident- response: the per-publisher operator can publish a new mta- sts.txt-policy-id WITHOUT the compromised-third-party-ESP mx- pattern and bump the per-publisher _mta-sts-TXT-record id=-field to force per-receiver per-mta-sts.txt cache- invalidation; (iv) per- publisher max_age:- field publication-cadence AS LOAD- BEARING-PER-PUBLISHER-PER-RECEIVER- POLICY-CACHE-COHERENCE-INVARIANT AGAINST THE TLS-SESSION-DOWNGRADE- REPLAY-CACHE-POISONING PHISHING VARIANT — the per- publisher max_age:- field publication-cadence the policy-syntax spoke documents is the per-publisher per-receiver per- day TLS-handshake-attempt-baseline cache-coherence invariant whose per-receiver per-publisher per-day TLS-RPT per-mta-sts.txt-policy- violation-class observability stream surfaces the per-publisher per-receiver per-day per-mta- sts.txt-mode-state per-mx-pattern TLS-downgrade-attempt forensic- evidence the per-publisher anti- phishing incident-response analyst consumes. Read the mta_sts_policy_syntax spoke ALONGSIDE this receiver-side multi-layer anti-phishing reference when the per-publisher transport-layer anti-downgrade- attack-prevention primitive extends the per-publisher message-authentication-evidence preservation discipline THIS page documents — the spoke is the canonical per-publisher TRANSPORT-LAYER ANTI-DOWNGRADE- ATTACK-PREVENTION REFERENCE the per-receiver anti-phishing- defense framework depends on at the per-publisher mta-sts.txt- policy-file byte-level publication level.
• TLS-RPT record syntax — the per-publisher per-policy-domain TRANSPORT-LAYER-ANTI-DOWNGRADE-OBSERVABILITY- RECORD-PUBLICATION-DISCIPLINE companion to this receiver-side multi-layer anti-phishing reference. Where THIS page documents the per- receiver per-message anti-phishing layered defence (per-message SPF + DKIM + DMARC evaluation, per-publisher visual-clue BIMI-rendering, per-receiver per-message warning-banner-and-attachment-sandboxing, per-receiver per-message URL-rewriting safe- link discipline), the TLS-RPT-record-syntax spoke documents the per-publisher per-policy- domain _smtp._tls.<d> TXT-RR byte-grammar (the v=TLSRPTv1 version tag, the rua=mailto: reporting-URI list, the optional rua=https:// HTTPS-collection-endpoint authorization) at the transport-layer anti-downgrade-attack observability-publication discipline boundary — the per-publisher per-policy-domain observability primitive that surfaces the per-receiver per-day per-publisher per- policy-domain SMTP-session-level transport- layer-downgrade events (STARTTLS-strip, STARTTLS-fail, certificate-validation-fail, MTA-STS-policy-violation) the per-receiver anti-phishing defence framework THIS page documents DEPENDS ON for the per-publisher per-domain pre-phishing transport-layer attack-surface attribution channel. Three per-receiver per-message anti-phishing observability dimensions the TLS-RPT-record- syntax spoke documents the per-publisher per-domain anti-phishing operator MUST AUTHOR alongside the per-message anti- phishing defence layers THIS page documents: (i) per-publisher per-day per- receiver STARTTLS-strip attack-surface observability via per-policy-domain TLS-RPT aggregate-report publication — the per-receiver per-day per-publisher per- policy-domain TLS-RPT aggregate report the spoke documents surfaces the per-receiver per-publisher per-policy-domain per-day STARTTLS-strip attack events (an active attacker intercepting the SMTP session and removing the STARTTLS extension from the EHLO response, forcing the per-message delivery into plaintext for transport-layer eavesdropping or message-modification attacks) the per-receiver anti-phishing defence framework THIS page documents depends on at the per-publisher per-domain pre-message transport-layer attack-surface observability tier; (ii) per- publisher per-day per-receiver MTA-STS- policy-violation observability via per- policy-domain TLS-RPT aggregate-report publication — the per-receiver per-day per-publisher per-policy-domain TLS-RPT aggregate report the spoke documents surfaces the per-receiver per-publisher per-policy-domain per-day MTA-STS-policy- violation events (per-receiver per-message SMTP sessions where the per-publisher per- policy-domain mode: enforce commitment was violated due to certificate- chain-mismatch, MX-pattern-mismatch, or STARTTLS-failure) the per-receiver anti- phishing defence framework THIS page documents depends on at the per-publisher per-domain transport-layer policy- enforcement observability tier; (iii) per-publisher per-day per- receiver transport-layer attack-frequency attribution via per-policy-domain TLS-RPT per-receiver per-result-type aggregation publication — the per-receiver per-day per-publisher per-policy-domain TLS-RPT aggregate report the spoke documents attributes per-receiver per-day per-publisher per-policy-domain transport-layer attack- frequency to per-result-type bucket (starttls-not-supported, certificate-host-mismatch, certificate-expired, certificate-not-trusted, validation-failure) the per- receiver anti-phishing defence framework THIS page documents depends on at the per- publisher per-domain transport-layer attack- class root-cause attribution tier. Read the TLS-RPT-record-syntax spoke ALONGSIDE this anti-phishing defence reference whenever the per-publisher per-domain operator AUTHORS the per-publisher per-domain transport-layer observability publication portfolio that SURFACES the per-message pre-phishing transport-layer attack-surface the per- message receiver-side anti-phishing layered defence framework THIS page documents DEPENDS ON at the per-publisher per-domain anti-phishing publication-portfolio authoring boundary.
• DMARC troubleshooting — the PER-PUBLISHER-PER-DOMAIN-DMARC- VERDICT-FAIL-REMEDIATION companion to this per-recipient per-publisher anti- phishing defence-framework reference. Where THIS page documents the per- recipient per-publisher per-message receiver-side layered anti-phishing defence framework (the per-message DMARC-verdict-pass-as-anti-phishing- primitive surface, the per-publisher per-domain DMARC-enforcement-as-deterrence primitive, the per-recipient receiver- side mail-client UI per-attack-class anti-phishing indicator surface), the DMARC troubleshooting spoke is the OPERATIONAL-DIAGNOSIS-OF-DMARC-VERDICT- REGRESSIONS-THAT-DEGRADE-THE-ANTI- PHISHING-SURFACE companion documenting the per-verdict decision-tree for per-message DMARC-fail regressions that DIRECTLY degrade the per- publisher per-domain anti-phishing deterrence surface THIS page documents. The composition operates through the per-publisher per-domain DMARC-pass dependency: per-publisher per-domain anti-phishing deterrence REQUIRES per-message dmarc=pass on every legitimate operator-controlled mail AND requires per-message dmarc=fail → quarantine-or-reject on every attacker-spoofed mail. A per-message dmarc=fail regression on operator-controlled mail (caused by SPF-include lookup-budget overflow, DKIM signature-canonicalisation drift, or alignment misconfiguration) forces the per-publisher per-domain operator to choose between p=none monitoring (no deterrence — attackers can freely spoof) and p=quarantine / p=reject enforcement (deterrence active but with collateral quarantine-or-reject of the operator's own legitimate mail) — both choices DEGRADE the per-publisher per-domain anti-phishing deterrence surface THIS page documents. The troubleshooting spoke's per-verdict decision-tree catalogues the operational-diagnosis surface that RESOLVES the per-message dmarc=fail regressions without forcing the operator into the p=none-monitoring vs legitimate-mail-quarantine trade-off: (i) per-domain spf=fail diagnosis walks the per-source-IP authorisation audit and per-domain SPF-include cascade audit; (ii) per-domain dkim=fail / dkim=permerror diagnosis walks the per-selector publication audit; (iii) per-domain dmarc=fail from alignment-mismatch walks the per- publisher per-domain alignment- configuration audit. Read THIS page when AUTHORING the per-recipient per- publisher anti-phishing defence framework; read the DMARC- troubleshooting spoke when DIAGNOSING per-message DMARC-verdict regressions that DEGRADE the per- publisher per-domain anti-phishing deterrence surface THIS page documents at the per-publisher per- domain anti-phishing publication- portfolio operational-resilience boundary.
• DMARC reporting pipeline — the ANTI-PHISHING-DEFENCE- PROGRAM-EMPIRICAL-OBSERVABILITY-PIPELINE companion to this per-publisher per- domain anti-phishing defence reference. Where THIS page documents the per- publisher per-domain anti-phishing defence-program publication discipline (the per-publisher per-domain SPF + DKIM + DMARC + BIMI + MTA-STS + TLS- RPT + CAA + lookalike-domain-monitoring + DNS-based-block-list-monitoring + per- recipient-side phishing-recognition- training + per-incident-response SOC- ticketing publication-discipline portfolio), the DMARC-reporting- pipeline spoke is the PER-PUBLISHER- PER-DOMAIN-ANTI-PHISHING-DEFENCE-PROGRAM- EMPIRICAL-OBSERVABILITY-AND-ALERTING DOWNSTREAM-CONSUMER documenting how the per-publisher per-domain RUA + RUF reporting pipeline FEEDS the per- publisher per-domain anti-phishing- incident-response and per-publisher per-domain spoofing-attack-forensic- investigation workflow at FOUR per- pipeline-stage per-anti-phishing- defence-program coupling dimensions: (i) per-receiver per-day per- publisher per-day per-source-IP DMARC- aligned-fail-rate spike as per- publisher per-domain active-attack- campaign empirical-detection signal — the per-publisher per-domain RUA-pipeline-side per- source-IP DMARC-aligned-fail-rate-floor regression alerting cadence that EMITS a per-publisher per-domain operator-visible alert when a per- publisher per-domain per-source-IP per-day per-publisher per-day DMARC- aligned-fail-rate spike PARTITIONS the per-receiver-emitted RUA aggregate- report population into per-publisher per-domain legitimate-mailflow per- source-IP buckets vs per-publisher per-domain attacker-spoofing per- source-IP buckets — the per- publisher per-domain attacker- spoofing per-source-IP bucket IS the LITERAL per-publisher per-domain active-attack-campaign empirical- detection signal the per-publisher per-domain anti-phishing-incident- response SOC consumes as the per- publisher per-domain attack-campaign attribution primitive; (ii) per-failure-message forensic- report ARF diagnostic-block per- attack-message header-and-body forensic-evidence-collection per RFC 6591 — the per-publisher per-domain RUF-pipeline-side per- aligned-fail per-failure-message per-attacker-emitted SMTP-envelope- and-RFC-5322-header-and-body forensic-evidence-collection discipline that materializes per- attack-campaign per-attacker-emitted per-message diagnostic-block payload (envelope MAIL FROM, envelope RCPT TO, RFC 5322 From header, RFC 5322 Subject header, DKIM-Signature header, Authentication-Results header, Received-chain header) the per-publisher per-domain anti- phishing-incident-response SOC consumes as the per-publisher per- domain attack-campaign forensic- investigation evidence primitive; (iii) per-publisher per- domain per-day per-publisher per- domain spoofing-attack-campaign- longitudinal-trend-storage and per- publisher per-domain spoofing-attack- campaign-retention-cadence — the per-publisher per-domain RUA + RUF pipeline-side per-publisher per- domain per-day per-publisher per- domain spoofing-attack-campaign- longitudinal-trend retention cadence that materializes the per-publisher per-domain spoofing-attack-campaign- wave time-series the per-publisher per-domain anti-phishing-defence- program-effectiveness-trending analytics dashboard structurally depends on; and (iv) per- publisher per-domain per-day per- publisher per-domain anti-phishing- defence-program-effectiveness empirical-KPI emission — the per-publisher per-domain RUA + RUF pipeline-side per-publisher per- domain per-day per-publisher per- domain anti-phishing-defence-program- effectiveness KPI emission cadence (per-publisher per-domain DMARC- aligned-pass-rate floor for legitimate-mailflow time-series, per-publisher per-domain DMARC- aligned-fail-rate floor for attacker- spoofing time-series, per-publisher per-domain per-day per-publisher per- domain spoofing-attack-campaign- deterrence time-series) the per- publisher per-domain anti-phishing- defence-program-leadership KPI- reporting dashboard structurally consumes as the empirical-evidence primitive for per-publisher per- domain anti-phishing-defence-program- ROI defense at the per-publisher per- domain CISO / CFO / Board executive- reporting boundary. Pair this per- publisher per-domain anti-phishing defence reference with the DMARC- reporting-pipeline spoke when OPERATIONALIZING the per-publisher per-domain anti-phishing-defence- program empirical-observability cadence — the DMARC-reporting- pipeline spoke is the PER-PUBLISHER- PER-DOMAIN-AGGREGATE-AND-FORENSIC- REPORT-DOWNSTREAM-CONSUMER REFERENCE whose per-publisher per-domain per- receiver per-day per-publisher per- day per-source-IP DMARC-aligned-fail spike-detection-and-forensic- diagnostic-payload emission cadence the per-publisher per-domain anti- phishing-defence-program structurally depends on as the empirical- observability pipeline THIS page's defence-publication-discipline- portfolio materially requires.
• SPF for Google Workspace — the per-Workspace-tenant per-domain v=spf1 include:_spf.google.com ~all publication discipline is the load- bearing per-publisher per-domain envelope-MAIL-FROM authorization primitive whose first-hop SPF- aligned-pass verdict gates the DMARC composite against the envelope- MAIL-FROM disjoint-domain, cousin- domain and source-IP-forgery spoofing-attack classes targeting Workspace-hosted brands. Joint Workspace-tenant per-domain SPF publication + per-tenant DMARC p=reject ramp produces the per-publisher anti-phishing defence-portfolio every Workspace- tenant deployment must publish to protect its brand domain from the spoofing-and-impersonation attack classes this page enumerates.
• DKIM for Google Workspace — the PER-WORKSPACE-TENANT-DKIM- SIGNING-DISCIPLINE-AS-ANTI-PHISHING- CRYPTOGRAPHIC-AUTHENTICATION-PRIMITIVE companion to this anti-phishing- protection playbook. Where THIS page documents the per-publisher per- domain anti-phishing defence-portfolio the Workspace-tenant operator publishes to defend the brand-domain against the canonical phishing-and- impersonation attack classes (direct- spoof, cousin-domain look-alike, compromised-vendor, BEC-overlap, credential-harvesting landing-page, consent-phishing), the DKIM-for- Workspace spoke documents the UPSTREAM per-Workspace-tenant per-custom-domain DKIM-signing deployment workflow (Workspace Admin Console > Apps > Google Workspace > Gmail > Authenticate email; per-tenant per- custom-domain DKIM key generation at 2048-bit RSA modulus; per-selector TXT-record publication under google._domainkey.<domain> in the per-tenant authoritative DNS zone; per-tenant Authenticate-email Start toggle) whose per-Workspace- tenant DKIM-pass-then-DMARC-aligned- DKIM-pass verdict is the LOAD-BEARING per-message cryptographic anti-spoof proof every phishing-impersonation variant against a Workspace-hosted brand domain THIS page catalogues must structurally defeat to land at the victim's inbox under the spoofed From-header identity. The PHISHING- PROTECTION-VS-WORKSPACE-DKIM cross- reference establishes FOUR structurally-distinct per-Workspace- tenant per-domain anti-phishing cryptographic-authentication coupling dimensions: (i) direct-spoof phishing variant attempts to forge the Workspace-hosted brand domain's From-header without producing a per- message DKIM-Signature cryptographically valid under the per-Workspace-tenant per-custom-domain RSA-2048 public key — the absence of a valid signature under d=workspace-brand-domain with s=google is the immediate cryptographic-anti-spoof- proof the receiver-side DKIM verifier returns dkim=fail on, gating downstream DMARC-aligned-DKIM- pass evaluation; the DKIM-for- Workspace spoke documents the per- Workspace-tenant Authenticate-email Start toggle deployment whose per- tenant per-custom-domain google._domainkey.<d> publication is the load-bearing cryptographic-anti-spoof-proof primitive; (ii) compromised- vendor phishing variant produces a per-message DKIM-Signature cryptographically valid under the compromised vendor's Workspace per- tenant per-custom-domain RSA-2048 key — the cryptographic primitive passes, the impersonation succeeds at the message-authentication layer, and the per-Workspace-tenant incident-response priority is per- selector key revocation + rotation — the DKIM-for- Workspace spoke documents the per- Workspace-tenant Authenticate-email Rotate Key + Stop authentication workflow operators execute on every per-selector key suspected to be compromised; (iii) cousin- domain phishing variant cannot forge the cryptographic chain-of-custody back to the legitimate per-Workspace- tenant per-custom-domain google._domainkey.<d> publication because the cousin-domain attacker publishes their own per- tenant per-cousin-domain selector TXT publication independently — the forensic-attribution chain is what the Workspace-hosted brand operator and the receiver-side incident- response team trace via the per- message d= + s= tags — the per-message DKIM-Signature d=cousin-domain + s=cousin-selector trace is the cryptographic-forensic- attribution chain back to the attacker's DNS publication infrastructure; (iv) per- Workspace-tenant per-custom-domain DKIM-signing posture is the load- bearing cryptographic-authentication upstream prerequisite for the DMARC-aligned-DKIM-pass verdict the per-Workspace-tenant operator's DMARC p=reject ramp depends on to defeat the direct- spoof phishing variant at the receiver-side SMTP-rejection boundary — the per- Workspace-tenant Authenticate-email Start toggle is the canonical per- tenant cryptographic-authentication- publication primitive without which the per-publisher per-domain DMARC p=reject ramp produces 100% per-message dkim=fail + 100% per-message spf=fail verdicts at the receiver-side, defeating the intended anti-phishing-impersonation defence. Read this anti-phishing- protection playbook when EXECUTING the per-Workspace-tenant per-domain anti-phishing defence-portfolio publication; read the DKIM-for- Workspace spoke when DEPLOYING the upstream per-Workspace-tenant per- custom-domain DKIM-signing posture whose per-message DKIM-pass verdict is the load-bearing cryptographic- anti-spoof proof every phishing- impersonation variant THIS page catalogues must structurally defeat.
• DKIM for Microsoft 365 — the PER-M365-TENANT-DKIM-SIGNING- DISCIPLINE-AS-ANTI-PHISHING- CRYPTOGRAPHIC-AUTHENTICATION-PRIMITIVE companion to this anti-phishing- protection playbook. Where THIS page documents the per-publisher per- domain anti-phishing defence-portfolio the M365-tenant operator publishes to defend the brand-domain against the canonical phishing-and-impersonation attack classes (direct-spoof, cousin- domain look-alike, compromised-vendor, BEC-overlap, credential-harvesting landing-page, consent-phishing), the DKIM-for-M365 spoke documents the UPSTREAM per-M365-tenant per-custom- domain DKIM-signing deployment workflow (Exchange Admin Center > mail-flow > DKIM; per-tenant per- custom-domain DKIM-Enable toggle; per-tenant per-custom-domain dual- selector1 / selector2 rotation under selector1._domainkey.<d> + selector2._domainkey.<d> published as per-tenant CNAME pointers to per-tenant provider- managed selector*-<tenantId>._domainkey.<onmicrosoft-tenant>; per-tenant Rotate-DKIM-Keys cadence) whose per-M365-tenant DKIM-pass- then-DMARC-aligned-DKIM-pass verdict is the LOAD-BEARING per-message cryptographic anti-spoof proof every phishing-impersonation variant against an M365-hosted brand domain THIS page catalogues must structurally defeat to land at the victim's inbox under the spoofed From-header identity. The PHISHING- PROTECTION-VS-M365-DKIM cross- reference establishes FOUR structurally-distinct per-M365- tenant per-domain anti-phishing cryptographic-authentication coupling dimensions: (i) direct-spoof phishing variant attempts to forge the M365-hosted brand domain's From- header without producing a per- message DKIM-Signature cryptographically valid under the per-M365-tenant per-custom-domain provider-managed selector1 / selector2 RSA-2048 public key — the absence of a valid signature under d=m365-brand-domain with s=selector1 or s=selector2 is the immediate cryptographic-anti-spoof- proof the receiver-side DKIM verifier returns dkim=fail on, gating downstream DMARC-aligned-DKIM-pass evaluation; the DKIM-for-M365 spoke documents the per-M365-tenant Exchange-Admin-Center DKIM-Enable deployment whose per-tenant per- custom-domain dual-selector CNAME publication is the load-bearing cryptographic-anti-spoof-proof primitive; (ii) compromised- vendor phishing variant produces a per-message DKIM-Signature cryptographically valid under the compromised vendor's M365 per- tenant per-custom-domain selector key — the cryptographic primitive passes, the impersonation succeeds at the message-authentication layer, and the per-M365-tenant incident-response priority is per- selector key revocation via the Microsoft-managed Rotate-DKIM-Keys workflow — the DKIM-for- M365 spoke documents the per-M365- tenant Rotate-DKIM-Keys + Disable- DKIM-signing workflow operators execute on every per-tenant per- custom-domain key suspected to be compromised; (iii) cousin- domain phishing variant cannot forge the cryptographic chain-of-custody back to the legitimate per-M365- tenant per-custom-domain selector*._domainkey.<d> CNAME pointing at provider-managed per-tenant selector records because the cousin-domain attacker publishes their own per-tenant per-cousin- domain selector CNAME publication independently — the forensic- attribution chain is what the M365- hosted brand operator and the receiver-side incident-response team trace via the per-message d= + s= tags — the per-message DKIM-Signature d=cousin-domain + s=cousin-selector trace is the cryptographic-forensic- attribution chain back to the attacker's DNS publication infrastructure; (iv) per- M365-tenant per-custom-domain DKIM- signing posture is the load-bearing cryptographic-authentication upstream prerequisite for the DMARC-aligned-DKIM-pass verdict the per-M365-tenant operator's DMARC p=reject ramp depends on to defeat the direct-spoof phishing variant at the receiver- side SMTP-rejection boundary — the per-M365- tenant DKIM-Enable toggle in the Exchange Admin Center is the canonical per-tenant cryptographic- authentication-publication primitive without which the per- publisher per-domain DMARC p=reject ramp produces 100% per-message dkim=fail verdicts at the receiver-side, defeating the intended anti-phishing- impersonation defence. Read this anti-phishing-protection playbook when EXECUTING the per-M365-tenant per-domain anti-phishing defence- portfolio publication; read the DKIM-for-M365 spoke when DEPLOYING the upstream per-M365-tenant per- custom-domain DKIM-signing posture whose per-message DKIM-pass verdict is the load-bearing cryptographic- anti-spoof proof every phishing- impersonation variant THIS page catalogues must structurally defeat.
• SPF DNS record syntax — the PER-PUBLISHER-PER-DOMAIN-SPF- RECORD-BYTE-LEVEL-PUBLICATION-DISCIPLINE-AS- FOUNDATIONAL-ANTI-PHISHING-FIRST-LEG- AUTHENTICATION-EVIDENCE companion to this phishing-protection playbook. Where THIS page documents the per-publisher per- domain anti-phishing defence-portfolio catalogue (per-attacker per-message domain-spoofing / display-name spoofing / cousin-domain / homograph / BEC variants), the SPF-DNS-record-syntax spoke is the per-publisher-per-domain FOUNDATIONAL FIRST-LEG-AUTHENTICATION publication reference every per-publisher anti-phishing defence-portfolio depends on per-source-IP- restrictively publishing at FOUR per- phishing-attack-variant defence-evidence dimensions: (i) per-publisher per-domain SPF -all hardfail qualifier as per-source-IP-restrictive per-message envelope-MAIL-FROM authorisation defeating per-attacker per-source-IP-spoofing of the publisher domain — the per- publisher per-domain SPF DNS record's -all hardfail qualifier publishes the per- publisher per-domain per-source-IP authorisation list as PER-SOURCE-IP-CLOSED (only the listed ip4:/ip6:/a/mx/include:- resolved IPs authorised; ALL OTHER per- source-IPs rejected at the per-receiver per-message envelope evaluation), defeating per-attacker per-source-IP-spoof variants that attempt to send mail from arbitrary per-source-IPs with the per-publisher per-domain in the envelope-MAIL-FROM — the per-source-IP-restrictive SPF publication is the per-publisher per- domain FIRST-LEG anti-phishing-defence per-message authorisation gate; (ii) per-publisher per-domain SPF include: chain audit as per-attacker per-tenant-SaaS-platform-compromise per-source-IP-authorisation-leak prevention — the per-publisher per-domain SPF DNS record's include: chain documents the per-tenant SaaS platforms the per-publisher per-domain authorises to send mail on per-publisher per-domain behalf (Salesforce, HubSpot, Mailchimp, SendGrid, Mailgun, etc.) — per-publisher anti-phishing-defence operators audit the per-include: chain regularly to remove decommissioned per- tenant SaaS authorisations (per-attacker per-tenant-SaaS-platform compromises of decommissioned-but-still-include:d per- publisher per-domain authorisations is a per-attacker per-publisher per-domain envelope-MAIL-FROM phishing-launch vector); (iii) per-publisher per-domain SPF DNS record + per-publisher per-domain DMARC sp= subdomain-policy as per-attacker per-publisher per- subdomain phishing-launch defence complement — the per-publisher per-domain SPF DNS record syntax reference documents the per-publisher per-subdomain SPF publication discipline (per-publisher per-subdomain SPF records published with -all hardfail at every used-or-reserved per-publisher per- subdomain) that complements the per- publisher per-domain DMARC sp= subdomain- policy publication — together they per-source-IP-restrictively gate per- attacker per-publisher per-subdomain envelope-MAIL-FROM phishing variants (attacker cousin-domains spoofing billing.publisher.com, support.publisher. com, accounts.publisher.com etc.); (iv) per-publisher per-domain SPF DNS record macro-expansion (RFC 7208 §7) as per-receiver per-message per-publisher per-customer-segment dynamic- authorisation-decision evidence complement — the per-publisher per-domain SPF DNS record's RFC 7208 §7 macro-expansion (per-receiver per- message %{i} sender-IP / %{s} sender- address / %{h} sender-HELO / %{d} sender-domain substitution) is the per- publisher per-customer-segment dynamic- per-source-IP-authorisation publication discipline that per-publisher per-domain anti-phishing-defence operators use to per-customer-segment per-source-IP- restrictively scope per-publisher per- domain SPF authorisations (limiting per- customer-segment per-source-IP authorisation surface area to per- customer-segment per-source-IP- restrictive ranges, defeating per- attacker per-customer-segment per-source-IP-spoof variants). Read the SPF DNS record syntax spoke alongside this phishing-protection playbook when AUDITING the per-publisher per-domain SPF DNS record's per-source-IP authorisation publication discipline for per-attacker per-source-IP-spoof defence, when AUTHORING per-publisher per-domain SPF publication runbooks for the anti-phishing-defence portfolio, when EXECUTING per-publisher per-domain per-tenant SaaS-platform per-include: chain audit cadence as per-attacker per-publisher per-domain phishing- launch-prevention discipline, or when ESTABLISHING the per-publisher per- domain SPF -all hardfail terminal qualifier publication as the per- publisher per-domain per-source-IP- restrictive FIRST-LEG-AUTHENTICATION publication discipline complementing the per-publisher per-domain DKIM- signing + DMARC-policy + MTA-STS- publication + TLS-RPT-evidence- attribution defence portfolio.
• TLS-RPT (SMTP TLS Reporting RFC 8460) explained — the PER-PUBLISHER-PER-DOMAIN- TRANSPORT-LAYER-OBSERVABILITY-PUBLICATION- AS-LOAD-BEARING-ANTI-PHISHING-DEFENCE- STACK-TRANSPORT-LAYER-EVIDENCE-ATTRIBUTION- STREAM companion to THIS phishing- protection defence-stack catalogue reference. Where THIS page documents the per-publisher per-domain anti-phishing defence-stack catalogue (per-publisher per- domain SPF + DKIM + DMARC composite- authentication receiver-side enforcement, per-publisher per-domain lookalike-domain / IDN-homograph detection, per-publisher per- domain OAuth-consent-abuse mitigation, per- publisher per-domain MFA-push-bombing defense, per-publisher per-domain AiTM proxy-kit mitigation), the TLS-RPT spoke is the PER-PUBLISHER-PER-DOMAIN-TRANSPORT- LAYER-OBSERVABILITY-PUBLICATION companion at FOUR per-phishing-defence-control-vs- TLS-RPT-observability coupling dimensions: (i) per-publisher per-domain TLS- RPT transport-layer-observability stream AS load-bearing transport-layer evidence- attribution input feeding per-publisher per-domain anti-phishing defence-stack AiTM-proxy-kit-detection evidence pipeline — the per- publisher per-domain TLS-RPT JSON- aggregate-report per-MX-host per-day transport-layer-observability stream the TLS-RPT spoke documents (per-publisher per- domain per-MX-host per-day per-failure- type-bucket evidence-row ingestion, per- publisher per-domain certificate-name- mismatch / certificate-expired / certificate-not-trusted per-MX-host per- failure-bucket attribution) IS the per- publisher per-domain load-bearing transport- layer evidence-attribution input feeding the per-publisher per-domain anti-phishing defence-stack AiTM-proxy-kit-detection evidence pipeline THIS page documents the per-attacker per-publisher per-victim per- session credential-relay attack-class defence control of; per-publisher per- domain operators consume per-publisher per- domain TLS-RPT per-MX-host transport-layer- anomaly evidence as per-publisher per- domain AiTM-proxy-kit-detection input at the per-publisher per-domain transport- layer-anomaly anti-phishing-correlation boundary; (ii) per-publisher per- domain TLS-RPT transport-layer- observability stream AS load-bearing transport-layer evidence-attribution input feeding per-publisher per-domain anti- phishing defence-stack MTA-STS-mode- enforce-publication-readiness-floor verification pipeline — per-publisher per-domain MTA-STS mode=enforce transport-layer- enforcement-publication-floor commitment IS verifiable per-publisher per-domain operationally via the per-publisher per- domain TLS-RPT per-MX-host per-day enforcement-failure-rate-floor observability stream the TLS-RPT spoke documents the per-publisher per-domain transport-layer-evidence-attribution discipline of; per-publisher per-domain operators measure per-publisher per- domain MTA-STS-enforcement-failure-rate- floor before-and-after per-publisher per- domain MTA-STS mode-enforce deployment as per-publisher per-domain anti-phishing- defence-portfolio MTA-STS-publication- readiness-evidence at the per-publisher per-domain transport-layer-enforcement- readiness anti-phishing-defence-validation boundary; (iii) per-publisher per- domain TLS-RPT transport-layer- observability stream AS load-bearing transport-layer-failure-attribution evidence-stream pairing with per-publisher per-domain DMARC RUA application-layer- failure-attribution evidence-stream for per-publisher per-domain cross-protocol- layer composite-failure-attribution anti- phishing defence-effectiveness measurement — the per- publisher per-domain TLS-RPT per-MX-host per-day transport-layer-failure-attribution evidence-stream the TLS-RPT spoke documents pairs operationally with the per-publisher per-domain DMARC RUA per-source-IP per- disposition row application-layer-failure- attribution evidence-stream THIS page's anti-phishing defence-stack catalogue documents the per-attacker per-attack- class detection-and-mitigation effectiveness measurement consumption of; per-publisher per-domain operators cross- reference BOTH per-publisher per-domain observability streams at the per-publisher per-domain cross-protocol-layer composite- failure-attribution anti-phishing-defence- effectiveness measurement boundary; (iv) per-publisher per-domain composite SPF + DKIM + DMARC + MTA-STS + TLS-RPT + BIMI + DANE publication-floor coordination AS load-bearing per-publisher per-domain operator-side unified-anti-phishing- defence-publication-discipline-floor — the per-publisher per-domain TLS- RPT transport-layer-observability publication discipline the TLS-RPT spoke documents IS the load-bearing transport- layer-observability leg of the per- publisher per-domain composite SPF + DKIM + DMARC + MTA-STS + TLS-RPT + BIMI + DANE publication-floor coordination posture the per-publisher per-domain anti-phishing defence-stack catalogue THIS page documents the receiver-side-enforcement + publisher- side-publication-discipline composite anti-phishing-defence-portfolio coordination of; per-publisher per-domain operators publish ALL SEVEN per-publisher per-domain protocol-layer publications coordinated at the per-publisher per-domain unified-anti-phishing-defence-publication- readiness boundary. Read THIS page when DESIGNING the per-publisher per-domain anti-phishing defence-stack catalogue; read the TLS-RPT spoke when AUDITING the per-publisher per-domain per-MX-host per- day transport-layer-observability stream whose per-publisher per-domain RFC 8460 JSON-aggregate-report ingestion discipline IS the load-bearing transport-layer leg of the per-publisher per-domain anti- phishing defence-stack catalogue THIS page documents the receiver-side and publisher-side defence control set of.
• SPF permerror vs temperror
• DNS propagation timelines
• DMARC for cPanel hosting — the PER-CPANEL-TENANT-PER-CUSTOM-DOMAIN-DMARC-ENFORCEMENT-MODE-PUBLICATION-DISCIPLINE-AS-LOAD-BEARING-PER-TENANT-PER-CUSTOM-DOMAIN-DOMAIN-SPOOFING-ATTACK-SURFACE-CLOSURE-DRIVER-AT-SHARED-HOSTING-DEPLOYMENT-CONTEXT companion at four cPanel-shared-hosting-DMARC-deployment-vs-anti-phishing-defence-stack coupling dimensions: (1) per-cPanel-tenant per-custom-domain DMARC enforcement-mode ramp p=none → p=quarantine → p=reject per RFC 7489 §6.3 IS the per-tenant per-custom-domain operator-side application-layer per-message-disposition-enforcement primitive whose progression closes per-tenant per-custom-domain From-header-domain spoofing attack-surface against per-attacker per-message lookalike-domain impersonation the per-publisher per-domain anti-phishing defence-stack THIS page catalogues seven-protocol composite-discipline of; (2) per-cPanel-tenant per-custom-domain shared-IP-pool egress at shared-MX-cluster Exim-MTA infrastructure exposes per-tenant per-custom-domain DMARC composite-aligned-pass-rate floor to cross-tenant verdict-noise contamination — the per-cPanel-tenant per-custom-domain DKIM-aligned-pass attribution leg (per-tenant selector segregation, per-tenant zero-downtime rotation) provides per-tenant identity-attribution the per-publisher per-domain anti-phishing defence-stack REQUIRES for per-receiver per-message disambiguation between legitimate-tenant per-message-emission and per-attacker per-tenant impersonation; (3) per-cPanel-tenant per-custom-domain DMARC rua=mailto: aggregate-report-URI publication per RFC 7489 §6.2 surfaces per-tenant per-custom-domain per-day per-receiver per-source-IP per-row attribution stream IS the per-tenant per-custom-domain operator-actionable per-day per-receiver per-source-IP-attribution evidence-channel through which per-tenant per-custom-domain anti-phishing-defence-stack-readiness drift surfaces and through which per-tenant per-custom-domain enforcement-mode ramp-progression is gated; (4) per-cPanel-tenant per-custom-domain seven-protocol publication-portfolio coordination (SPF + DKIM + DMARC + BIMI + MTA-STS + DANE + TLS-RPT) at per-tenant per-custom-domain DNS-publication-discipline boundary IS the per-tenant per-custom-domain operator-side composite anti-phishing-defence-stack readiness primitive THIS anti-phishing-defence-stack catalogue page documents the receiver-side and publisher-side defence control set of — the per-cPanel hosting page documents the per-tenant per-custom-domain shared-Exim-MTA / WHM application-context publication-discipline of this seven-protocol composite-portfolio coordination at the per-publisher per-domain composite shared-hosting-deployment-and-anti-phishing-defence-stack publication-discipline coordination boundary.
• SPF mechanisms explained — the PER-PUBLISHER-PER-DOMAIN-SPF-ENVELOPE-MAIL-FROM-LAYER-MECHANISM-CLASS-PUBLICATION-DISCIPLINE-AS-LOAD-BEARING-ENVELOPE-MAIL-FROM-LAYER-ANTI-PHISHING-DEFENSE-LEG companion at four per-publisher per-domain SPF-mechanism-vs-anti-phishing coupling dimensions: (i) per-publisher per-domain SPF mechanism-class catalogue (a / mx / ip4 / ip6 / include / all) per RFC 7208 §5 IS the load-bearing per-publisher per-domain envelope-MAIL-FROM-layer authorization-vocabulary publication-discipline closing the ENVELOPE-MAIL-FROM-SPOOF (RFC 5321 envelope-sender forgery) attack-class of the per-publisher per-domain anti-phishing defense-stack THIS page catalogues; (ii) per-publisher per-domain SPF -all terminal-mechanism qualifier-publication-decision IS the load-bearing envelope-MAIL-FROM-layer hard-fail enforcement-floor whose per-receiver per-message SPF-aligned-pass discipline feeds the per-publisher per-domain DMARC composite-aligned-pass-rate floor underpinning the per-publisher per-domain anti-phishing defense-stack the seven-protocol composite-discipline of; (iii) per-publisher per-domain SPF include: mechanism-class DNS-lookup-chain authorization-publication-discipline IS the load-bearing per-publisher per-domain envelope-MAIL-FROM-layer third-party-egress authorization-discipline that prevents per-attacker per-message ESP-impersonation envelope-MAIL-FROM-spoofing — the per-publisher per-domain SPF mechanism-class catalogue THIS page documents the per-publisher per-domain SPF-envelope-MAIL-FROM-layer authorization-publication-discipline of materially feeds the per-publisher per-domain DMARC strict-vs-relaxed alignment-mode evaluation closing the LOOKALIKE-DOMAIN + COUSIN-DOMAIN spoof attack-classes; (iv) per-publisher per-domain SPF mechanism-class publication-discipline drift (premature -all hardfail cutover surfacing as per-source-IP per-day DMARC RUA spf=fail attribution-distortion + permerror on 10-DNS-lookup-cap exhaustion per RFC 7208 §4.6.4 surfacing as SPF-aligned-pass-rate floor regression) directly opens per-publisher per-domain DMARC composite-aligned-pass-rate floor regression that the per-publisher per-domain anti-phishing defense-stack readiness-floor materially depends on for per-receiver per-message disambiguation between legitimate-publisher per-message-emission and per-attacker per-message-spoofing attack-class.
• DKIM DNS TXT-record byte syntax
• Email authentication glossary — the plain-language reference for the authentication vocabulary this anti-phishing page relies on. SPF, DKIM, DMARC, alignment, BEC, display-name spoof and the Authentication-Results verdicts that distinguish a legitimate sender from a spoof are each defined there in one place — read the glossary when a term in this phishing-protection guide needs grounding before you act on it.
• DMARC for Office 365 hybrid (on-premises Exchange + Exchange Online) — the deployment-context companion that closes the From-header-spoofing attack surface THIS anti-phishing page treats, in the hardest topology to get right. A hybrid Exchange tenant emits authenticated mail from TWO egress paths (on-prem Send Connector + Exchange Online outbound queue); direct-domain, lookalike and BEC spoofing is only denied once DMARC reaches p=reject AND both paths pass aligned SPF/DKIM — any path that breaks alignment leaves a spoofable seam an attacker can ride. Read the hybrid guide for the dual-egress DMARC enforcement ramp that hardens both paths in lockstep.
• Microsoft SNDS + JMRP monitoring — outbound abuse from compromised accounts or infrastructure surfaces first as spam-trap hits and Junk-click complaints: Microsoft's SNDS filter verdicts and JMRP ARF stream are an early-warning channel for your own sending IPs.

15. Start protecting against phishing now

The DMARC Analyzer platform automates the email-authentication layer of phishing defense. The includes/DnsChecker.php module audits your SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI, and CAA records; the includes/DmarcParser.php module ingests DMARC aggregate (RUA) reports and surfaces failing-authentication source IPs so you can identify phishing attempts against your domain in real time; includes/EmailHeaderParser.php and includes/ForensicReportParser.php handle Authentication-Results parsing and forensic (RUF) report ingestion for incident response.

Audit my domain phishing protection Analyze a suspicious email header Sign up — Free plan