DMARC reports: moving safely from p=none to p=reject

You have published a DMARC record starting v=DMARC1; p=none;, and reports are starting to arrive. Now what? This guide is for owners and for whoever looks after their email and DNS. It shows you how to read those reports, find every service that sends mail as you, fix the ones that fail, and tighten the policy in careful steps.

If you have not set up SPF, DKIM and DMARC yet, start with SPF, DKIM and DMARC explained and come back.

In short: p=none only monitors. p=quarantine asks receivers to treat failing mail as suspicious, and p=reject asks them to refuse it. Move up only after every real sender (invoices, bookings, newsletters, contact forms) has passed DMARC with an aligned domain in real test sends. Receivers make the final call, so enforcement reduces spoofing but cannot promise to stop it.

What an aggregate report contains

Participating receivers send an XML file, often compressed, to the address in your record's rua= tag. Each file covers one reporting period from one receiver. Timing and coverage vary, and not every receiver sends reports.

For each sending IP address, a report shows:

• how many messages claimed to be from your domain
• whether SPF passed, and for which domain
• whether DKIM passed, and for which domain (d=) and selector
• whether either result aligned with the visible From address
• the disposition the receiver applied, which can differ from your policy if the receiver used a local override

Raw XML is hard to read, so most people use a report viewer. Reports include sender IPs and some address details, so choose a viewer you trust and read its terms first. Make sure the mailbox in rua= exists and can accept attachments. If it sits on a different domain, that domain may need to authorise receiving your reports, so check your viewer's instructions.

Tip: Before you change any DMARC record, copy the current TXT value at _dmarc.yourbusiness.com. If something breaks, you can paste it straight back.

Alignment: where most failures come from

A message passes DMARC when SPF or DKIM passes and the passing domain is aligned with the From address. One aligned mechanism is enough.

• SPF alignment compares the domain in the envelope sender (the Return-Path on delivered mail) with your From domain.
• DKIM alignment compares the d= domain in a valid signature with your From domain.

Under relaxed alignment, the default in the DMARC specification, the domains only need to share the same organisational domain. Under strict alignment they must match exactly.

This explains a common puzzle: a newsletter tool shows "SPF: pass", yet DMARC fails. SPF passed for the tool's own bounce domain, not yours. The fix is to authenticate your domain in the tool, so it signs with DKIM as you or uses a custom return path on your domain.

Reading your first report

Here is one row from an aggregate report, simplified and using a fictional documentation IP address. Real files hold more fields.

source_ip:    203.0.113.5
count:        42
disposition:  none
dkim:         pass   (d=yourbusiness.com, aligned)
spf:          pass   (domain=bounces.newsletter-tool.example, not aligned)
header_from:  yourbusiness.com

This newsletter passes DMARC through aligned DKIM, even though SPF passed for the wrong domain. The disposition is none because the policy is monitoring only.

Senders you recognise

Group the IPs by the service behind them. Viewer labels are a hint, not proof, so check them against the tools your business actually uses. Then build a list like this (illustrative rows only):

The booking system is your to-do item. Once you enforce, its mail is at risk of landing in spam or being refused.

Senders that look wrong

Investigate unfamiliar services before dismissing them, because shared provider IPs can mislead. Common explanations are an old marketing tool someone forgot, a website plugin sending through a third party, a former employee's forwarding rule, or real spoofing such as fake invoices in your name. These patterns help you decide which:

• A steady volume with no aligned result usually means a real system, such as a billing tool or website form. Find its domain authentication setting.
• An unknown IP that appears every week. Look up who owns the address range with a public WHOIS lookup, then ask staff which tool uses that provider. If nobody does, and the mail fails both checks, treat it as suspicious.
• A few messages from unrelated locations, failing everything, is the typical shape of spoofing. It needs no fix on your side, and it is what enforcement is designed to reduce at receivers that apply DMARC.

Forwarders and mailing lists

