Stopping Business Email Compromise: A Practical DMARC Rollout

Why email authentication is a rollout, not a DNS task

Publishing a DMARC record takes minutes. Reaching a reject policy safely can take months because every legitimate sender that uses your domain must authenticate and align. Payroll platforms, CRM campaigns, support tools, recruitment systems, printers, monitoring services, and regional marketing agencies often send mail without the central messaging team knowing they exist.

That hidden inventory is why copying a strict record from a checklist can interrupt invoices, password resets, or customer notifications. The defensible approach is progressive enforcement: observe all sources, repair legitimate traffic, quarantine a controlled portion, then reject unauthenticated mail when the evidence shows that the remaining failures are unwanted.

The objective is precise. DMARC prevents an attacker from using your exact visible domain in the From header when the message does not pass an aligned SPF or DKIM check. It reduces direct-domain spoofing and improves provider trust. It does not authenticate the person operating a legitimate account, and it does not stop lookalike domains.

What SPF, DKIM, and DMARC each contribute

SPF publishes which systems may send for a domain used in the SMTP envelope. The receiving server checks the connecting IP against that policy. SPF is useful but fragile under forwarding because the forwarder becomes the connecting system. It also has a ten-DNS-lookup evaluation limit, which makes long chains of SaaS includes operationally risky.

DKIM adds a cryptographic signature to message headers and content. The receiver retrieves the public key from DNS and verifies that signed fields were not altered. A valid signature can survive forwarding when intermediaries do not rewrite signed content. Rotate selectors, protect private keys, and use sufficiently strong keys supported by your mail provider.

DMARC connects authentication to the From address users see. A message passes when SPF or DKIM passes and the authenticated domain aligns with the visible From domain. The record also tells receivers whether to take no action, quarantine, or reject failures, and where to send aggregate reports. Alignment is the concept many incomplete guides miss.

Phase one: inventory with p=none

Begin with one DMARC record at _dmarc.example.com using p=none and an aggregate-report destination controlled by your organisation or a trusted processor. Confirm the reporting mailbox can handle compressed XML and that its privacy and retention settings are documented. Reports contain sending infrastructure and message counts, not message bodies, but they are still security telemetry.

Observe for at least two normal business cycles. Map each source to an owner, business purpose, volume, SPF result, DKIM result, and alignment status. Include low-volume systems: a quarterly investor platform or annual benefits portal will not appear in a one-week sample. Search procurement records and DNS configuration to discover systems that reports have not yet captured.

Do not solve every failure by adding another SPF include. Prefer aligned DKIM for third-party platforms because it survives forwarding and avoids SPF lookup sprawl. Give each provider a dedicated selector or subdomain where feasible so it can be rotated or retired without affecting other senders.

Phase two: repair legitimate senders

For Microsoft 365, Google Workspace, and major transactional providers, enable custom-domain DKIM and verify that the signing domain aligns. For systems that cannot sign, use a dedicated subdomain with a narrow SPF policy and a visible From address on that subdomain. Do not allow an obsolete application to hold the entire organisational domain at p=none indefinitely.

Check SPF flattening claims carefully. A static flattened record can become stale when a provider changes its infrastructure, while an automated service adds a new dependency and must be governed like any security control. The better long-term design is fewer SPF-authorised vendors, aligned DKIM for major senders, and separate subdomains for distinct mail streams.

Forwarding and mailing lists create legitimate failures. Authenticated Received Chain can help receivers evaluate intermediary handling, but adoption is not universal. Your rollout data should distinguish predictable forwarding failures from unknown direct sources rather than declaring every failed message malicious.

Phase three: quarantine, then reject

Move to p=quarantine with a percentage such as pct=10 only after high-volume legitimate senders align. Increase the percentage while monitoring delivery complaints, provider dashboards, and aggregate reports. Some receivers do not apply percentage sampling identically, so treat it as risk reduction rather than a perfect laboratory control.

When known legitimate traffic consistently passes, move to p=reject. Set an explicit subdomain policy with sp=reject unless there is a documented reason to permit unauthenticated subdomain mail. A protected apex with forgotten subdomains leaves an obvious impersonation path.

Keep monitoring after enforcement. New SaaS platforms appear, vendors rotate infrastructure, and teams change campaign tools. Add email-sending approval to procurement and change management: no system should use a corporate domain until an owner, signing method, data classification, and retirement process are recorded.

What DMARC does not stop

An attacker can register a visually similar domain, compromise a supplier, or take over a real employee mailbox. Those messages may pass authentication perfectly. Defending against business email compromise therefore requires controls around identity, payments, and human verification—not only DNS.

Use phishing-resistant MFA for administrators and high-risk roles, disable legacy authentication, monitor impossible travel and suspicious inbox rules, and alert on unusual OAuth consent. Finance processes should require out-of-band verification for bank-detail changes and high-risk payments using a known contact path, never the phone number supplied in the request.

Secure domain registration with strong account authentication, registry lock where appropriate, and monitored certificate-transparency and lookalike-domain signals. Train staff around concrete workflows such as invoice diversion and executive impersonation rather than generic ‘spot the bad email’ quizzes.

A 90-day enforcement plan

During days 1–30, publish p=none, collect reports, inventory senders, and assign owners. During days 31–60, configure aligned DKIM, simplify SPF, separate problematic streams onto subdomains, and test high-value messages across major mailbox providers. Record expected volumes so sudden changes can be investigated.

During days 61–75, apply quarantine to a small percentage and increase it as evidence allows. During days 76–90, move the organisational domain and unused subdomains to reject, publish the operating runbook, and define an emergency exception process that expires automatically.

The final deliverable is not the DNS record. It is an owned service: a sender registry, a report-review cadence, key-rotation responsibilities, a procurement gate, and metrics for aligned legitimate volume and unauthorised sources. That operating model is what keeps enforcement intact after the project team disbands.