DMARC rollout from p=none to p=reject

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy layer above SPF and DKIM that tells receiving mail servers what to do when authentication fails. Moving from no DMARC to p=reject is a journey, typically 6–12 months for an organisation with significant email infrastructure.

The DMARC policy stages

Three policy levels:

• p=none — monitor only. Report-only mode. No enforcement; receivers send DMARC reports but don't act on failures.
• p=quarantine — send unauthenticated mail to Junk Email / quarantine. Soft enforcement.
• p=reject — reject unauthenticated mail entirely. Strong enforcement; never delivered.

The journey: start at p=none, gather data, fix issues, progressively move to enforcement.

Pre-rollout

Before publishing a DMARC record:

1. SPF record must be in place and accurate.
2. DKIM must be signing all outbound mail from your domain.
3. Inventory all senders — every system that sends email as your domain (marketing platforms, helpdesk, CRM, internal applications, third-party services).
4. DMARC reporting endpoint — set up to receive aggregated and forensic reports.

Reporting endpoints typically point to DMARC analyser services (DMARCian, Valimail, Easy DMARC, dmarcanalyzer.com) or a custom mailbox you'll analyse manually. The analyser services are dramatically more efficient.

Publish at p=none

Add a DNS record at _dmarc.yourdomain.com:

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

This says:

• DMARC version 1.
• Policy: none (just monitor).
• Aggregated reports to the specified address.
• Forensic reporting flag.

Wait 1–2 weeks. Reports start arriving — Gmail, Outlook, Yahoo, and other providers send daily aggregated reports showing sends from your domain and their authentication status.

Analyse the reports

The reports show:

• Sending IPs / sources for your domain.
• SPF and DKIM authentication results per source.
• DMARC alignment — whether the SPF/DKIM-authenticated domain matches the From: header.
• Volume per source.

You'll discover:

• Legitimate senders failing — typically because SPF doesn't include their IP or DKIM isn't configured.
• Unknown senders — marketing platform you forgot, shadow IT sending email.
• Spoofers — bad actors sending fake email from your domain (this is what DMARC is for).

Fix legitimate failures

For each legitimate sender failing DMARC:

• Add their SPF mechanism to your SPF record (subject to SPF's 10-lookup limit).
• Configure DKIM signing on their platform — usually a vendor configuration.
• Update DMARC alignment if the sender uses a subdomain.

This is where the multi-month timeline comes from — coordinating with each sending team to fix their setup.

Move to p=quarantine

Once legitimate senders are reliably passing:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourcompany.com

pct=25 says "apply this policy to 25% of failures" — partial enforcement during transition. Increase to 50, 75, 100 over weeks. Monitor reports for impact.

Quarantine sends failing mail to Junk Email. Recipients receive it but it's flagged.

Move to p=reject

Final state:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourcompany.com

Failing mail is rejected — never delivered. Strongest anti-spoofing protection.

By this point, all legitimate senders should be authenticated, so reject only affects actual spoofing attempts.

Subdomain policy

DMARC supports separate policy for subdomains via sp=:

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

Without sp=, subdomains inherit the main policy. For specific subdomain control (e.g., marketing.yourdomain.com with different posture), use a separate subdomain DMARC record.

Modern requirements

In 2024, Gmail and Yahoo introduced bulk-sender requirements mandating DMARC for senders sending more than 5,000 messages a day to their users. Without DMARC, these senders get throttled or blocked. This has accelerated DMARC adoption significantly.

BIMI

Once you're at p=quarantine or p=reject, you qualify for BIMI — Brand Indicators for Message Identification — displaying your brand logo next to email in supported clients. A nice reward for completing the DMARC journey.

Operational considerations

• DMARC analyser service is worth the cost for non-trivial volumes.
• Quarterly review of DMARC reports — new senders appear; old senders change configurations.
• Document the sending sources for future operations.
• Reporting endpoint resilience — if the endpoint goes down, you lose reports temporarily.

For organisations with significant email infrastructure, the DMARC journey is one of those investments that's invisible when complete and obviously broken when not. Start at p=none, finish at p=reject, take the time needed — done well, it's permanent.

Worked example: a professional-services firm with a marketing platform and a helpdesk tool

A 300-seat firm publishes p=none on a Monday. Reports start arriving from Wednesday. By the end of week two, the aggregate reports show three sending sources: Exchange Online itself (passing cleanly — Microsoft signs its own outbound mail), a marketing-email platform sending the monthly newsletter (failing SPF — its sending IP was never added to the SPF record), and a support-ticketing tool sending "your ticket was updated" notifications (failing both SPF and DKIM — it was never configured to authenticate as the firm's domain at all).

Fixing the marketing platform is a one-line SPF addition (include:spf.marketingplatform.example) and passes on the next report cycle. Fixing the helpdesk tool takes longer: the vendor needs a custom return-path domain configured before it can DKIM-sign, which means a support ticket of its own and a two-week wait for the vendor's side. Only once both third parties show clean, consistent passes across several report cycles does the firm move to p=quarantine; pct=25, watching for any drop in helpdesk-notification delivery before increasing the percentage.

The lesson that generalises: the domain's own mail (Exchange Online) is rarely the problem. The multi-week timeline comes from every third-party platform sending as the domain, and each one is a separate vendor conversation.

Decision matrix: choosing the pct increment

| Situation | Reasonable pct step | Why | | --- | --- | --- | | Small domain, few sending sources, all already passing | 50 → 100 in two steps | Little left to break; a slow crawl adds time without adding safety | | Several sending sources, one still unconfirmed | 10 → 25 → 50 → 100 | Each step is a chance to catch a source the reports didn't clearly flag | | High-volume transactional mail (invoices, notifications) riding on the domain | 5 → 10 → 25 → 50 → 100, held for a full billing cycle at each step | A quarantined invoice email that a customer never sees is a support and revenue problem, not just an inbox nuisance | | Domain used mostly for internal mail, external senders are a small fraction | 25 → 100 | Internal mail via Exchange Online authenticates cleanly by default; external risk is the only real unknown |

MSP checklist

• Confirm which tenant owns the DMARC record before touching it — sp= and subdomain records are easy to apply to the wrong customer in a multi-tenant reporting dashboard.
• Ask every client for their list of marketing, helpdesk, invoicing, and HR-system integrations before publishing p=none — the client rarely remembers all of them unprompted, and the aggregate reports will only show what actually sent mail in the reporting window, not what sends quarterly or annually.
• Use a shared DMARC analyser account scoped per client rather than reading raw XML per tenant; at MSP scale, manual report reading does not stay sustainable past a handful of domains.
• Set client expectations on timeline up front — a rollout that "should be quick" and then stalls on a slow-to-respond vendor is a common source of friction if not flagged early.