A supplier list misses the route that can fail
Knowing that you use a mailbox provider, campaign tool and shop platform is not yet a sender inventory. One supplier can send receipts, reminders and marketing through different domains, accounts and authentication settings. One business process can also hand a message through several systems before it reaches the internet.
The inventory unit should be the route: a repeatable path that creates a message, chooses the visible From identity, applies an envelope domain and signatures, then connects to a receiver. This reframe makes a failure assignable. It also prevents an administrator from replacing a shared DNS record to fix one supplier while breaking another.
The NCSC advises organisations to protect all their domains and treats SPF, DKIM and DMARC as connected controls. The NCSC email security guidance provides that implementation context. A route inventory is the bridge between those domain controls and the applications your organisation actually runs.
Two suppliers listed on the same invoice can still send from different domains, IPs or return paths, and one supplier can send several distinct streams that behave differently. The inventory row that matters is the route a message actually travelled, so a supplier name alone is not enough. Recording the visible From domain, envelope domain, DKIM signer and sending platform together is what makes a row actionable when a specific address stops working.
For a smaller first review built around the same route evidence, use the verifiable small-business email checklist to identify missing owners and records.
Start with business processes rather than DNS records
Ask finance, sales, support, operations, HR and website owners what sends mail using the organisation’s name or domains. Include staff mail, shared mailboxes, CRM workflows, newsletters, invoices, payslips, bookings, password resets, monitoring alerts, scanners, ticketing, forms and outsourced agencies.
Review contracts, application settings, DNS change history and mailbox traces. Search for From-address settings in active services. Compare that list with DMARC aggregate sources, but do not treat reports as complete because receivers may not report and infrequent routes may not appear.
Record discontinued services too until you have evidence that sending stopped and credentials or DNS delegations were removed. “We no longer pay for it” is not proof that an old API key, scheduled campaign or selector is inactive.
Copy the sender inventory template
Copy this blank template into a restricted spreadsheet or asset register. Complete one copy for each repeatable message route, then add optional fields for selectors, SPF, DKIM and DMARC results, test receivers, evidence references, approved change windows and rollback records when they are needed.
| Field | Value for this route |
|---|---|
| Route ID | |
| Business purpose | |
| Application | |
| Visible From domain | |
| MAIL FROM domain | |
| DKIM signing domain | |
| Business owner | |
| Technical owner | |
| Last verified | |
| Status |
Use roles or team contacts in a broadly shared view, not passwords or personal recovery details. Put sensitive account identifiers and escalation contacts in an access-controlled companion record. Never store DKIM private keys, API secrets or mailbox credentials in the inventory.
Give every route a stable ID. Reuse it in tickets and test notes so evidence survives supplier name changes. Mark a value “not observed” or “owner confirming” instead of guessing.
To populate each row from receiver evidence, learn to read DMARC aggregate reports as route evidence.
Capture a message from the real workflow
- Trigger an authorised test. Submit the real form, create a test invoice or use the application function that production users rely on.
- Receive it in a controlled mailbox. Record the receiver and UTC time.
- Open original-message evidence. Copy From, Return-Path or trusted MAIL FROM evidence, DKIM
d=ands=, plus SPF, DKIM and DMARC results. - Link, do not scatter. Store the redacted evidence securely and put only its restricted reference in the inventory.
- Compare with the intended design. Record which aligned mechanism is expected to carry DMARC.
RFC 9989 makes the Author Domain, SPF domain and DKIM signing domain distinct objects. The current DMARC specification defines these identities. Your columns should preserve that distinction.
Classify each route by readiness and evidence
- Verified: an accountable owner exists, the route was tested recently and the intended aligned authentication path passed.
- Repair: the route is legitimate, but authentication is absent, failing or unaligned.
- Investigate: evidence exists but the application or owner is not confirmed.
- Retire: the owner confirms the route should stop, with a shutdown and verification plan.
- Exception: a documented business decision accepts a known limitation for a defined period and review date.
Status is not a judgement on the supplier. It describes your evidence for this route. A reputable provider can be misconfigured in one account, and an unfamiliar infrastructure address can belong to a legitimate shared service.
Do not increase DMARC enforcement while a critical authorised route remains in repair or investigate without an accepted plan.
subdomains versus separate domainsConnect DNS authority to each row
Record the DNS zone and owner responsible for every envelope subdomain and DKIM selector. A route may require a TXT record in one zone, a CNAME delegation in another and an account switch before signing starts. The person who can edit DNS may not control the sending account.
Preserve current record names, values, TTLs and purpose before any edit. For SPF, identify the single policy at the exact owner name and map each include or address range to an active route where possible. For DKIM, map selectors to services and rotation dates. For DMARC, record policy, reporting destinations and inheritance.
Unknown records are research items, not deletion candidates. Removing an old-looking include or selector without traffic and ownership evidence can turn a clean-up exercise into an outage.
what DMARC alignment is and why it mattersUpdate the inventory when ownership changes
Trigger review when a supplier is added or removed, a domain is acquired, an application changes its From address, a website is rebuilt, mail is rerouted, a DKIM key rotates or a staff owner leaves. Calendar review catches drift, but change events catch it earlier.
For retirement, disable sending, run a same-route check, watch expected reporting periods, revoke credentials and remove authentication only after evidence shows the route is no longer needed. Keep the rollback and approval record long enough to explain later report rows.
A useful inventory is not the largest sheet. It is the smallest controlled record that lets another administrator identify the route, owner, identities, last evidence and safe action without guessing.
Make updates a triggered event rather than a yearly tidy-up. When a supplier is added or removed, a domain is renewed or transferred, or an owner's contract changes, the affected rows should be updated the same week. A register that is accurate at audit time but months out of date otherwise can authorise a wrong DNS change with more confidence than no register at all.
Design the register so it can be shared safely
The main register should help owners work without becoming a secret store. Keep route ID, business purpose, team contacts, From and authenticated domains, selectors, results, status, review date and references there. Put personal escalation details, account identifiers and original headers in a separate access-controlled record. Passwords, API keys, DKIM private keys and recovery codes belong only in the organisation’s approved credential system.
A test header linked from a route row can expose recipients, subjects, internal hosts and message IDs. The mail administrator should keep the original; the inventory needs a redacted copy containing the identities and verdicts required to reproduce the classification. If a supplier is asked about its route, send only its own account reference, observed domains, timestamp and relevant extract through authenticated support.
Name the register owner, readers and retention rules. Former suppliers and retired routes may need enough historical evidence to explain later report rows, but that does not justify keeping personal message content indefinitely. If an inventory review cannot proceed without wider access to staff or customer mail, ask the data owner to approve a narrower collection method.
Audit the register by choosing real rows at random
Choose a critical row and ask its owner to perform the recorded business action. The received message should reproduce the row’s From domain, MAIL FROM domain, signing domain, selector and authentication outcome. Compare the UTC test time and evidence reference with the register. If the supplier name is right but the observed route differs, the row is stale and should not remain “verified”.
Test one route from each important class, such as staff mail, billing and an application, after a shared DNS change. For a retirement row, confirm the service no longer sends, its credentials are revoked and its DNS authority can be removed without affecting another row. For an unknown source, retain the investigate status until a contract, log or controlled message establishes ownership.
Save the received results and update the last-tested date without overwriting earlier evidence. A register is useful when another administrator can follow the reference and reach the same classification. DNS lookup success alone does not demonstrate that an application used the recorded identity.
Do not let an incomplete register authorise a broad change
Stop when a critical row has no business owner, the technical owner cannot reproduce the route, or an unknown DNS record is about to be removed because it looks old. The same caution applies when one supplier name hides several message types. Split the rows and observe them before changing shared SPF, DKIM or DMARC settings.
Send ownership gaps to the relevant department and DNS questions to the zone administrator. Include route IDs, last evidence, current records and the business event that needs testing. If an edit breaks a verified row, use its rollback reference and pause only that sender while the owners compare evidence.
No inventory entry should grant authority on a guess. Keep a route in investigate or repair status until the domains, owner and test agree. Record who must decide and by when, then leave unrelated working records in place.
Sources and further reading
- RFC 9989: Domain-based message authentication, reporting and conformance
- NCSC email security and anti-spoofing guidance