Deployment, ongoing support, SPF flattening, managed hosting, and monthly reporting that an exec can actually read. We get domains to p=reject without losing legitimate mail.
Most domains we audit have all three records published. Plenty still get spoofed. Knowing which record does what tells you where the gap is.
A list of IP addresses authorised to send mail for your domain. The receiver checks the connecting IP against your list. Pass or fail, in DNS.
The sending server signs each message with a private key. The receiver fetches your public key from DNS and verifies the signature. Tamper with the message, the signature fails.
SPF and DKIM only matter if you tell receivers what to do when they fail. DMARC publishes the policy (none, quarantine, reject) and asks for aggregate reports so you can see who's trying to send as you.
For years, DMARC was something banks and large enterprises worried about. That ended in February 2024, when Google and Yahoo's bulk-sender requirements came into force: any domain sending more than 5,000 messages a day to Gmail or Yahoo users must publish a DMARC record. Microsoft 365 followed, tightening its inbound authentication filters. Campaigns from unauthenticated domains are now being junked or rejected outright.
Cyber insurance moved at the same time. We've been on renewal calls where the underwriter's questionnaire asks specifically for the p= tag, the RUA endpoint address, and whether reports are being monitored by a human or just an inbox nobody reads. "We have DMARC" at p=none stopped being a satisfactory answer sometime in 2025. What underwriters are now asking about DMARC has changed more in the past 18 months than in the previous decade.
Business email compromise is the other driver. By most measures it's the most expensive cybercrime category by reported losses, and nearly all of it relies on either a lookalike domain or a direct spoof. DMARC at p=reject kills the direct-spoof vector outright. If your domain isn't at full enforcement, someone with a mail server and ten minutes can send messages that look exactly like they came from your CFO. The mechanics of what p=reject actually does aren't complicated, getting there without breaking your own mail is where most organisations stall.
The bottleneck on every DMARC project we run is not the DNS work. It is reading the aggregate reports week after week, catching the new sender that marketing stood up on a Friday afternoon, and chasing a payroll vendor for a DKIM selector that was meant to land two months ago. That ongoing work is what most teams do not have capacity for, and it is the part of managed DMARC that actually keeps a domain at p=reject.
The ramp from p=none to p=reject takes three to six months for a typical organisation. The bottleneck is rarely technical. Finding out which IPs a payroll vendor uses, waiting for the helpdesk platform to publish a DKIM selector, watching the quarantine-phase reports daily so nothing legitimate catches, that's the work. We've done it enough times to know where it stalls and how to keep it moving.
Two-week observation at p=none. We map every IP, every selector, every include. Marketing always finds something they forgot.
Fix the lookup-limit ceiling, rotate weak DKIM keys to 2048-bit, and align every legitimate sender. This is the heavy-lifting phase.
Move to p=quarantine with pct=10, then pct=25, then pct=100 over four to eight weeks. We watch the reports daily and pull back if anything legitimate is failing.
Full enforcement. From here it's monitoring, monthly reporting, and a friendly heads-up the first time a new sender shows up unannounced.
Audit, deployment, SPF and DKIM alignment, the ramp to p=reject, managed RUA hosting, and a monthly executive summary written in English. We get domains to full enforcement without losing legitimate mail.
Audit, deployment, SPF and DKIM alignment, the ramp to p=reject, managed RUA hosting, and a monthly executive summary written in English. We get domains to full enforcement without losing legitimate mail.
