DMARC Policy Progression: From None to Reject Safely

DMARC policy progression is the process of moving from observation towards an enforcement request without losing legitimate mail. The technical values are simple; the difficult part is knowing when the sending estate is understood well enough to change policy.

There is no universal calendar. Progress only when normal and periodic legitimate sending has been observed, authenticated, and confirmed. The current policy specification is RFC 9989.

Understand the three policy values

p=none

The domain owner expresses no requested handling for messages that fail DMARC. Participating receivers can still evaluate DMARC and send aggregate reports to an authorised destination.

Use monitoring to discover legitimate sources and alignment gaps. Do not describe p=none as enforcement.

p=quarantine

The domain owner asks participating receivers to treat DMARC failures with additional suspicion. A receiver may place a message outside the inbox or apply another local decision.

Quarantine is not a guaranteed holding area, and receivers can apply local policy.

p=reject

The domain owner asks participating receivers to refuse messages that fail DMARC. Receivers still control their final handling decision.

Reject is the strongest standard policy request, but it does not stop lookalike domains, display-name deception, compromised accounts, or every form of phishing and fraud.

Evidence gate 1: prepare before publishing

Confirm domain ownership and change control

Identify who owns the domain, who manages DNS, who can approve changes, and how rollback will work. Keep the existing record and TTL details with the change record.

Inventory known senders

List systems that use the domain in visible From addresses:

• primary user mail;
• invoicing and accounting systems;
• CRM, marketing, and survey platforms;
• helpdesk and ticketing tools;
• website and application mail;
• monitoring and alerting systems; and
• outsourced or vendor-managed services.

Include periodic senders. A quarterly campaign or annual statement service may not appear during a short observation window, so the inventory and observation period must account for low-frequency business mail.

Confirm the reporting destination

Choose an aggregate-report destination that is authorised, monitored, and able to process the data. Where reports go to a different domain, confirm the required external-destination verification under RFC 9990.

Evidence gate 2: establish monitoring

A basic monitoring record has this shape:

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

This is an illustration, not a record to paste into production. The destination must be approved and correctly verified for the real domain.

After publishing:

1. confirm authoritative DNS returns one valid DMARC record;
2. verify the effective policy domain, including subdomain discovery where relevant;
3. allow for DNS propagation, actual outbound mail, and receiver reporting schedules; and
4. confirm that aggregate reports are arriving and being processed.

The absence of a report does not prove there was no mail, and one reporting period does not prove the sender inventory is complete.

Evidence gate 3: classify every material source

Use aggregate reports, provider documentation, message headers, DNS, and customer knowledge to classify sources as:

• authorised and aligned;
• authorised but failing alignment;
• a known forwarding or mailing-list path;
• unknown and under investigation; or
• unauthorised or obsolete.

DMARC needs at least one aligned pass:

• SPF can pass with alignment to the visible From domain; or
• DKIM can pass with alignment to the visible From domain.

Do not approve a policy change while a material legitimate source remains unexplained or misaligned.

Evidence gate 4: remediate legitimate mail

Common remediation includes:

• consolidating multiple SPF records;
• reducing an SPF evaluation that exceeds the 10-lookup limit;
• enabling provider-managed DKIM;
• correcting a selector, CNAME, or signing-domain configuration;
• configuring a provider-specific aligned return path; and
• retiring a sender that should no longer use the domain.

Test through the real sending service. A DNS record can be syntactically correct while provider-side signing or alignment is still wrong.

Read SPF Records Explained and the DKIM setup guide before changing those mechanisms.

Evidence gate 5: decide whether quarantine is safe

Before moving from none to quarantine, confirm:

• known legitimate sources have an aligned SPF or DKIM pass;
• periodic and low-volume sources have been considered;
• unresolved failures have an owner and decision;
• the customer understands the requested handling change;
• support staff know what to check if delivery is affected; and
• the previous record is available for rollback.

After the change, wait for enough subsequent evidence to test normal mail flows. If legitimate mail is affected, correct the authentication gap or roll back while investigating.

Do not assume every failure will land in a spam folder. Receiver outcomes vary.

Evidence gate 6: decide whether reject is safe

Move towards p=reject when:

• legitimate sources remain aligned under the quarantine phase;
• no material unexplained source is being dismissed;
• forwarding and local-policy patterns are understood;
• subdomain mail use has been reviewed; and
• operational owners approve the change.

The decision should be based on evidence, not on a promised date.

Set an internal target and review point, but never let a deadline override unresolved legitimate mail. Targets organise the work; evidence controls the policy decision.

If a legitimate source remains unresolved, slow down. Document what is missing, who is responsible, and what evidence will allow the next decision.

Subdomain policy

The sp tag can express a requested policy for subdomains. Before setting it, identify subdomains that send mail and confirm how their authentication is managed.

An appropriate subdomain policy asks participating receivers to apply that policy to covered failures. It does not prove that every subdomain is unused or force every receiver to take the same action.

Current DMARC also supports advanced options such as np, t, and psd. These are not default settings for ordinary customer domains. Use them only when the ownership model and current RFC requirements justify them.

Do not rely on historic percentage rollout

Older DMARC guidance used the pct tag for percentage-based handling. Current policy work should use evidence-led policy stages and controlled domain or subdomain changes rather than assuming consistent percentage behaviour across receivers.

If a legacy record contains pct, review it against the current standard and the domain’s intended policy before changing it.

Ongoing monitoring after reject

Enforcement is not a set-and-forget state. Review:

• new or changed sending sources;
• provider migrations;
• DKIM rotation and signing changes;
• SPF lookup and DNS errors;
• unexpected alignment failures;
• forwarding and ARC/local-policy patterns; and
• subdomain use.

When a customer adds a service, authenticate and validate it before relying on it for production mail.

Common progression mistakes

• Publishing reject without discovery: legitimate senders can fail because they were never inventoried.
• Treating p=none as the final state: monitoring supplies evidence but does not request enforcement.
• Using one day of reports as a complete inventory: low-frequency sources may be missed.
• Assuming SPF pass means DMARC pass: the SPF-authenticated domain must align with the visible From domain.
• Ignoring provider-side DKIM: DNS can exist while signing remains disabled.
• Chasing a deadline: policy changes should wait for evidence.
• Ignoring receiver discretion: a published policy is a request, not a universal delivery guarantee.
• Stopping monitoring at reject: the sending estate continues to change.

What progression does not guarantee

DMARC can reduce successful delivery of messages that misuse an exact From domain when receivers participate and honour the requested policy. It does not guarantee that all such mail is rejected, that legitimate mail always reaches the inbox, or that the organisation is protected from other email threats.

Frequently asked questions

Can I move directly from none to reject?

The protocol does not require a quarantine step, but skipping it removes an evidence stage. Do so only when the legitimate sending estate is already known, aligned, tested, and approved for the stronger change.

How long should monitoring take?

Long enough to cover normal and periodic legitimate sending and resolve material failures. Simple and complex domains need different observation periods, so a universal number is misleading.

What happens to a DMARC failure at p=reject?

The domain owner asks participating receivers to refuse it. A receiver can still apply local policy, and failure-notification behaviour varies.

Should parked or non-mail domains use the same process?

They have a different sender inventory, but ownership, DNS validation, subdomain review, and rollback still matter. Confirm that the domain truly does not send mail before publishing restrictive SPF or DMARC records.

How do I know whether the next step is safe?

Review aggregate reports and source evidence. Every legitimate sender should have an aligned authentication path or an explicit, accepted exception before stronger policy.

Check the current public record with the free DMARC checker, then use Understanding DMARC Reports to evaluate the evidence behind the next decision.