Rolling Out DMARC Safely: From p=none to p=reject

Every DMARC rollout carries the same tension. The protection only exists at enforcement, and enforcement is exactly where a mistake blocks legitimate email: the monthly statements, the booking confirmations, the invoices from an accounting system nobody remembered. This guide sets out the sequence that resolves that tension, the tags that matter along the way, and the domains most rollouts forget.

The principle: evidence before enforcement

A domain should move to a stricter policy only when the DMARC report data shows that every legitimate source is passing with alignment. Not when a date arrives, not when someone feels confident, and not because a checklist asks for it. The reports are the evidence; the policy change is the decision based on it. Everything in a safe rollout follows from that.

Phase 1: Monitor with reporting

Publish a monitoring policy with an aggregate reporting address:

_dmarc.yourcompany.co.za  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@reports.example"

This changes nothing about delivery. What it does is start the flow of aggregate reports from receiving mail servers, each listing the IP addresses that sent mail as your domain, their volumes and their SPF, DKIM and DMARC results.

Run monitoring long enough to capture your real email patterns. A week catches daily mail. It will miss the monthly statement run, the quarterly newsletter, the annual renewal notices and the system that only emails when something goes wrong. The length of this phase depends on your business, and it should be decided by what the data shows rather than a fixed rule.

Phase 2: Build the sender inventory

Group every source in the reports into three buckets.

Expect some ambiguity. Forwarded mail shows up as failures from servers you do not recognise, often carrying intact DKIM signatures from your own platforms. Recognising forwarding patterns stops you wasting time chasing them or mistaking them for attacks.

Phase 3: Align every legitimate sender

For each legitimate service that is failing, set up authentication that aligns with your domain.

• DKIM first. Enable custom domain signing so the d= value is your domain. This is the most robust route and survives forwarding. See our DKIM guide.
• SPF where possible. Add the service to your SPF record, or set a custom return-path on your own subdomain so SPF aligns. Watch the ten lookup limit covered in our SPF guide.
• Move or retire what cannot be fixed. A service that cannot authenticate as your domain may need to send from a subdomain with its own policy, or be replaced.

Then keep monitoring until the reports confirm the fixes worked across the full cycle of your email.

Phase 4: Quarantine

When legitimate mail is consistently passing, move to quarantine:

"v=DMARC1; p=quarantine; rua=mailto:dmarc@reports.example"

Failing mail now goes to spam rather than the inbox. If something legitimate was missed, it is still recoverable from spam folders, which is why quarantine is a valuable intermediate step. Watch the reports and listen for complaints of missing email. Anything that surfaces gets fixed before the next step.

Phase 5: Reject

Once quarantine has held cleanly, move to reject:

"v=DMARC1; p=reject; rua=mailto:dmarc@reports.example"

Forged mail is now refused during delivery. This is the state that stops criminals using your domain for invoice fraud and impersonation. It is also the state to maintain: new services must be aligned before they start sending, or they will be rejected too.

The tags that matter

Subdomains and parked domains

Two groups of domains are routinely left out of rollouts, and attackers know it.

Subdomains

Subdomains without their own record inherit the organisational domain’s policy through sp=, or p= if no sp= is set. Make sure an enforced policy on the main domain is not undermined by an sp=none left over from early testing.

Parked and unused domains

Many businesses own domains that never send email: old brand names, alternate extensions, defensive registrations. They are ideal for impersonation because nobody monitors them. Lock them down completely:

parkeddomain.co.za          TXT  "v=spf1 -all"
_dmarc.parkeddomain.co.za   TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@reports.example"
parkeddomain.co.za          MX   0 .

The SPF record authorises nothing, the DMARC policy rejects everything, and the null MX record declares that the domain accepts no email. Because there is no legitimate mail to protect, these domains can go straight to reject.

Frequently asked questions

MailMarq
MailMarq is a managed DMARC service run from Johannesburg. Our team has built and managed business websites, hosting and email infrastructure for South African companies since 2016, and writes these guides from work on real domains.