DMARC: A Practical Path from p=none to p=reject Without Breaking Production

Publishing a DMARC record is a five-minute job. Reaching p=reject without breaking mail that your business depends on is a project, and the gap between those two facts is where most DMARC rollouts stall — usually at p=none, permanently, generating reports nobody reads.

The risk is real but it is also specific and knowable. At p=reject, mail that fails DMARC is rejected outright. If some system you forgot about — the billing platform, the recruiting tool, the ten-year-old CRM in another department — is sending as your domain without authentication, that mail stops arriving. Not lands in spam. Stops.

This guide is the rollout, not the syntax reference: how to find every sender before you enforce anything, what the reports actually tell you, and how to ramp policy so that if something is going to break, it breaks visibly and in small quantities rather than all at once.

What DMARC Actually Enforces

SPF and DKIM each answer a narrow question. SPF asks whether the server that delivered this message is on a list the domain owner published. DKIM asks whether the message carries a valid cryptographic signature from a key the domain owner published.

Neither answers the question a recipient actually cares about: is this message really from the brand in the From line? That is what DMARC adds. It ties SPF and DKIM to the domain the recipient sees, and tells the receiving server what to do when neither one lines up.

A DMARC record is a TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1

The tags that matter for a rollout:

The Part That Breaks Things: Alignment

Here is the single concept that explains almost every surprising DMARC failure. A message can pass SPF and still fail DMARC. It can carry a perfectly valid DKIM signature and still fail DMARC.

DMARC does not just require SPF or DKIM to pass. It requires that the domain they passed for matches the domain in the visible From header. That match is called alignment, and mail involves more domains than most people expect:

• The From header — what the recipient sees, and the only one DMARC cares about aligning to.
• The Return-Path (envelope sender) — what SPF actually validates. Many sending platforms set this to their own domain by default.
• The DKIM signing domain (d= in the signature) — what DKIM actually validates.

So the common failure is not “SPF is broken”. It is: SPF passed for the platform’s domain, DKIM signed with the platform’s domain, and the From header says your domain. Every check passes on its own terms, and DMARC still fails, because nothing authenticated the identity the recipient was shown.

This is why “we have SPF and DKIM set up, we’re fine” is not a safe assumption. It has to be your domain on at least one of the two.

Relaxed alignment (the default) accepts an organisational-domain match: mail.example.com aligns with example.com. Strict alignment demands an exact match. Relaxed is right for almost everyone; strict mainly buys you protection against a subdomain you already control being abused, at the cost of much more fragile rollouts.

For a domain sending through Brixus365, DKIM alignment is handled by the CNAME you add during domain setup — bx1._domainkey.yourdomain.com pointing at bx1.dkim.brixus365.com — which signs with your domain rather than ours. The SPF include (v=spf1 include:spf.brixus365.com ~all) authorises the sending infrastructure. The domain configuration guide walks through both records; what matters for DMARC is that the DKIM signature carries d=yourdomain.com, which is what makes it align.

Before You Publish Anything: Find Every Sender

Most organisations underestimate their sender count by a wide margin. Marketing email and the application’s transactional email are the two everyone remembers. The list is longer:

• Invoicing and billing platforms
• Helpdesk and support ticketing
• ATS / recruiting tools
• CRM and sales-engagement tools
• Calendar and scheduling tools
• Survey and NPS tools
• E-signature services
• Monitoring and alerting that emails as alerts@yourdomain.com
• Legacy on-premise systems, scanners, and copiers configured a decade ago
• Whatever a department signed up for last quarter without telling anyone

You cannot build this list reliably by asking around; someone always forgets. Build it from the reports instead. That is the entire purpose of Stage 1.

Do this before publishing anything, though: audit your SPF record for length. SPF has a hard limit of 10 DNS lookups, and each include: costs at least one. Records that exceed it return a permanent error and SPF fails for everyone — a failure mode that is invisible until DMARC starts enforcing.

v=spf1 include:spf.brixus365.com include:_spf.google.com include:servers.example.net ~all

Count the includes. If you are near ten, consolidate or drop senders you no longer use before you go any further.

Stage 1 — p=none and Reading the Reports

Publish this and change nothing else:

v=DMARC1; p=none; sp=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1