Forwarding often breaks SPF, because the forwarding server is not in your SPF record. DKIM usually survives forwarding, which is why aligned DKIM on every real sender matters. Mailing lists that edit subjects or footers can break DKIM too.

Build a full sender inventory

A report covers one period, so it misses senders that did not happen to send that week. Before enforcing, list every system that could send as you:

• staff mailboxes
• website contact forms and shop receipts
• booking, support and CRM tools
• accounting, invoicing and payroll
• newsletter and marketing platforms
• scanners and monitoring alerts
• seasonal or occasional campaigns

Send a real test from each one to a mailbox you control. Open the message source and read the Authentication-Results header. You want dmarc=pass, with the passing SPF or DKIM domain matching your own.

Fixing a failing sender

The steps are similar in most services:

1. Find the domain or sender authentication settings. "Domain authentication" and "DKIM" are common names.
2. Add your domain. The service gives you DNS records, usually a DKIM TXT or CNAME such as selector._domainkey.yourbusiness.com. Some also give a custom return-path CNAME.
3. Publish those records at your DNS host, then click the service's verify button.
4. Send tests to mailboxes at a few providers and read the headers as above.

Watch out: A green tick in a dashboard usually only means the DNS records were found. The received headers show whether mail is actually signed correctly.

Mind your SPF lookup limit

Each service tends to add an include: to your SPF record. SPF allows at most 10 DNS-querying mechanisms per check, counting nested includes (RFC 7208, section 4.6.4). Go over and SPF returns permerror, so the SPF side of DMARC fails. If you are near the limit, rely on aligned DKIM for bulk senders and keep SPF for servers that send from your own domain.

Moving to quarantine, then reject

Tighten when your checks pass, not after a fixed number of days.

Step 1: quarantine. Change only the policy:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourbusiness.com

Watch the reports and your own spam folders for several cycles. DNS caching means changes take time to spread.

Step 2: reject. Once quarantine has run without surprises:

v=DMARC1; p=reject; rua=mailto:dmarc@yourbusiness.com

Receivers that honour reject typically refuse failing mail at delivery, though they keep some local discretion. After that, authenticate any new sending service before it sends real mail, keep the reporting address monitored, and review reports more closely when staff tools, DNS or email providers change.

Subdomains

A subdomain that publishes its own _dmarc record follows that record. Otherwise it follows sp= if you have set one. If sp= is absent, your p= policy applies to subdomains too, so p=reject covers them by default. Check subdomains before Step 2. Look for any that send mail, such as a help desk, status page, marketing platform or an old shop, and authenticate those first.

What DMARC does not do

Enforcement reduces use of your exact domain in the From address at receivers that apply DMARC. It does not stop:

• lookalike domains such as y0urbusiness.com
• display-name tricks that use a different From address
• phishing from a compromised account on a service you authorised

Reports also cover only receivers that send them, are summaries per period, and cannot show where an individual message landed.

While you are tidying email, you can look at your website too. The free Safe Scan at pentest.lordevo.com checks a URL without attacking it. It is a website check, not a DMARC test. For website-side basics, see security headers every small business website needs.

Key takeaways

• Start at p=none with a working rua= mailbox and read several reports.
• Look at aligned results, not just pass or fail.
• Inventory every sender, then test each with a real send and read Authentication-Results.
• Rely on aligned DKIM for bulk senders, and check subdomains before reject.
• Move to quarantine, then reject, only when your checks pass. Save your old record first.
• Keep monitoring after reject, and authenticate new services before they send.

FAQ

How long should I stay at p=none?

There is no fixed time. Stay until your sender inventory is complete and several reporting cycles show only authenticated or clearly illegitimate mail.

Can I skip quarantine and go straight to reject?

You can, but quarantine is a softer warning if you missed a sender, so it is safer for most small businesses.

Will reject stop all fake emails from my domain?

No. It helps against exact-domain spoofing at receivers that apply DMARC. Lookalike domains and compromised accounts are outside its reach.