The work between publishing p=none and moving to enforcement is almost entirely this: turning a list of IP addresses into a list of named senders, and deciding for each one whether it should be sending as you at all.
Sort by volume and alignment first
Before identifying anything, sort the sources into four groups. Which group a source is in determines how much of your attention it deserves.
| Aligned (passing) | Not aligned (failing) | |
|---|---|---|
| High volume | Your main mail platform. Working. Leave it alone. | The work. A real sender of yours that is not aligned. Fix these before enforcing, in volume order. |
| Low volume | A minor system that happens to be configured correctly. Confirm and move on. | A long tail: forwarding, forgotten systems, and spoofing. Individually small, and you still have to know which is which. |
The top-right cell is the project. Everything else is either fine or noise, and the single most common mistake at this stage is spending days on a source sending four messages a week while a platform sending forty thousand is still unaligned.
Identifying a source from an IP
Four pieces of evidence, in the order that usually resolves it fastest:
- The SPF domain in
auth_results. If SPF passed formail.sendplatform.example, that names the platform outright. This alone identifies most sources. - The DKIM
d=domain. Same idea, and it is the better signal when both are present. - Reverse DNS.
- Who owns the address range.
dig +short -x 198.51.100.25 # reverse DNS whois 198.51.100.25 | grep -i 'orgname\|netname\|descr'
Reverse DNS on a cloud provider tells you almost nothing
A source in a large cloud network resolves to the cloud provider, which narrows it to "something somebody runs". When that happens, the authentication domains in auth_results are the only useful evidence, and if those are absent too you are left asking internally.
Three categories, and what each needs
| Category | How it looks | Action |
|---|---|---|
| Yours, and aligned | Consistent volume, aligned pass, domain you recognise. | Record it in the inventory. No change. |
| Yours, not aligned | Consistent volume, auth_results passing for a vendor domain, policy_evaluated failing. | Align it — DKIM on your domain, or a custom return-path. This is the work. |
| Not yours | Scattered single-digit counts from unrelated networks, nothing passing anywhere. | Nothing to fix. This is what enforcement will stop, and it is the reason to enforce. |
Reading the long tail honestly
There is always a tail of low-volume failing sources, and it is a mixture of three things that look alike in a report:
- Forwarding. Usually the largest part. Small counts from many residential and consumer networks, often with DKIM passing and SPF failing.
- Forgotten systems. A monitoring box, an appliance, a script on someone’s server. These matter and are worth chasing.
- Actual spoofing. Nothing passes anything, sources are unrelated to each other, volume is erratic.
You do not need to resolve every entry in the tail before enforcing, and waiting until you have is the most common way a DMARC project stalls indefinitely. You need to be confident that no significant stream of legitimate mail is in it — which is a judgement about volume and pattern, not a demand for certainty about every row.
The deliverable
Keep a written inventory: sender, business owner, From domain used, how it authenticates today, what has to change, and whether it is done. This document is the actual output of the monitoring phase. The DNS changes at the end are the easy part; knowing what your organisation sends is the hard part, and nobody has it written down at the start.