DMARC: from p=none to p=reject in 30 days
A week-by-week plan to move a domain from DMARC monitoring to full enforcement without blocking your own invoices, newsletters or support mail.
Why enforcement needs a plan
Publishing p=reject is a single DNS change, and so is breaking your own mail. Every service that sends as your domain has to pass DMARC after the change: your mailbox provider, the newsletter tool, the invoicing system, the helpdesk, the web shop and the scanner in the office that emails PDFs. Any of them that signs with its own domain or uses its own bounce address fails alignment and gets rejected.
The DMARC reporting loop exists to find those senders before enforcement. With p=none and a working rua address, receivers send daily aggregate reports that list every IP address sending mail with your domain in the From header and whether it passed. You enforce only when the reports show nothing legitimate is left failing.
Before you start: the sender inventory
Write down every system that sends mail with your domain in the From address, and who owns it. Reports will reveal the ones you forget, but a list shortens the first week and gives you contacts when something fails. Include systems that send rarely: a year-end statement run is easy to miss in a two-week window.
| Sender type | Examples | Usual way to align |
|---|---|---|
| Mailbox provider | Microsoft 365, Google Workspace | Enable DKIM signing with your own domain in the admin console |
| Marketing and newsletters | Email service providers | Add the provider's DKIM CNAME or TXT records; optionally a custom bounce domain |
| Transactional mail | Password resets, receipts sent by your application | DKIM with your domain at the relay; custom MAIL FROM (return-path) domain |
| Business systems | CRM, helpdesk, invoicing, HR tools | Domain verification in the tool, which usually adds DKIM records |
| Devices and scripts | Scanners, monitoring alerts, cron jobs | Send through your mailbox provider's authenticated SMTP instead of directly |
Check SPF and DKIM for the domain before publishing anything. Use the Email Security to confirm the record exists, stays under the 10-lookup limit and ends with ~all or -all. Use the Domain Health check for an overview of SPF, DMARC, MX and the website in one run.
Week 1: publish p=none and collect reports
Publish a monitoring record with an aggregate report address. A dedicated mailbox or a DMARC report service works better than a personal inbox: large domains receive dozens of compressed XML files a day. If the address is on another domain, that domain must publish an authorization record, which report services do automatically.
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"Run the Email Security after the change. It confirms there is exactly one record, the policy parses, and external report addresses are authorised. Reports from the large providers usually start within a day or two, covering the previous UTC day.
Lower the TTL first
_dmarc record to a short value such as 300 seconds for the rollout. If a stage causes problems, a rollback then reaches receivers within minutes instead of hours.Week 2: read the reports and fix alignment
Group the report rows by source IP and identify who owns each address. Reverse DNS, the network name from an IP Intelligence and the volume usually make it obvious: an IP range of your ESP, your mailbox provider or your own servers. The aggregate report guide explains every field.
| Pattern in the report | Likely cause | Action |
|---|---|---|
| Your provider's IPs, DKIM pass, SPF pass, both aligned | Correctly configured sender | Nothing |
| Your ESP's IPs, SPF pass but not aligned, no aligned DKIM | ESP uses its own bounce domain and signs with its own domain | Set up DKIM with your domain in the ESP |
| Unknown IPs, DKIM pass aligned, SPF fail | Mail forwarded by a recipient's server | Nothing; DKIM keeps it passing |
| Unknown IPs, SPF and DKIM fail, small volumes | Spoofing or a forgotten system | Confirm nobody owns it; enforcement will block it |
| Your own server IPs, everything fails | Script or device sending directly | Route it through authenticated SMTP with DKIM |
Aim for DKIM alignment on every service. SPF alignment breaks whenever mail is forwarded, while a DKIM signature with d=example.com survives forwarding as long as the message is not modified. Where a service cannot sign with your domain, consider moving it to a subdomain such as news.example.com with its own SPF, DKIM and DMARC setup.
selector1._domainkey.example.com. IN CNAME selector1-example-com._domainkey.esp.example.net.Week 3: move to p=quarantine
When the last week of reports shows your known senders passing with alignment, change the policy to quarantine. Failing mail is now delivered to spam folders, which is visible to users but recoverable. Tell the people who own sending systems and the support team what changed, so a complaint about missing mail is connected to DMARC quickly.
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"RFC 7489 also defines pct to apply the policy to part of the failing mail, for example pct=25, with the rest treated one step softer. It can soften a first step on a very large domain, but the DMARCbis revision removes pct in favour of a simple testing flag. Most domains are better served by finishing the alignment work and switching fully.
Keep sp in mind
sp tag, subdomains follow p. If you publish sp=none during the rollout, remember to remove it later; Email Security warns when subdomains are weaker than the domain.Week 4: move to p=reject
After a week of quarantine without legitimate failures, publish p=reject. Receivers that honour the policy now refuse failing messages during the SMTP transaction, so senders get a bounce instead of the recipient finding the message in spam. This is the setting that stops direct spoofing of your domain.
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"Keep rua in place for good. Reports are how you notice a new marketing tool someone signed up for, a DKIM key that expired at a provider, or a spoofing campaign. Check them at least weekly, or let a report service alert you.
If something breaks
When legitimate mail starts bouncing, lower the policy one step, fix the sender and move up again. With a short TTL the change takes effect within minutes. Do not delete the record: that removes the reports you need to see what went wrong.
- Change
p=rejecttop=quarantine(orquarantinetonone). - Find the failing source in the latest aggregate report or in the bounce message.
- Enable DKIM with your domain for that service, or route it through an authenticated relay.
- Confirm the fix with a test message and the Email Header Analyzer:
dkim=passwithheader.d=example.com. - Restore the stricter policy.
Special cases
Forwarding and mailing lists
Forwarding breaks SPF because the forwarding server is not in your SPF record. Mailing lists that add footers or change the subject also break DKIM. Receivers can use ARC (RFC 8617) headers added by trusted intermediaries to accept such mail, but that is outside your control; what you control is signing all mail with DKIM.
Domains that never send mail
Parked and defensive domains can skip the stages entirely. Publish p=reject, an SPF record of v=spf1 -all and no MX record, and they cannot be used for spoofing.
example.org. IN TXT "v=spf1 -all"
_dmarc.example.org. IN TXT "v=DMARC1; p=reject;"Low-volume domains
A small business domain may send only a few messages a day, so reports take longer to show every sender. Keep p=none for at least one full billing cycle, or until every system on the inventory list has appeared in a report with a pass.
Working with third-party senders
Most alignment failures in week 2 belong to a vendor, not to your own servers. The good news is that almost every serious sending service supports custom-domain authentication; it is usually called domain verification, sender authentication or branded sending. The setting is often off by default because it needs DNS records from you.
When you contact a vendor, ask precise questions. A vague request such as "please support DMARC" tends to get a vague answer, while a request for a DKIM signature with d=example.com has a clear yes or no. Keep the answers in your sender inventory so the next person knows how each service is configured.
- Can you sign our messages with DKIM using our domain (
d=example.com), and which DNS records do you need? - Can the envelope sender (return-path, bounce address) use a subdomain of ours, such as
bounces.example.com, so SPF aligns? - Which SPF
includedo you need, and how many DNS lookups does it use? - Do you send from shared IP ranges, and do you rotate DKIM keys? How are we told about key changes?
- Can we send from a subdomain such as
news.example.comif full alignment on the main domain is not possible?
Adding a vendor's SPF include is not always necessary. If the vendor signs with your domain and uses its own bounce domain, DMARC passes through DKIM alone, and you avoid spending one of your ten SPF lookups. The SPF 10-lookup guide explains why that budget matters.
Use subdomains to isolate risk
news.example.com and receipts from billing.example.com keeps each stream's reputation and DMARC setup separate. A problem with one vendor then does not affect mail from your people at example.com.Subdomains during the rollout
Subdomains without their own _dmarc record inherit the policy of the organizational domain: the sp tag if present, otherwise p. That inheritance is useful, because attackers like to spoof names such as secure.example.com that look official but have no records at all. It also means your rollout covers every subdomain at once, including ones a team set up years ago.
Look for subdomain senders in the reports: the header_from field shows the exact From domain of each row. If a subdomain sends mail that is not ready for enforcement, give it its own record with p=none while you fix it, instead of weakening sp for every subdomain. When it is fixed, delete the subdomain record so it follows the main policy again.
_dmarc.legacy.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"The DMARCbis revision adds an np tag for subdomains that do not exist in DNS at all. Receivers that support it can reject mail from invented names such as invoice-2026.example.com even if you use a softer sp for real subdomains. Until support is widespread, keeping sp equal to p gives the same protection.
Measuring progress
A rollout is easier to steer with a few numbers from the weekly report summary. Track them per week so a regression, such as a vendor that stopped signing, stands out immediately. They also make a good status update for people who own sending systems.
| Metric | Target before enforcing | Why it matters |
|---|---|---|
| Share of mail passing DMARC | Close to 100% of mail from known senders | Remaining failures from known senders will be blocked |
| Known senders without aligned DKIM | Zero | SPF-only senders fail when mail is forwarded |
| Unknown sources with passing DMARC | Zero, or explained | A pass from an unknown IP means someone can send as you |
| Reporting receivers | Stable week to week | A drop can mean the rua address stopped working |
Do not chase a perfect 100% across all traffic. Forwarded mail and spoofing attempts will always fail, and that is expected. The number that must reach zero is legitimate mail from your own senders that fails.
Checklist
- Inventory of sending services with an owner for each.
- SPF record valid, under 10 lookups, ending in
~allor-all. - DKIM signing with your domain enabled for every service that supports it.
- One DMARC record with
ruaand a short TTL; external report addresses authorised. - At least one week of reports reviewed before each policy change.
- Support team informed before
quarantineandreject. - Weekly report review and a vendor onboarding step that includes SPF and DKIM.
FAQ
Can I go straight to p=reject?
Only for domains that send no mail, or when you are certain every sender is DKIM-signed with your domain. Otherwise you risk rejecting your own invoices or password resets without warning.
How do I know it is safe to move to the next stage?
When a full week of aggregate reports (longer for low-volume domains) shows every IP you recognise passing DMARC, and the remaining failures are forwarding or unknown sources you have confirmed nobody owns.
Is SPF alignment enough if DKIM is hard to set up?
It is enough for DMARC to pass on direct delivery, but SPF fails when a recipient forwards the message. DKIM with your domain is what keeps forwarded mail passing, so treat SPF-only senders as a risk to fix.
Will p=reject affect mail I receive?
No. Your DMARC record controls how other receivers treat mail that claims to come from your domain. How your own mail server treats incoming mail is configured separately.
Do I need a paid DMARC report service?
Not necessarily. Small domains can read the XML reports directly or with a short script. Services help when volumes are large or when you want alerts and history.
What should the rua mailbox be?
A dedicated address such as dmarc-reports@example.com that is not someone's personal inbox, or a report service address. Reports are frequent, compressed and machine-readable.