A checklist is useful only when it records evidence
A tick beside “SPF set up” can hide the wrong domain, duplicate records or a provider route that was never tested. The same problem applies to DKIM and DMARC. A small business needs fewer abstract ticks and more dated evidence tied to each route.
Use this checklist as a change record. For every item, record the owner, exact domain or application, evidence location, observed result, UTC time and action. “Done” should mean another authorised person can reproduce the check, not that a setup wizard displayed a success icon.
The NCSC presents email anti-spoofing as an ongoing combination of SPF, DKIM, DMARC and monitoring across organisational domains. The NCSC email security collection sets out that UK operational context. The reframe is to review ownership and routes before records.
Confirm control and recovery before changing mail
- Domain control: record the registrar, DNS host, renewal owner and expiry protection. Confirm the administrator can reach the authoritative zone.
- Account recovery: verify recovery methods for DNS, mailbox and sending-platform administrators through approved channels. Do not copy recovery codes into the checklist.
- Change authority: name who approves DNS edits and who can pause each critical sender.
- Rollback: export or record current MX, relevant TXT and CNAME values with TTLs before editing.
- Business timing: avoid an enforcement change during payroll, invoicing, a campaign or an unsupported period.
Stop here if ownership is disputed, the registrar account is inaccessible or no safe rollback exists. Authentication work cannot compensate for weak domain control.
Before changing anything, confirm you can already recover. Log in to the DNS provider, the sending platforms and the reporting addresses, and verify you or a named colleague can access them. A checklist that records control and recovery first prevents a well-intentioned audit from turning into an account-lockout incident halfway through, when half the records have been changed and nobody can sign in to finish or revert them.
Inventory every route that uses the domain
List staff mail, shared inboxes, finance and payroll, shops, bookings, support, CRM, newsletters, website forms, devices, monitoring and outsourced services. Give each route a business and technical owner. Use one row for each distinct From, envelope or signing configuration.
Trigger a controlled message from every critical route. Record the visible From domain, MAIL FROM or Return-Path domain, DKIM d= and selector, SPF, DKIM and DMARC results, receiver and UTC time. Store full headers with restricted access.
Compare the list with DMARC aggregate sources, contracts and application settings. Reports can reveal gaps but do not prove completeness. Mark unknowns for investigation instead of authorising them or declaring them hostile.
Verify SPF at the envelope domain
Query the exact MAIL FROM domain observed in a message. Confirm there is one SPF record beginning v=spf1, that active sending hosts are authorised through an understood mechanism, and that retired services are not retained without a reason.
Expand includes with an appropriate validator and check processing limits. Do not paste a second SPF record or flatten provider addresses without an ownership and maintenance plan. Save the query and tool time beside the route.
Google tells senders to authenticate each sending domain and include legitimate third-party senders in the relevant SPF design. Google’s current email sender guidelines describe its requirements. Its guidance does not mean every provider belongs in the root domain’s SPF record; follow the identity actually used.
an SPF, DKIM and DMARC guideUse privacy-conscious free DNS and header checks to collect the public and message-level evidence named here.
Verify DKIM from a received message
Use a controlled message to find the signing domain and selector. Query selector._domainkey.signing-domain and confirm the public record belongs to the intended service. Then check the receiver’s DKIM verdict, because a visible DNS key does not prove the route signed or that signed content survived.
Confirm the provider uses a business-controlled aligned signing domain where required. Record key owner and rotation process. Keep private keys only in the authorised signing system. If a selector name already exists, do not overwrite it; ask the provider for a distinct supported selector.
A DKIM pass authenticates the signing domain, not the sender’s personal identity or the safety of content. Preserve that limitation in staff guidance.
email authentication glossaryVerify DMARC as a comparison and policy
Query the applicable _dmarc record. Check version, policy, reporting destinations, alignment modes and subdomain handling. DMARC passes when a passing SPF or DKIM domain aligns with the visible From domain. RFC 9989 defines this result and the policy model.
Confirm aggregate reports reach a controlled mailbox or approved processor and are reviewed. Classify legitimate passes, legitimate failures, likely unauthorised use and unknown sources. Do not increase policy to make a checker happier; increase it only when critical authorised routes are ready and support is available.
Remember that DMARC policy is a receiver-facing preference and does not guarantee inbox placement. Keep delivery, content, permission and account compromise as separate checks.
Treat DMARC as both a diagnostic and a policy. While it stays at p=none it reports authorised and unauthorised sources without affecting delivery, which makes it a safe starting point for learning your real sender map. Only when the records and their alignment are understood should you consider moving to quarantine or reject, and each stage should be verified against received mail before the next.
a full DMARC guideIf the passing domain does not match the address people see, the DMARC alignment guide explains the comparison.
Test recovery and monitoring as real operations
- Restore access safely. Have an authorised administrator confirm recovery contacts without exposing credentials.
- Receive a report. Verify that the reporting mailbox or processor accepts and retains expected aggregate data.
- Run a route control. Test ordinary staff mail after any third-party or DNS change.
- Review failures. Assign unexplained legitimate failures and unknown sources to named owners with dates.
- Exercise rollback. Confirm the saved prior value is complete and that the approver knows when it may be restored.
Monitoring that nobody opens and recovery that nobody has tested are documentation claims, not controls. Keep the exercise small and avoid changing production solely to prove a hypothetical.
Keep the checklist useful without turning it into a password file
Record evidence references in the checklist, not the sensitive evidence itself. A useful entry names the route, domain, owner, result, UTC time and location of the approved DNS snapshot or redacted header. Keep full message headers with the mail administrator and detailed recovery contacts with the account owner. The broadly shared checklist should not contain mailbox passwords, private keys, API tokens or one-time recovery codes.
Limit personal data to what the check genuinely needs. Local parts, recipient addresses, subjects and customer details can usually be removed while retaining From, Return-Path, DKIM fields and receiver verdicts. Aggregate-report exports reveal providers and business volumes, so share assigned extracts with route owners rather than giving everyone access to the reporting mailbox.
Add an owner and review date for each evidence store. If a contractor or supplier needs a sample, use its verified support channel and provide only the fields tied to its system. Pause that checklist item when nobody can approve access to staff or customer mail; weak data handling is not an acceptable price for a green tick.
Ask a second administrator to reproduce the checks
Hand a second authorised administrator the checklist and evidence references, but no verbal shortcuts. They should be able to query the stated SPF, DKIM and DMARC names, find the saved baseline and trigger each critical business route. At the controlled receiver, they should observe the documented From, envelope and signing domains and reach the same authentication result.
Include an ordinary staff message and one high-impact application such as invoices or account recovery. Confirm that report collection, bounce ownership and the rollback contact are real, not just named in a document. If an authentication edit was made, compare these results with the earlier baseline and keep both sets with their UTC times.
A failed reproduction reopens the checklist item. Record whether the mismatch came from stale DNS, a changed provider route, missing access or an incorrect owner. Do not replace it with a fresh “done” date until the evidence and operational route agree.
Read a sample of the notes aloud with the person who would cover an absence. Labels such as “website mail” or “marketing SPF” are too vague if that person cannot locate the account, trigger the route and recognise the expected domains. Rewrite the item around the actual action and evidence reference.
Also compare the checklist with current supplier contracts and the DNS change log. A route may still pass while nobody owns its account, or a recently added record may have no corresponding business use. Record either gap as work to resolve rather than treating technical success as approval.
Leave the records alone when the safety checks fail
Stop before editing if the registrar or DNS account cannot be recovered, the current records have not been saved, a critical sender lacks a pause owner, or the work falls inside a payroll or billing run. If production mail changes unexpectedly, use the approved rollback and preserve a received example rather than trying several fixes at once.
The domain owner should coordinate the DNS administrator, route owner and provider support. Give them the checklist item, baseline, exact query and controlled test. A provider must not receive private signing keys or recovery codes. Do not weaken DMARC across the domain or add an unexplained service to SPF to meet a completion date.
Keep the item open with a named decision and review date. Authentication work can resume once control, evidence and rollback are all available; until then, maintaining the known working state is the safer result. Note who will check the affected route next, which mailbox will receive the test and which earlier result will be used for comparison. That turns a pause into a controlled handover rather than an abandoned task.
Sources and further reading
- Google email sender guidelines
- NCSC email security and anti-spoofing guidance
- RFC 9989: Domain-based message authentication, reporting and conformance