p=none changes no delivery behaviour whatsoever. Nothing is quarantined, nothing is rejected. All it does is ask participating receivers to send you aggregate reports about mail claiming to be from your domain. This stage is safe to leave running indefinitely, and you should leave it running for at least 30 days — long enough to capture monthly billing runs, quarterly campaigns, and the reports that only fire once a cycle.

Aggregate reports arrive as gzipped XML, one per receiver per day, and they are genuinely unpleasant to read by hand. Each record looks roughly like this:

<record>
  <row>
    <source_ip>203.0.113.42</source_ip>
    <count>184</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>yourdomain.com</header_from>
  </identifiers>
</record>

Read it as: 184 messages came from this IP claiming to be from your domain; SPF passed, DKIM did not align.

Use a DMARC report processor rather than parsing these yourself — several are free at low volume. What you are looking for is a stable list of source IPs, grouped into three buckets:

That third bucket is where the exercise pays for itself, and it is also where people panic unnecessarily. Unknown sources are far more often a forgotten scanner or a departmental SaaS trial than an attacker.

You are ready to leave this stage when every legitimate source is aligned and passing. Not “mostly”. The remaining failures should be mail you are content to have dropped.

Stage 2 — Quarantine, Slowly

Quarantine sends failing mail to spam rather than rejecting it. It is recoverable — a recipient can retrieve the message from their spam folder — which makes it the right place to discover the sender you missed.

Do not jump straight to full quarantine. Use pct= to apply the policy to a fraction of failing mail:

v=DMARC1; p=quarantine; sp=quarantine; pct=10; rua=mailto:dmarc-reports@yourdomain.com; fo=1

A workable ramp, watching reports at each step and holding if anything unexpected appears:

At pct=10, a sender you overlooked has 10% of its mail land in spam. That is enough for someone to notice and complain, and small enough that it is not a crisis. That is precisely the property you want — you are buying a controlled, visible failure instead of an uncontrolled, invisible one.

Stage 3 — Reject

By now the reports should show only aligned, passing mail from sources you recognise, and a month of quarantine should have surfaced anything the inventory missed.

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@yourdomain.com; fo=1

pct= is unnecessary here — you have already done the ramp. Keep rua= in place permanently. New vendors get added to companies constantly, and the reports are how you find out that someone in another department has wired one up to send as your domain.

One genuine benefit worth knowing: several mailbox providers display brand indicators (BIMI) only for domains at p=quarantine or p=reject. Enforcement is a prerequisite, not a bonus.

What Breaks, and How to Tell It’s You

Three legitimate mail flows break under DMARC through no fault of your configuration. Recognising them saves you from chasing a problem you cannot fix at the DNS level.

Forwarding breaks SPF. When a recipient auto-forwards your message, the forwarding server delivers it from its IP, which is not in your SPF record. SPF fails. DKIM, however, signs the message content and survives forwarding intact — so a message with aligned DKIM still passes DMARC. This is the strongest practical argument for making sure DKIM is aligned rather than relying on SPF alone.

Mailing lists break both. Discussion lists frequently modify the subject (adding [list-name]) or append a footer to the body. That invalidates the DKIM signature, and the list server’s IP fails SPF. Well-run lists handle this by rewriting the From header to the list’s own domain. Badly-run ones do not, and their mail will fail under enforcement. This is a known, accepted cost of DMARC and not something you can configure around.

“Send as” features break alignment. A colleague configuring a personal mail client to send as you@yourdomain.com through an unrelated provider produces mail that fails DMARC by design. Under p=reject it will not be delivered.

How to tell whether a delivery problem is DMARC: check the message headers of something that failed. An Authentication-Results header shows each check’s verdict directly:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@yourdomain.com;
  spf=pass smtp.mailfrom=bounce.brixus365.com;
  dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=yourdomain.com

Note what that example shows: SPF passed for a different domain than the From header, and DMARC still passed — because DKIM aligned. That is alignment doing its job, and it is the normal, healthy state for mail sent through a platform.

If dmarc=fail appears with p=REJECT, you have found your cause. If DMARC passes and mail is still going to spam, the problem is reputation rather than authentication — the sending reputation guide covers what to do about that, and the deliverability guide covers the fundamentals underneath both.

Getting your domain authenticated is the prerequisite for all of it. If you are setting up sending from scratch, Brixus365 generates your SPF and DKIM records during domain setup and verifies them for you — start free, 9,000 emails a month, no card — and then publish your own DMARC record on top and begin at Stage 1.

Frequently Asked Questions