DMARC enforcement stalls, and SPF records fill with includes nobody can explain, because no one keeps a list of every service allowed to send mail as the organisation's domains, who owns it and how it authenticates. This template is that list: one row per sending source, with its SPF include or IP ranges, its return-path domain, its DKIM selectors and key details, its alignment result, its business and technical owners, and the date it is due for review or removal. It complements the Email Authentication Checklist, which checks each domain's records; this register tracks the senders behind those records so that every include and every selector can be traced to a contract and a person. It is written for email administrators, DNS owners, marketing operations and the security team that signs off a move to DMARC p=reject. For how SPF, DKIM and DMARC work, read the DMARC, SPF and DKIM Guide.
How to use this template
- Keep the register in a shared spreadsheet or your configuration management database, one row per sending source per domain. A marketing platform that sends for two domains is two rows.
- Replace text in square brackets, such as [domain], [service] and [owner], with your own details. Columns marked Evidence hold something checkable: the DNS record as published, a header from a test message, or the aggregate report line.
- Build the first version from two directions: ask procurement, marketing, finance, HR and IT which services send mail, and read DMARC aggregate reports for two to four weeks at p=none to find the senders nobody declared.
- Any SPF include, IP range or DKIM selector found in DNS without a row in this register is an orphan. Find its owner or remove it.
- Review dates, rotation periods and thresholds in this template are NHI Mgmt Group suggestions. Set your own in section 5.
1. Domain summary
| Domain | Role | DNS host and change route | DMARC policy (p, sp, np) | Number of sending sources | Register owner |
|---|---|---|---|---|---|
| [example.com] | [corporate mail] | [DNS provider], [change ticket queue] | [p=quarantine; sp=reject; np=reject] | [7] | [email administrator] |
| [news.example.com] | [marketing] | [ ] | [ ] | [ ] | [ ] |
| [example.co.uk] | [non-sending, defensive] | [ ] | [p=reject; SPF v=spf1 -all] | [0] | [ ] |
Delegating each third-party service to its own subdomain (for example news.example.com for marketing) keeps its SPF include and DKIM keys out of the main domain's records and limits what a compromised sender account can spoof.
2. Sending source register
| Field | What to record | Example |
|---|---|---|
| Source ID | Stable reference used in tickets and DNS comments | [ES-004] |
| Service and purpose | Product name and what it sends | [Marketing platform: newsletters and promotions] |
| From domain (RFC5322.From) | The domain recipients see | [news.example.com] |
| Message type and volume | Transactional, marketing, internal, alerts; messages a day | [marketing; 40,000 a day] |
| Business owner | Person who pays for and needs the service | [Head of CRM] |
| Technical owner | Person who administers its sending settings | [Marketing operations lead] |
| Contract or ticket | Purchase order, contract end date, or approval ticket | [PO-1234, ends 31/03/2027] |
| SPF mechanism | The include, ip4 or ip6 term this source needs, exactly as the provider documents it | [include:[provider SPF domain]] |
| SPF lookups used | DNS-querying terms this include adds, counted through nested includes | [2] |
| Return-path (RFC5321.MailFrom) domain | The bounce domain the service uses; must be your domain or a subdomain for SPF to align | [bounce.news.example.com] |
| DKIM d= domain | The signing domain in the DKIM-Signature header; must share the organisational domain with the From domain for relaxed alignment | [news.example.com] |
| DKIM selector(s) | Every selector the service uses, active and retired | [s1-202611], [s2-202605 retired] |
| DKIM record type | TXT with the public key, or CNAME to a provider-hosted key | [CNAME to provider] |
| Key algorithm and length | RSA bit length or Ed25519 | [RSA 2048] |
| Key created, last rotated, next rotation | Dates, and who rotates (you or the provider) | [01/11/2026], [provider-managed] |
| DMARC result | SPF aligned, DKIM aligned, from a test header or aggregate report | [SPF aligned pass; DKIM aligned pass] |
| Sending credentials | API keys, SMTP credentials or OAuth apps used to send, where they are stored, and their owner | [API key in [vault path], owner Marketing ops] |
| Admin access | Who can change sending domains or create keys in the service, and whether MFA or SSO is enforced | [3 admins, SSO enforced] |
| Status and review date | Active, onboarding, decommissioning, removed; next review | [Active; review 05/2027] |
| Evidence | Link to the published records and a test header | [link] |
3. SPF budget for each domain
RFC 7208 limits SPF evaluation to 10 DNS-querying terms (include, a, mx, ptr, exists and the redirect modifier), counted across nested includes; more than 10 is a permerror. It recommends a limit of two void lookups. An include that points at a domain with no SPF record also returns permerror, which is how retired services break records. Keep the running count here.
| Domain | Term | Source ID | Lookups | Running total | Last verified |
|---|---|---|---|---|---|
| [example.com] | [include:[mail platform SPF domain]] | [ES-001] | [ ] | [ ] | [date] |
| [example.com] | [include:[ticketing SPF domain]] | [ES-002] | [ ] | [ ] | [ ] |
| [example.com] | [ip4:[on-premises relay range]] | [ES-003] | [0] | [ ] | [ ] |
| [example.com] | [-all or ~all] | n/a | [0] | [total, must be 10 or fewer] | [ ] |
When the budget is close to 10, move a source to its own subdomain, rely on aligned DKIM for that source (DMARC passes if either SPF or DKIM passes aligned), or replace an include with the provider's documented IP ranges if the provider commits to notifying changes.
4. DKIM selector register
DKIM public keys are found at selector._domainkey.domain (RFC 6376). Selectors let a domain run several keys at once, for example one per service, so each key can be rotated or revoked without touching the others. RFC 6376 advises against reusing a selector name for a new key; M3AAWG guidance suggests names that show the owning department and the activation date.
| Selector and domain | Source ID | Record type | Algorithm and length | Activated | Status | Revoked on |
|---|---|---|---|---|---|---|
| [mkt-202611._domainkey.news.example.com] | [ES-004] | [TXT] | [RSA 2048] | [date] | [Signing] | [ ] |
| [mkt-202605._domainkey.news.example.com] | [ES-004] | [TXT] | [RSA 2048] | [date] | [Retired, p= empty] | [date] |
| [selector1._domainkey.example.com] | [ES-001] | [CNAME to provider] | [provider-managed] | [ ] | [Signing] | [ ] |
- Key length: RFC 8301 says signers must use RSA keys of at least 1024 bits and should use at least 2048 bits, and that rsa-sha1 must not be used. Record anything below 2048 bits as an action.
- Rotation: M3AAWG recommends rotating DKIM keys at least every six months: publish the new key, switch signing, keep the old public key for 7 to 30 days, then publish it with an empty
p=rather than deleting the selector. For provider-hosted keys behind a CNAME, record the provider's rotation practice from its documentation. - Revocation: an empty
p=value revokes a key (RFC 6376). Revoke selectors for any service that has been decommissioned.
5. Onboarding and offboarding a sending source
| Step | Onboarding a new sender | Offboarding a sender |
|---|---|---|
| 1 Approve | Ticket with business and technical owner, purpose, volume and contract | Contract end or replacement confirmed by business owner |
| 2 Domain | Decide main domain or dedicated subdomain; check the SPF budget in section 3 | Confirm no live mail still uses it, from aggregate reports |
| 3 DKIM | Publish the provider's selector records; confirm d= is your domain | Publish empty p= for its selectors or remove the CNAMEs |
| 4 SPF | Add the documented include or IPs; set a custom return-path on your domain | Remove the include in the same change |
| 5 Credentials | Create API keys or SMTP credentials with sending scope only; store in the vault; enforce SSO and MFA on the service admin console | Revoke API keys and SMTP credentials; remove admin users; delete the verified domain from the service |
| 6 Verify | Send a test message; record SPF and DKIM aligned pass in the register | Check DNS no longer references the service; mark the row Removed |
Leaving the verified domain configured in a cancelled account is a risk: whoever controls that account, or later recovers it, can still send DKIM-signed mail as your domain while your selector remains published. Removing the selector and the include closes it. Dangling CNAMEs to a provider can also be claimed by someone else; see the Subdomain Takeover and Dangling DNS Guide.
Implementation guidance
- Discover: publish DMARC at p=none with an aggregate report address on every domain, then export the published SPF and DKIM records. List every sending IP and every d= domain from two to four weeks of reports.
- Reconcile: match each report source and each DNS term to a row. Unmatched report sources are unknown senders; unmatched DNS terms are orphans.
- Fix alignment: for each row without aligned SPF or DKIM, configure a custom return-path and a DKIM key on your domain in the service, then confirm in the next reports.
- Enforce: move each domain towards p=quarantine and then p=reject only when every active row shows an aligned pass. RFC 9989 provides the
t=ytest flag, under which receivers apply one policy level lower, for staged moves. - Maintain: review the register against DNS and reports [quarterly], and on every new purchase, contract end or DNS host change. Add a change control rule that no SPF or DKIM change is made without a register row.
Small and large organisations: a small business may have five sources and one domain, so a single sheet and a six-monthly check is enough. A large organisation with hundreds of domains and senders needs the register in the CMDB, automated comparison with DNS and with a DMARC reporting service, and named owners per business unit. The DMARC Buyer's Guide covers reporting tools.
Where identity fits: every sending source is a non-human identity allowed to speak as your domain. Its DKIM private key, its API keys and its SMTP credentials are credentials with an owner and a lifetime, and the service admin console is a privileged account. Govern them like any other secret. See the SendGrid, Mailgun and Mailchimp API Keys Security Guide.
Measures that show the register works
| Metric | Target (ours) | Source |
|---|---|---|
| Share of DMARC aggregate volume from sources in the register | 100% of legitimate volume | DMARC reports |
| SPF terms and DKIM selectors with no register row | 0 | DNS export against register |
| Active sources with aligned SPF or DKIM pass | 100% before p=reject | Test headers, reports |
| Selectors with keys below 2048 bits or older than the rotation period | 0 | Section 4 |
| Days from contract end to removal of include, selector and keys | [30 days or fewer] | Offboarding tickets |
Common failures: a provider signing with its own d= domain so DMARC fails at enforcement; includes for services cancelled years ago, pushing SPF past 10 lookups; selectors deleted instead of revoked, or never revoked; sending API keys shared between teams with no owner; a cancelled account still holding the verified domain; and subdomains used by a sender but left out of the register because only the main domain was reviewed.
| Register area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ATT&CK |
|---|---|---|---|
| Source register and owners | CM-8, SA-9 | ID.AM-02, ID.AM-04 | |
| SPF and DKIM records | SI-8, SC-20 | PR.PS-01 | T1566 Phishing |
| Onboarding and offboarding | CM-8 | PR.PS-01 | T1585.002 Email Accounts |
Standards and references
- IETF: RFC 7208 Sender Policy Framework (SPF)
- IETF: RFC 6376 DomainKeys Identified Mail (DKIM) Signatures
- IETF: RFC 8301 Cryptographic Algorithm and Key Usage Update to DKIM
- IETF: RFC 9989 Domain-based Message Authentication, Reporting, and Conformance (DMARC)
- M3AAWG: DKIM Key Rotation Best Common Practices
- NCSC: Email security and anti-spoofing
Related NHI Mgmt Group resources: Email Authentication Checklist · DMARC, SPF and DKIM Guide · Top 10 Email Authentication Mistakes · Email Identity and BEC Guide · DNS Security Guide