From DMARC p=none to p=reject: How to Read DMARC Reports, Find Every Service That Sends as You, and Enforce Without Losing Email
Move DMARC from p=none to p=reject safely: read aggregate reports, find every service sending as your domain, fix alignment and enforce in stages.
Rupak NepaliPublished Nov 13, 2026When Gmail and Yahoo started requiring DMARC for bulk senders in 2024, and Microsoft followed for Outlook.com in 2025, millions of domains published the minimum: a record with p=none. That satisfies the rule, but it doesn’t protect anything. p=none tells receiving servers “if a message claiming to be from us fails authentication, deliver it anyway.” Anyone can still send phishing emails from your domain to your customers.
The reason most teams stay at p=none is fear: “If we turn on enforcement, will our order confirmations or newsletters disappear?” DMARC reports answer that question. This post shows how to read them, how to fix each sending service, and how to move to p=reject in steps.
If you haven’t set up SPF, DKIM and DMARC at all yet, start with our email deliverability guide and the Gmail, Yahoo and Microsoft sender requirements, then come back.
A 60-second DMARC refresher
When your email arrives at Gmail, three checks run:
- SPF: is the sending server allowed to send for the domain in the hidden envelope sender (the Return-Path)?
- DKIM: does the message carry a valid signature, and for which domain (the
d=value)? - DMARC: did SPF or DKIM pass for the same domain the customer sees in the From address? That match is called alignment.
That last point is where most failures come from. An email from orders@mystore.com sent through an email platform might pass SPF for bounces.emailplatform.com and carry a DKIM signature for emailplatform.com. Both checks pass, but neither is for mystore.com, so DMARC fails. With p=none nobody notices. With p=reject the email is refused.
By default alignment is relaxed: a subdomain counts, so a DKIM signature for mail.mystore.com aligns with From: orders@mystore.com.
Step 1: make sure you’re getting reports
Look up your current record (replace the domain):
dig +short TXT _dmarc.mystore.comYou want something like:
"v=DMARC1; p=none; rua=mailto:dmarc-reports@mystore.com"The rua tag is the address that receives aggregate reports. Without it, you’re flying blind. If it’s missing, add it. If you send reports to an address at another domain (a report service), that service publishes a small DNS record authorising it; their setup instructions cover it.
Don’t use your personal inbox. Large receivers send one report per day each, as zipped XML files, and they pile up.
Step 2: understand what’s in a report
Each report comes from one receiver (Google, Microsoft, Yahoo and others) for one day. Inside, one record per sending IP address:
<record>
<row>
<source_ip>203.0.113.25</source_ip>
<count>412</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>mystore.com</header_from>
</identifiers>
<auth_results>
<spf>
<domain>server1.cheaphost.net</domain>
<result>pass</result>
</spf>
</auth_results>
</record>Reading it: 412 emails claiming to be from mystore.com came from 203.0.113.25. SPF passed, but for server1.cheaphost.net, so it isn’t aligned. There’s no DKIM signature. DMARC failed (<dkim>fail</dkim> and <spf>fail</spf> under policy_evaluated are the aligned results). Because the policy is none, they were delivered (disposition: none).
This one is a classic: it’s the web server sending OpenCart’s order emails with PHP mail(). Legitimate, and it would be rejected under enforcement.
Reports contain no message content and no recipient addresses, only IPs, counts and results, so they’re safe to share with a report service.
Step 3: use a tool to read them
Reading raw XML for every receiver every day isn’t realistic. Free options:
- Cloudflare DMARC Management: free if your DNS is on Cloudflare. It sets up the
ruaaddress for you and shows senders by source, with pass rates. - Postmark DMARC Digests: a free weekly summary email per domain.
- Free tiers of dmarcian, EasyDMARC and Valimail Monitor, with more detail and paid plans for larger volumes.
Let reports collect for two to four weeks before drawing conclusions. Some services (monthly invoices, quarterly statements) only send occasionally.
Step 4: sort every sender into one of three groups
Group the sources by the organisation behind each IP (the tools do this using reverse DNS). For each, decide:
- Ours, passing. Aligned SPF or DKIM passes. Nothing to do.
- Ours, failing. A real service that sends as your domain but isn’t set up correctly. Fix it (Step 5).
- Not ours. Unknown servers, often in countries you don’t operate in, with low volumes, failing everything. That’s spoofing, which is exactly what enforcement will stop. Also in this group: forwarding. When a customer’s university address forwards to Gmail, SPF breaks; DKIM usually survives, so senders that sign with DKIM keep passing.
For an online store, group 2 typically includes several of these:
| Sender | Typical problem | Fix |
|---|---|---|
| Store server (OpenCart order confirmations, password resets) | PHP mail() from the host’s server, no DKIM, SPF for the host’s domain | Switch OpenCart to SMTP through a provider that signs with your domain (System > Settings > Mail > Mail Engine: SMTP). Our Gmail SMTP guide covers one option; a transactional service like Postmark, Amazon SES or Mailgun with your domain verified is better for volume. |
| Google Workspace or Microsoft 365 | DKIM never switched on | Generate the DKIM key in the admin console, publish it in DNS, then turn signing on |
| Email marketing (Klaviyo, Mailchimp, Brevo) | Sending on the platform’s shared domain | Set up a branded sending domain (for example send.mystore.com) in the platform; it publishes DKIM and Return-Path records for you to add. See our Klaviyo integration post. |
| Helpdesk (Zendesk, Gorgias, Freshdesk) | Replies to customers sent from the vendor’s servers | Follow the vendor’s “authenticate your domain” or “DKIM” setup |
| Invoicing and accounting (Xero, QuickBooks, Stripe receipts) | Sends “from” your address | Authenticate your domain in the tool, or let it send from its own domain with your address as Reply-To |
| Shipping and reviews (ShipStation, review apps) | Same as above | Same as above |
Prefer DKIM to SPF for each fix. DKIM survives forwarding and isn’t affected by SPF’s limit of 10 DNS lookups, which stores with many services hit quickly. Our DNS records explainer shows what each record looks like.
Keep a simple list as you go: service, owner on your team, DKIM aligned yes/no. It becomes your record of who’s allowed to send as your domain, and the place to add the next tool someone signs up for.
Step 5: move to enforcement in stages
Once the reports show your real senders at or near 100% aligned for two weeks:
| Week | Record | What happens |
|---|---|---|
| 0 | p=none | Collect and fix (Steps 1 to 4) |
| 1–2 | p=quarantine; pct=25 | A quarter of failing messages go to spam. Watch reports and support tickets |
| 3–4 | p=quarantine; pct=100 | All failing messages go to spam |
| 5–6 | p=reject | Failing messages are refused |
For example:
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@mystore.comA few details:
pctapplies the policy to a percentage of failing mail. Most large receivers honour it, but the revised DMARC specification replaces it with a simpler test flag, so treat it as a short ramp, not a long-term setting.- Subdomains. Without an
sp=tag, subdomains inherit your policy. If you have subdomains that never send email,sp=rejectprotects them too. Domains you own that never send email at all (old brand names, typo domains) should havev=DMARC1; p=reject;plus an SPF record ofv=spf1 -allstraight away; there’s nothing to break. - Keep the reports on. New tools get added, a vendor changes servers, a DKIM key gets rotated wrongly. Your report service should alert you when a legitimate source starts failing.
If something legitimate breaks after a step, go back one step, fix the sender, and continue. The DNS change takes effect within your record’s TTL.
What you get at p=reject
- Spoofing stops at every receiver that enforces DMARC, which includes Gmail, Yahoo and Outlook.com. Phishing emails pretending to be your store’s order notifications are refused instead of reaching your customers.
- Better deliverability. Mailbox providers trust domains with enforced policies more, and your own mail is properly authenticated end to end.
- BIMI. Showing your logo next to your emails in Gmail, Yahoo and Apple Mail requires DMARC at
p=quarantineorp=reject(at 100%), plus a BIMI record and, for Gmail and Apple, a mark certificate (a Verified Mark Certificate, or a Common Mark Certificate where supported).
Summary
- Make sure
ruareports arrive, through a tool rather than your inbox. - Collect two to four weeks of data.
- List every service that sends as your domain; fix each one, preferably with aligned DKIM.
- Move through quarantine to reject over about six weeks.
- Keep watching the reports, and add every new sending tool to your list before it goes live.
It’s a few hours of work spread over a month and a half, and it closes one of the easiest ways to defraud your customers.
Author of four Opencart book.
The recent are Opencart 4 developer book and Opencart 4 user manual
