How to Inventory Every System Sending as Your Domain
Find senders across DNS, headers, provider consoles, applications, and DMARC reports, then mark unknown sources for investigation.
Product & Engineering · September 25, 2026 · 2 min read
To inventory every system sending as your domain, triangulate evidence. Start with DNS, then compare real message headers, provider consoles, application configuration, and DMARC aggregate data. The output is not a list of vendors; it is a map from sender identity to owner, purpose, and control.
1. Build the domain map
List the organizational domain, every known sending subdomain, and any reply or tracking domain. Capture authoritative MX, SPF, DKIM selector, and DMARC records using the DNS records guide. Note the lookup time and nameserver. A record shows what is published, not which applications are actively sending.
2. Inspect messages and provider consoles
Collect representative headers from transactional, marketing, support, and outreach messages. Record the visible From domain, Return-Path or envelope sender, DKIM d= domain and selector, Message-ID, receiving path, and authentication results. Use the email authentication guide and authentication change-management workflow to keep authentication evidence separate from placement conclusions.
Then inspect provider consoles, SMTP credentials, API integrations, web forms, CRM automations, scheduled jobs, and infrastructure-as-code. Search for domains, selectors, relay hostnames, API key identifiers, and webhook endpoints. Ask application owners about dormant integrations; an old form or staging environment can remain authorized long after its business purpose ends.
3. Reconcile DMARC aggregate data
Aggregate reports can reveal source IPs and authentication outcomes that do not appear in a documentation inventory. Group rows by source, From domain, SPF alignment, DKIM alignment, and policy disposition. Do not treat report counts as a complete message ledger. Record source IPs or providers that have no owner and classify them as unknown pending investigation.
4. Decide what to do with unknowns
For each unknown, check deployment history, provider accounts, DNS changes, and application logs before editing records. If it is legitimate, assign an owner and document its purpose. If it is obsolete, schedule credential revocation and a controlled DNS cleanup. If it is suspicious, preserve headers and report evidence before containment. Re-run the inventory after the change and record what disappeared or remained.
Related resources
The Email Infrastructure academy is the appropriate hub for domain and sender ownership questions.
This workflow should be checked against the cited standards and current provider documentation 1.
References
Resources in this guide
[object Object]
Frequently asked questions
Can DMARC reports identify every sender?
No. They provide aggregate observations from participating receivers and can be delayed or incomplete. Combine them with DNS, headers, consoles, and application configuration.
What is the most useful header evidence?
Record From, Return-Path, DKIM d= and selector, Authentication-Results, Message-ID, and timestamps. These fields help connect a message to a sending system without exposing its body.
Should an unknown sender be removed immediately?
Preserve evidence and investigate first. Immediate deletion can break a legitimate workflow or erase clues. Use a controlled containment and rollback plan.
Continue learning
Review authentication change management
Continue with the closest operational guide.