Modeesp=none is the most common DMARC record on the internet, and also the most misunderstood. It tells receivers: here is what I would like you to do; for now, do nothing, just tell me what you saw.
That is useful. It is not protection. Anyone can still send as your domain with the same success they had before you published the record.
What the record asks for
A DMARC record is a policy plus two reporting addresses:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.example; fo=1
p=none— monitor only.rua— aggregate XML reports, sent daily by most large receivers.fo=1— ask for failure reports when either SPF or DKIM fails, not only when both do.
None of that stops a spoofed invoice. Only quarantine and reject do, and both are one edit away — which is exactly why people edit too early, break a forgotten payment provider, and retreat.
Read the reports before you move
Aggregate reports are compressed XML, one file per receiver per day. You do not need to read them raw. Put the rua address behind a tool or a script that produces two numbers for each sending source:
- Volume and alignment rate — how much mail, and how much of it passes DMARC.
- Domain and IP ownership — whether you recognise the sender.
Sort by volume. The top five sources are usually your ESP, your CRM, a transactional provider, a website form and something nobody remembers. Fix alignment for the first four; investigate the fifth.
Two patterns deserve special attention:
- A source that only ever fails and sends on your behalf is either broken or not yours. If it is not yours, that is the spoofing DMARC can eventually stop.
- A source that passes SPF but fails DMARC is almost always misaligned: the platform authenticates its own bounce domain. Fix DKIM, not the SPF record.
If you have no reporting address yet, start there. Enforcing without data is guessing with your customers' invoices.