Set DMARC to p=reject, with DKIM and SPF aligned

What the control is

DMARC, DKIM and SPF together are the email-authentication stack the standards bodies have settled on for stopping domain spoofing. SPF declares which IP addresses are authorised to send mail for the domain. DKIM cryptographically signs outbound mail with a key published in DNS. DMARC binds the two together with an alignment policy and tells receiving mail servers what to do when an inbound message claiming to be from the domain fails authentication: do nothing (p=none, monitoring only), quarantine into the spam folder (p=quarantine), or refuse delivery entirely (p=reject). The end state every framework specifies is p=reject with strict alignment.

The control protects two populations at once. It protects the people receiving mail purportedly from your domain — your customers, suppliers, staff — from impersonation-led phishing and business-email-compromise. It protects your domain’s reputation in the receiver-side reputation systems that decide whether your legitimate mail reaches the inbox. The same DNS configuration achieves both.

Why it matters

The brand-impersonation BEC ecosystem is the largest single category of cybercrime by financial volume — the FBI’s IC3 reports place BEC consistently above ransomware in dollar terms. The catalogue holds several worked examples. The Bangladesh Bank SWIFT heist of February 2016 succeeded in part because attackers had cultivated email channels that looked authentic to the bank’s settlement staff, with sender-side controls that should have caught the spoofing. The Carbanak / FIN7 multi-year campaign against banks combined long-running phishing access with social-engineering spoof of internal correspondence. Twitter 2020’s Bitcoin-scam takeover relied initially on convincing internal contacts that an external lookalike address was legitimate. The MGM and Caesars vishing-led intrusions of September 2023 sat in an ecosystem where DMARC-equivalent helpdesk caller-verification was the equivalent missing control on the voice channel — same architectural gap, different medium.

DMARC reject does not single-handedly stop these attacks. It does shut the gate on the cheapest, most automatable variant: the attacker who registers no infrastructure, simply forges the From: header on outbound mail to a target’s customers or staff, and lets the mail systems route the deception. Without DMARC reject, that mail lands. With DMARC reject, it bounces.

Where the regulators sit

NCSC’s “Email security and anti-spoofing” guidance is direct: every UK organisation should set DMARC to p=reject once aggregate-report monitoring confirms legitimate mail aligns. NCSC also operates the public Mail Check service to surface non-compliant government domains. CISA’s Binding Operational Directive 18-01 mandated DMARC p=reject across all US federal civilian executive branch agencies in 2017 with a hard deadline. NIST SP 800-177 Rev. 1 (“Trustworthy Email”) is the technical reference and walks through the deployment in detail. The Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) publishes the operationally-detailed Email Authentication Recipe Book that most large enterprises follow. The Australian Cyber Security Centre repeats the same recommendation in its email-gateway hardening guidance.

The framework view has not moved meaningfully in a decade. The deployment patterns are well-understood. The recipe is published.

Where it usually breaks

Two failure modes account for almost every stalled DMARC rollout. The first is the third-party-sender inventory. Most enterprises have dozens of legitimate systems sending mail on their behalf — marketing automation, recruitment platforms, payroll providers, transactional-email services, internal helpdesk tooling. Each one needs its IP added to SPF or its DKIM key published, and the inventory is almost always incomplete on day one. The fix is the aggregate-report DMARC monitoring stage: deploy p=none with reports going to a parsing tool, run for six to twelve weeks, work through every alignment failure the reports surface, and only escalate to p=reject when the aggregate is clean.

The second is the political fear of bouncing legitimate mail during the escalation. The fear is real but bounded. The escalation path of p=none → p=quarantine → p=reject exists precisely to manage it; the right answer is to commit to the gate-closure date in advance and use the intermediate stages as the rehearsal.

What good looks like

A DMARC record at p=reject with pct=100 and strict alignment for every domain the organisation owns, including parked and brand-protection domains. Every legitimate sending system signed with DKIM and listed in SPF. Aggregate reports parsed continuously and alerted on for new senders. Forensic reports — the ones that include partial message content — disabled, because they leak. A documented owner for the email-authentication configuration, with an annual review.

The cost is the configuration time and the report-monitoring tool. The benefit is permanent removal of the cheapest impersonation vector against your domain.