What this analysis does
This inventory is evidence-based: it shows what public configuration authorizes or points toward, while clearly separating DNS evidence from proof of current sending activity.
Before a domain can move DMARC to enforcement, someone has to be able to answer a simple question completely: which services are allowed to send as this domain, and who owns each one. That inventory is rarely written down, and it is the prerequisite that most enforcement projects skip.
Build the list from published evidence
The inventory starts from what DNS already authorizes. Every SPF include and every address mechanism represents a service permitted to send. Discoverable DKIM selectors add services that sign mail, which frequently include platforms absent from SPF because they rely on the DKIM path alone.
The two lists rarely match, and the mismatches are the interesting part. A platform in SPF with no signing evidence has only the fragile alignment path. A platform that signs but is not in SPF is invisible to any audit that reads SPF alone.
- SPF includes and address mechanisms enumerate authorized senders.
- DKIM selectors reveal signing services that SPF may not list.
- Divergence between the two lists is where risk concentrates.
Every entry needs a named owner
Authorization without ownership is the durable risk. Each entry should have a team accountable for it, a business purpose, and a known account with current credentials and multi-factor authentication. Entries that cannot be attributed are the ones to investigate first.
Dormant authorizations are worse than unused ones. An SPF include pointing at a platform where the account has lapsed still authorizes that platform’s infrastructure to send as your domain, and account recovery on an abandoned tenant is a well-established attack path.
Close the gap with aggregate reporting
DNS shows what is permitted; DMARC aggregate reports show what actually sent. Reconciling the two identifies both authorized services that never send, which can be removed, and sending sources that are not in the inventory at all, which need attribution before enforcement.
Collect reports across a period long enough to capture infrequent senders. Quarterly billing systems, annual notices and seasonal campaigns are exactly the services that get missed in a short observation window and break loudly when policy moves to reject.
Reconcile against aggregate reportsMeasure the lookup cost of each authorization
Example: a signing platform missing from SPF
Evidence supplied
A domain with four SPF includes and a discoverable DKIM selector belonging to a fifth platform.
How to read the result
The inventory lists five services rather than four and marks the fifth as authenticating through DKIM only. That entry would be invisible to an audit that reads SPF alone, and its alignment depends entirely on the signing path.
Known limits
- DKIM selector discovery is heuristic; services using unguessable selectors may not appear.
- Public DNS shows authorization, not actual sending activity.
- Internal relays that never traverse public infrastructure are outside the inventory.
Common questions
Why does the inventory include services we do not use?
Because DNS still authorizes them. Removing the authorization is the corrective action, and it also recovers SPF lookup budget.
How complete does this need to be before enforcement?
Complete enough that every sending source appearing in aggregate reports is attributed and has at least one aligned authentication path.
Does removing an include break anything?
Only if the platform still sends. Confirm against aggregate reporting before removal, and remove one entry at a time.