DMARC p=reject tells receiving servers to refuse mail that fails DMARC. The safe way to get there is staged: publish p=none with a rua address, read the aggregate reports, fix each legitimate sender with aligned DKIM or SPF, then move to p=quarantine and finally p=reject.
What does DMARC p=reject do?
With p=reject, a receiver is asked to reject any message that fails DMARC, meaning neither SPF nor DKIM passed with a domain aligned to the visible From address. The message is refused during delivery instead of reaching the inbox or spam folder. It is the strongest DMARC policy against spoofing.
The three policies differ only in what happens to failing mail:
- p=none: take no action. Failing mail is delivered as normal, but reports are still sent to you.
- p=quarantine: treat failing mail as suspicious, usually by routing it to spam or junk.
- p=reject: refuse failing mail outright.
This article is about the road to enforcement. If you are weighing the two enforcing policies against each other, see DMARC quarantine vs reject: what's the safer bet.
Why start at p=none with a rua address?
Because p=none changes nothing about delivery, it is safe to publish first, but only the rua tag makes it useful. The rua address receives aggregate reports showing who sends mail as your domain and whether it passes. Without it, p=none teaches you nothing.
A starting record looks like this:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
You can confirm what is currently published with the DMARC record lookup, and check SPF, DKIM and DMARC together with the domain scanner. Raw reports are compressed XML, so a tool such as DMARC monitoring helps you collect and visualise them. yourDMARC's monitoring does this for your domains.
How do you find every service sending as your domain?
Let reports accumulate for a few weeks, then list every source IP and sending service that uses your domain in the From address. Match each one to a real service and an owner. Anything you cannot identify must be investigated before you enforce, because it is either a forgotten legitimate sender or abuse.
A useful inventory covers:
- Your mailbox provider (Microsoft 365, Google Workspace or similar)
- Marketing and newsletter platforms
- CRM and sales tools
- Helpdesk and ticketing systems
- Billing and invoicing software
- Website contact forms, application servers and monitoring alerts
Wait long enough to catch senders that only mail occasionally, such as month-end invoices or annual notices. For each source record whether SPF passes, whether DKIM passes, and whether either one is aligned.
How do you fix each sender?
For each legitimate sender, make at least one of SPF or DKIM pass with a domain that aligns with your From domain. DKIM alignment is the more reliable choice, because SPF breaks when mail is forwarded while a DKIM signature normally survives.
Typical fixes:
- DKIM: in the vendor's settings, enable custom domain signing and publish the CNAME or TXT record they give you. Alignment is relaxed by default (
adkim=r), so the signature's d= domain only needs to share its organizational domain with the From domain: a signature with d=mail.example.com aligns with a From address at example.com. An exact match is required only if you setadkim=s. - SPF: add the vendor's include, for example
include:spf.vendor.example, to the SPF record of the domain the vendor uses as its Return-Path (envelope sender). SPF alignment is also relaxed by default (aspf=r), so that domain only has to share the organizational domain with your From domain. A vendor bounce subdomain such as bounce.example.com aligns with example.com, which is the usual way vendors achieve SPF alignment. If the vendor uses its own domain as the Return-Path, adding an include to your root record does not create alignment.
example.com. IN TXT "v=spf1 include:_spf.example.net include:spf.vendor.example -all"
Keep exactly one SPF record per domain. Work through senders one at a time and confirm in the next reports that each now shows aligned passes.
What breaks mail when you enforce DMARC?
Most enforcement problems come from a few known traps: forwarding, mailing lists, third-party senders that use their own envelope domain, subdomains with different needs, and SPF records that exceed the lookup limit. Check each before you tighten the policy.
- Forwarding and mailing lists: forwarding changes the sending IP, so SPF fails. Lists often also alter the subject or body, which can invalidate DKIM. Aligned DKIM on your original mail gives forwarded messages the best chance of passing. Some lists and forwarders may still cause failures you have to accept or handle case by case.
- Third-party senders using their own envelope domain: if a vendor sends with a Return-Path on its own domain, SPF passes for the vendor's domain, not yours, so it is not aligned. Either have the vendor use a bounce subdomain on your domain, if it supports one, or rely on DKIM signing with your domain.
- Subdomains: subdomains inherit the main policy unless you set sp=. Use sp= deliberately, for example to keep subdomains at a softer policy while you finish fixing them, and publish separate records where a subdomain has its own senders.
- The SPF 10-lookup limit: SPF allows at most 10 DNS lookups during evaluation. Every term that triggers a DNS query counts (include, a, mx, ptr, exists and redirect), including those nested inside other includes. Going over the limit produces an SPF permerror, and for DMARC that means SPF does not pass. Remove unused vendors and prefer DKIM for new services.
For a larger estate, DMARC for multiple domains: lessons from 87 domains covers how to run this across many domains.
How do you move from p=none to p=quarantine and p=reject?
Once reports show your legitimate sources passing with alignment, change p=none to p=quarantine, watch the reports and your helpdesk for a period, fix whatever surfaces, then change to p=reject. Do each step only when the previous one is quiet.
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"
The second line replaces the first; you only ever publish one DMARC record. You may see guidance to ramp up with the pct= tag. It is best not to rely on it: DMARCbis drops pct in favour of a t= testing flag, and receivers have applied partial percentages inconsistently. Staging by policy and fixing sender by sender is more predictable.
Rolling back fast. If legitimate mail starts failing, edit the same TXT record back to p=quarantine or p=none. Keep the TTL on the _dmarc record low during the transition so the change spreads quickly, and note that receivers may cache the old record until the TTL expires. Then use the reports to find the failing source, fix it, and re-tighten.
How do you keep p=reject working after enforcement?
Keep reading aggregate reports permanently. New senders get added over time, such as a new survey tool, a billing system or a department's own newsletter, and at p=reject any sender that is not set up correctly is rejected immediately.
Good habits:
- Make "set up DKIM for our domain" part of every new-vendor checklist.
- Review reports regularly for new unknown sources and for sudden failures from known ones.
- Re-check your records after DNS or provider changes with the domain scanner.
If you would rather not run the rollout yourself, the managed services option has the yourDMARC team run it for you.
Key takeaways
- p=none monitors, p=quarantine sends failing mail to spam, and p=reject refuses it.
- Always publish p=none with a rua address first; without reports you are guessing.
- Inventory every sender from several weeks of aggregate reports and identify unknown sources before enforcing.
- Prefer aligned DKIM for each sender, since SPF breaks on forwarding. Relaxed alignment is the default, so a shared organizational domain is enough.
- Watch for forwarding, mailing lists, vendors using their own Return-Path domain, subdomains (sp=) and the 10-lookup SPF limit, which causes a permerror.
- Move to p=quarantine, then p=reject, and keep a fast rollback ready by editing the same record.
- Keep monitoring after p=reject, because new senders will appear.
