Most spoofing and deliverability problems come from one domain or one sending service that nobody checked: a marketing platform signing with its own domain, a parked domain with no records, or an SPF record that quietly exceeds ten lookups. This template is a domain by domain checklist that takes each domain you own from no authentication to DMARC enforcement, and checks it against the published requirements of Google, Yahoo and Microsoft Outlook.com for bulk senders. It covers the inventory, SPF, DKIM, DMARC tags under RFC 9989, the bulk sender rules, non-sending domains, transport security and ongoing monitoring. It is written for email administrators, DNS owners and the security engineers who sign off a move to p=reject. For why each mechanism works the way it does, read the DMARC, SPF and DKIM Guide; this page is the checklist you work through and keep as evidence.
How to use this template
- Copy section 1 once per domain, including subdomains that send mail and domains that never send. Replace text in square brackets, such as [Organisation], [domain] and [DMARC report mailbox], with your own details.
- Mark each check Pass, Fail or Exception (link the risk acceptance), and record the evidence: the DNS record text as published, a header from a test message showing the result, or the aggregate report line.
- Checks marked Required (bulk) come from the mailbox provider pages for senders of more than 5,000 messages a day, as published when this page was checked on 8 November 2026. Provider rules change, so re-read their pages before each review.
- Work through the sections in order. Do not move a domain to p=quarantine or p=reject until sections 2, 3 and 6 pass for every legitimate sending source.
- Repeat the review whenever a new sending service is bought, a domain is acquired, or the DNS host changes, and at least every six months.
1. Domain inventory record
| Field | Value |
|---|---|
| Domain and owner | [domain], [business owner], [technical owner] |
| Domain role | [primary corporate / marketing / transactional / regional / parked or non-sending] |
| Sending sources | [mail platform], [marketing platform], [CRM], [ticketing], [billing], [HR system], [on-premises relays] |
| Daily volume to personal mailboxes | [estimate]; above 5,000 a day to Gmail, Yahoo or Outlook.com means bulk sender rules apply |
| DNS host and change process | [DNS provider], [change ticket route], [who can publish TXT records] |
| Current DMARC policy and date reviewed | [p=], [date], [reviewer] |
Build the list of sending sources from aggregate reports as well as from people: after two to four weeks of p=none reporting, every IP that sends as the domain appears in the reports, including services that nobody declared.
2. SPF
| Check | Source | Result |
|---|---|---|
Exactly one TXT record beginning v=spf1 is published at the domain. Two such records produce a permerror, so SPF fails for all mail. | RFC 7208 s3.2, s4.5 | [ ] |
| The record lists every legitimate sending source, using the include values each provider documents, and nothing that is no longer used. | RFC 7208 | [ ] |
Evaluation needs no more than 10 DNS-querying terms in total (include, a, mx, ptr, exists and redirect, counted through nested includes). More than 10 is a permerror. | RFC 7208 s4.6.4 | [ ] |
| No more than two void lookups (terms returning no answer or NXDOMAIN), usually caused by includes for retired services. | RFC 7208 s4.6.4 | [ ] |
The ptr mechanism is not used (the RFC says it should not be published). | RFC 7208 s5.5 | [ ] |
The record ends with ~all or -all, never +all or ?all. With DMARC enforced, either softfail or fail works; -all is the stricter choice for domains with a closed set of senders. | RFC 7208 | [ ] |
| Each third-party service uses a return-path (envelope from) on [domain] or a subdomain of it, so SPF can align for DMARC. Where the provider cannot do this, rely on aligned DKIM for that source and record it. | RFC 9989 alignment | [ ] |
| Sending IPs have valid forward and reverse DNS (PTR) records. | Google, Yahoo | [ ] |
3. DKIM
| Check | Source | Result |
|---|---|---|
Every sending source signs with a d= domain equal to [domain] or one of its subdomains (aligned), not only the provider's own domain. | RFC 9989 alignment | [ ] |
Each source has its own selector, named so the owner is obvious (for example crm2026), so one key can be retired without affecting others. | Practice | [ ] |
| RSA keys are at least 1024 bits, and 2048 bits wherever the provider supports it. Gmail requires 1024 bits or longer for personal accounts and recommends 2048. | RFC 8301; Google | [ ] |
| No source signs with rsa-sha1; RFC 8301 says it must not be used for signing or verifying. | RFC 8301 | [ ] |
| Keys have a recorded rotation date [every 6 to 12 months], and retired selectors are removed from DNS after the last messages signed with them have been delivered. | Practice | [ ] |
A test message from each source shows dkim=pass with the expected header.d value in the Authentication-Results header at the receiver. | Test | [ ] |
| Private signing keys for on-premises signers are stored in a secrets store with named owners, not on shared file systems. | Practice | [ ] |
4. DMARC record
RFC 9989 (May 2026, Standards Track) obsoletes RFC 7489 and RFC 9091. It removes the pct tag and adds np, psd and t. The DMARCbis Changes Guide explains what that means for existing records.
| Tag | Check | Default if absent | Result |
|---|---|---|---|
| v | One TXT record at _dmarc.[domain], starting v=DMARC1. | Required | [ ] |
| p | Policy is recorded and matches the stage in section 7 (none, quarantine or reject). | Treated as none | [ ] |
| sp | Policy for existing subdomains is deliberate; set only where subdomains must differ from p. | Uses p | [ ] |
| np | Policy for non-existent subdomains is reject once the domain is at enforcement, so invented subdomains cannot be spoofed. | Uses sp, then p | [ ] |
| rua | Aggregate reports go to a mailbox or service someone reads: [DMARC report mailbox]. A report address on another domain needs that domain's authorisation record. | No reports | [ ] |
| ruf | Failure reports are either not requested or go to a restricted mailbox, since they can contain message content and personal data. | No reports | [ ] |
| adkim / aspf | Relaxed alignment unless there is a reason for strict; strict alignment breaks subdomain senders. | r (relaxed) | [ ] |
| t | Test mode is used only during a planned step up; remove t=y when the stage is complete. | n | [ ] |
| pct | Removed from the record; RFC 9989 receivers ignore it, so p=reject; pct=10 acts as full reject. | Not defined | [ ] |
5. Mailbox provider bulk sender rules
| Requirement | Google (Gmail) | Microsoft (Outlook.com) | Yahoo | Result |
|---|---|---|---|---|
| Threshold | More than 5,000 messages a day | More than 5,000 messages a day | Bulk senders | [ ] |
| SPF and DKIM | Both required | Both must pass | Both required | [ ] |
| DMARC | Required; p=none accepted | At least p=none | At least p=none, and DMARC must pass | [ ] |
| Alignment | From domain aligned with SPF or DKIM | Aligned with SPF or DKIM, ideally both | From domain aligned with SPF or DKIM; relaxed accepted | [ ] |
| Unsubscribe | One-click (RFC 8058 headers) plus a visible link for marketing mail | Not listed in the requirements announcement | One-click List-Unsubscribe plus visible link; honour within 2 days | [ ] |
| Spam complaint rate | Below 0.30% in Postmaster Tools; aim below 0.10% | Not listed in the requirements announcement | Below 0.3% | [ ] |
| Enforcement | From 1 February 2024 | From 5 May 2025; failing mail rejected with 550 5.7.515 | From February 2024, rolled out gradually | [ ] |
For one-click unsubscribe, check that marketing messages carry both List-Unsubscribe-Post: List-Unsubscribe=One-Click and a List-Unsubscribe header with an HTTPS URL. Google and Yahoo also require TLS for transmission (Google) and RFC 5321 and RFC 5322 compliant messages. Senders below the bulk threshold still need SPF or DKIM, valid reverse DNS and a low complaint rate.
6. Non-sending and parked domains
Domains that never send mail are easy to spoof because nobody watches them. Each one needs records that say so, and they can go straight to reject because there is no legitimate mail to break. See the Domain Portfolio and Lookalike Domain Management Guide for keeping the list complete.
| Record | Value | Result |
|---|---|---|
| SPF | v=spf1 -all | [ ] |
DMARC at _dmarc.[domain] | v=DMARC1; p=reject; sp=reject; rua=mailto:[DMARC report mailbox] | [ ] |
| MX | Null MX (a single MX record with preference 0 and target "."), if the domain must not receive mail | [ ] |
| DKIM | No selectors published; remove any left over from past services | [ ] |
7. Moving to enforcement
- Monitor: publish
p=nonewith rua and collect at least [4] weeks of reports, covering month-end and campaign cycles. - Fix sources: for each source in the reports, get aligned DKIM working first, then aligned SPF; turn off or move anything unknown after asking its owner.
- Quarantine: when aligned pass is above [98]% of legitimate volume for two report cycles, move to
p=quarantine. Uset=yif you want receivers to apply one level lower while you watch. - Reject: after [2 to 4] weeks at quarantine without legitimate failures, move to
p=rejectand setnp=reject. - Roll back: if a legitimate source starts failing, lower the policy one step by editing the record (keep the TTL at [3600] seconds or less during the change so the rollback takes effect quickly), fix the source, then step up again.
- Mailing lists: before reject, check whether staff post to external mailing lists that rewrite messages; RFC 9989 warns that enforcement affects mailing list delivery, so record the decision.
8. Transport security and extras
| Check | Result |
|---|---|
| Inbound and outbound servers support TLS (STARTTLS) with current certificates. | [ ] |
MTA-STS (RFC 8461) policy published at https://mta-sts.[domain]/.well-known/mta-sts.txt with a _mta-sts TXT record, in testing mode first and then enforce. | [ ] |
TLS-RPT (RFC 8460) record at _smtp._tls.[domain] sends TLS failure reports to [mailbox]. | [ ] |
| BIMI considered only after the domain is at quarantine or reject; it does not add protection on its own. | [ ] |
9. Ongoing monitoring and sign-off
| Measure | Target | Current |
|---|---|---|
| Domains at p=reject (sending and non-sending) | [100]% of the inventory | [ ] |
| Legitimate volume with aligned DMARC pass | [99]% or above | [ ] |
| Unknown sources appearing in aggregate reports | Investigated within [5] working days | [ ] |
| SPF lookup count per domain | 8 or fewer, leaving headroom below 10 | [ ] |
| DKIM keys past rotation date | 0 | [ ] |
| Spam complaint rate (Postmaster Tools) | Below 0.10% | [ ] |
Sign-off: [reviewer name], [date], open findings [number] with owners and due dates.
Implementation guidance
Where to start: small organisations with one mail platform and one marketing tool can usually reach reject in a quarter; start with non-sending domains (section 6) because they carry no delivery risk. Large organisations with dozens of sending services should run section 1 as a project, give each business unit a deadline to move its services onto aligned DKIM, and accept that the last 2% of volume takes most of the effort.
Tooling: raw aggregate reports are XML files that few people read by hand; a report processing service or tool is worth it beyond a handful of domains. The DMARC Buyer's Guide covers how to choose one. The NCSC also runs a free email security check that tests a domain against its guidance.
Where identity fits: every sending service is a non-human identity acting as your domain. Its DKIM key and its API key are credentials with an owner and a lifetime. When a contract ends, remove its include, its selector and its API key in the same change. See the SendGrid, Mailgun and Mailchimp API Keys Security Guide.
Common failures: a second SPF record added by a new provider; an SPF record at 11 lookups after one more include; providers signing only with their own d= domain, so DMARC fails at enforcement; subdomains left at p=none through sp; failure reports full of personal data sent to a third party without a contract; and DMARC at reject on the main domain while lookalike and parked domains stay open.
| Checklist section | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ATT&CK |
|---|---|---|---|
| SPF, DKIM, DMARC (2 to 4, 6) | SI-8, SC-20 | PR.PS-01 | T1566 Phishing |
| Transport security (8) | SC-8 | PR.DS-02 | |
| Monitoring (9) | SI-8 | DE.CM-09 | T1585.002 Email Accounts |
| Whole checklist | CM-6 | PR.PS-01 |
Standards and references
- IETF: RFC 9989 Domain-based Message Authentication, Reporting, and Conformance (DMARC)
- IETF: RFC 7208 Sender Policy Framework (SPF)
- IETF: RFC 8301 Cryptographic Algorithm and Key Usage Update to DKIM
- Google: Email sender guidelines
- Yahoo: Sender best practices
- Microsoft: Outlook's new requirements for high-volume senders
- NCSC: Email security and anti-spoofing
Related NHI Mgmt Group resources: DMARC, SPF and DKIM Guide · Email Security Guide · DMARCbis Changes Guide · Email Authentication for Developers Guide · DNS Security Guide