Expert Tools

DMARC (Domain-based Message Authentication, Reporting and Conformance) sits on top of SPF and DKIM. It tells receiving mail servers two things: what to do with a message that fails both SPF and DKIM alignment (the policy: none, quarantine, or reject), and where to send reports about what's actually happening (the rua=/ruf= tags).

Why DMARC is the trickiest of the three

SPF and DKIM only need to exist and be technically correct. DMARC additionally needs them to align: the domain SPF checked, or the domain in DKIM's d= tag, has to match the domain in the message's visible "From:" address, not just pass on their own. A mail provider can have perfectly valid SPF and DKIM and still fail DMARC, if what they're signing or authorising doesn't line up with what the recipient actually sees in their inbox. Working out which of several sending services is causing a misalignment, without breaking mail from the others, is usually where DMARC stops being a five-minute DNS change and starts being an actual project, which is exactly why the reporting step below isn't optional in practice.

sp= and np= are not the same protection

Without an sp= tag, a subdomain with no DMARC record of its own simply inherits the main p= policy, and that inheritance has always been the default. sp= lets you set something different for that case, often stricter. What neither sp= nor the old RFC ever covered is a subdomain that doesn't exist at all. Mail can still claim to be from a typo'd or never-created subdomain, and DNS returning NXDOMAIN didn't stop that. RFC 9989 (DMARCbis, published May 2026 as the formal successor to the original 2015 spec) added np= specifically to close that gap. It's described by the RFC's own authors as the one genuinely new protection worth adding on its own, and it costs nothing, since by definition nothing legitimate is meant to be sending from a subdomain that isn't there.

Why this is becoming harder to ignore

Since February 2024, Google and Yahoo have required DMARC (at minimum p=none) from any domain sending 5,000+ messages a day to their users, alongside SPF/DKIM and one-click unsubscribe. Enforcement tightened in November 2025, moving from temporary deferrals to outright rejecting non-compliant mail. The 5,000/day threshold only applies to bulk senders, but the direction of travel is clear: expect the bar to keep moving from "a DMARC record exists" towards "a DMARC record actually enforces something" over the next couple of years.

The build-up path

Publishing p=reject on day one, before you're certain every legitimate sender is accounted for, risks silently dropping your own mail. The usual path: start at p=none with rua= configured so reports start arriving, read those reports for a while to confirm nothing legitimate is failing, then move to quarantine, and finally reject once you're confident. RFC 9989 adds a simple t=y flag for "still testing" (replacing the older pct= percentage tag, which the new RFC removes).

Reading the reports yourself

Aggregate reports are sent as XML attachments, once a day per reporting mail provider, and are not pleasant to read by hand. For a Thunderbird-based workflow, the DMARC Report Analyzer add-on parses them into a readable dashboard entirely on your own machine, with no upload, no network requests, and source available on GitHub under the GPL. For a domain that sends any meaningful volume of mail, or where nobody has the time to read reports regularly, a professional DMARC monitoring service is worth considering instead, since several offer automated analysis and policy recommendations based on the same reports.

One quirk worth knowing before you go looking for a setting that isn't there: the add-on picks its folder from the topmost account configured in Thunderbird, not from the domain you happen to be looking at. Managing several domains means temporarily moving the relevant account to the top of the account list to switch between them.

Especially if this domain doesn't send mail yet

The logic here is the same as on the SPF page, and worth repeating rather than assuming it carries over: a parked domain with SPF's -all and a DMARC record at p=reject has no spoofing surface at all, permanently, regardless of whether it ever gets an MX record. There's no "wait until we actually send mail" reason to delay this. If anything, setting it up before any mailbox exists is the one time it carries zero risk of breaking mail you're already relying on.