DMARC in 2026: from p=none to p=reject without breaking your mail.

DMARC is the email authentication standard that ties SPF and DKIM to the domain your recipients see, tells receiving servers what to do with mail that fails, and reports back on everything sent in your name. It is defined by RFC 7489, and a message passes it when either SPF or DKIM passes and aligns with the From domain. Its power is in the policy tag: p=none watches, p=quarantine sends failures to spam, and p=reject blocks them outright. The hard part is not publishing the record; it is the journey from none to reject, which means discovering every service that sends as your domain, fixing each one's authentication, and tightening the policy in stages so you never block your own invoices and password resets. Done carelessly it breaks legitimate mail; done patiently it stops spoofing and strengthens the reputation that decides whether you reach the inbox at all.

A message passes DMARC when either SPF or DKIM passes and aligns with the From domain. The word that does the work is aligns. SPF alignment means the domain SPF authenticated matches the From domain; DKIM alignment means the domain in the DKIM signature matches it. Per RFC 7489, your policy is applied only when both SPF alignment and DKIM alignment fail, so a single aligned pass is enough to succeed. That asymmetry shapes the practical advice: you do not need both to align, you need at least one to align reliably for every legitimate sender, and DKIM alignment is usually the more dependable to lean on because a DKIM signature survives forwarding while SPF often does not.

Alignment comes in two modes. Relaxed, the default, lets a subdomain match the organisational domain, so a message signed by mail.example.com aligns with a From of example.com; strict demands an exact match. Relaxed is the right choice for almost everyone and is set with aspf=r and adkim=r, the defaults you rarely touch. Strict alignment exists for organisations with a specific reason to require exact-domain authentication, and choosing it without that reason is a common way to make legitimate mail fail for no benefit. The rollout work, then, is mostly the work of getting one aligned pass for every real sender, which is why the aggregate reports that show you alignment per source are the centre of the whole exercise.

DMARC protects the exact domain in your From header. It does nothing about lookalike or cousin domains, the addresses an attacker registers to resemble yours, examples like exampl3.com or example-support.com, because those are different domains that pass their own authentication honestly. A message from a cousin domain is not spoofing your domain; it is impersonating your brand from somewhere you have no authority, and stopping it needs brand monitoring, takedowns and recipient awareness rather than a DNS record. DMARC also does not encrypt mail, does not inspect content for phishing language or malicious links, and does not vouch for the trustworthiness of a sender it authenticates; a spammer can publish a perfectly valid DMARC record for their own domain. Its single job is to make sure that mail claiming to be from your domain genuinely is, and it does that one job well, but reading it as a general anti-phishing or anti-fraud system is how organisations end up surprised by an attack it was never designed to stop. Pair it with the other controls rather than expecting it to be all of them.

Every provider that receives mail claiming to be from your domain sends an aggregate report to your rua address, summarising the source IPs, the volumes, and whether each passed SPF, DKIM and alignment. The way to use them is to sort every sending source into three buckets. Known and passing are your healthy senders; keep a documented list of them. Known but failing are usually legitimate services that are misconfigured, a platform that needs an SPF include added or DKIM signing enabled, and these are your fix list. Unknown senders deserve scrutiny: some are harmless noise from forwarders and scanners, and some are genuine abuse of your domain that DMARC is now showing you for the first time. At this stage DMARC stops being a DNS task and becomes an operational one, often needing input from marketing, sales, support and engineering, because the senders you have to account for live across all of them.

The raw XML is readable but tedious at scale, which is why reporting platforms exist to turn it into dashboards of senders, pass rates and alignment issues. A platform makes the work faster, but it does not change the discipline: classify every source, fix the legitimate ones, investigate the unknowns, and do not tighten the policy until the picture is clean. Forensic reports, requested with the ruf tag, are a different and lesser tool, sample copies of individual failing messages that help with debugging but are supported by few providers and carry privacy weight because they can include personal data. Most decisions come from aggregate reports; treat forensic reports as an occasional diagnostic rather than a routine feed.

Jumping straight to reject is the classic, blocking legitimate senders you never knew existed. Staying at p=none forever is the opposite failure, common and quieter, publishing a record for compliance and never gaining protection. The SPF ten-lookup limit catches growing senders: route mail through enough third-party services and your SPF record breaches the cap, SPF fails, and that cascades into DMARC failures for legitimate mail, which is fixed by auditing and flattening the SPF record to stay within the limit. Forwarding and mailing lists break alignment, because forwarding defeats SPF and lists modify messages in ways that break DKIM signatures, and the answer is to recognise those flows in your reports and lean on ARC, which preserves authentication results across a hop. The common thread is that all of these are visible in aggregate reports before they become a crisis, and all are recoverable without an emergency if you ramp with the pct tag and drop back a step when a legitimate sender starts failing rather than pushing through.

SPF evaluation is capped at ten DNS lookups, a limit built into the standard to stop a single check from triggering an unbounded chain of queries. Each include in your SPF record, every third-party service you authorise, a marketing platform, a help desk, an invoicing tool, a CRM, consumes part of that budget, and several of them nest further lookups inside their own includes. Add enough senders and the record silently exceeds ten lookups, at which point SPF returns a permanent error rather than a pass. Because DMARC needs an aligned SPF or DKIM pass, a broken SPF record removes one of the two ways legitimate mail can succeed, and any sender that was relying on SPF alignment rather than DKIM starts failing DMARC. The failure is invisible until you read the reports, and it grows naturally as a company adds tools, which is why a rollout that was clean six months ago can drift into trouble.

The fix is to audit the SPF record, count the lookups, and flatten it, replacing nested includes with the resolved IP ranges so the record stays within the limit, or moving senders to DKIM alignment where it is more dependable anyway. Tools exist to flatten and monitor SPF automatically, but the principle is to treat the ten-lookup budget as a resource you actively manage rather than discover you have overspent. This single constraint is worth checking first whenever previously-passing mail starts failing DMARC, because it is both the most common cause and the easiest to overlook in a record that looks correct line by line.

Aggregate reports are standard XML sent to whatever address your rua tag names, which means a self-hosted parser can ingest, aggregate and visualise them without handing the data to a third-party platform. That matters beyond cost: the reports reveal every service that sends as your domain, which is a map of your operations that you may not want to share outside your own infrastructure, and keeping the parsing in-house keeps that map private. On a stack you control, the same discipline that runs SPF and DKIM correctly extends naturally into DMARC: align every sender, watch the reports, ramp with the pct tag, and reach reject on a schedule the reports justify rather than a date on a calendar. The trade-off is that you build and maintain the ingestion and the dashboards; the benefit is full control and no outside service holding your sending map. For a multi-brand operator or an agency running many client domains, that control compounds: the same in-house parser handles every domain, separates results cleanly, and never exposes one client's sending map to a platform shared with others, which is the kind of separation that matters when the domains belong to distinct businesses that should not be visible to each other.

DMARC also does not stand alone. It is the enforcement layer over the SPF and DKIM that the bulk sender requirements demand, it is a prerequisite for the brand-logo display of BIMI, and a domain at reject is one whose reputation a provider can trust is genuinely yours, which feeds the inbox placement that warming a sender and honouring unsubscribes also protect. That is the lens we bring, because we run sending infrastructure and read these reports rather than only advise on them, and getting to reject without breaking mail is exactly the kind of careful, months-long work that rewards someone watching it closely. Where it helps to have the authentication built, the reports read, and the ramp run by people who do it for a living, that is the work our deliverability audit and wider email infrastructure practice exist to do.