SummaryInventory each sending identity, save the DNS baseline, validate the policy and test actual workflows. Assign every unresolved finding an owner and preserve the evidence for future changes.
In this guide
Define what this audit will establish
For each client domain, aim to produce four things: a list of legitimate sending identities, a saved DNS baseline, test evidence from important workflows, and an owned list of unresolved findings. This makes the result usable during onboarding, a provider migration or the next delivery incident.
Agree which domains and services are in scope. Include customer-facing systems such as invoices, bookings, support tickets and password resets, not only Microsoft 365 or Google Workspace mailboxes. Note any services you cannot access or test. An untested workflow remains unverified even if its policy looks plausible.
1. Build the sender inventory
Download the sender-inventory CSV. Use a row for each service and add rows when one service uses several sending identities. Ask the client’s finance, marketing, website and operations owners to confirm what still runs.
Capture the service owner, business purpose, visible From domain, envelope-sender domain, DKIM signing domain, provider instructions and date last tested. Record occasional jobs explicitly: a quarterly statement or annual renewal notice can be missed in a short observation period.
Use received message samples and available DMARC reports to compare the declared inventory with observed sending. Investigate unknown sources before treating them as legitimate; a report entry is evidence of traffic, not permission to add an IP to SPF. The NCSC describes an iterative approach to identifying and maintaining sending authorisations.
2. Preserve a DNS baseline
For each in-scope sending name, save the TXT values, TTL, authoritative DNS provider, inspection time and relevant referenced policies. Keep the full original strings rather than only a screenshot with truncated values.
Compare a current authoritative answer with a recursive resolver when investigating a recent change. Record any difference and the applicable caching interval. Do not interpret an old cached value as proof that a write failed.
Store the baseline in the client’s normal controlled documentation or ticketing location. Link the evidence to the service inventory so another technician can reproduce the investigation. Redact message bodies, recipient information and unnecessary identifiers from material shared outside that support context.
3. Inspect the SPF policy
- Correct DNS name: match the policy to the service’s observed envelope sender, with HELO identities reviewed where relevant.
- One policy per name: investigate duplicate SPF records while preserving unrelated TXT entries.
- Known authorisations: connect each include or address range to an active service or a documented transition.
- Evaluable dependencies: check malformed terms, missing referenced policies, loops and unresolved DNS responses.
- Lookup headroom: inspect nested records and distinguish a possible maximum from an evaluation for a specific sending IP.
- Deliberate policy: understand qualifiers, redirects and any dynamic mechanisms before proposing changes.
The Emailmetry SPF checker provides a bounded inspection of public records and dependencies. It does not perform a full sender-specific RFC evaluation or test DKIM and DMARC. Preserve any uncertainty it reports as an outstanding finding.
4. Test the actual business workflows
Send fresh messages from representative workflows to external mailboxes you control. Include at least the main mailbox service and each critical automated route. Where forwarding, an outbound gateway or a mailing list is part of normal use, include that path.
Record the test time, workflow, receiving system, SPF result and evaluated domain, DKIM result and signing domain, and DMARC result. Note whether the message arrived and where it landed. Authentication and placement are separate observations.
Use the recipient system’s trusted authentication headers. Microsoft’s message-header reference explains how its results are represented. A mailbox success does not establish that an invoice service passes, and a new test cannot prove how a historical incident behaved.
5. Turn findings into owned work
A useful finding names the affected workflow, observed failure, evidence, proposed action, owner and verification requirement. Prioritise confirmed disruption to legitimate mail, then policy defects and maintenance gaps according to their scope and impact.
| Finding | Next action and owner | Completion evidence |
|---|---|---|
| Invoices return SPF permerror | Messaging technician investigates the recorded lookup path and reviews the proposed repair. | Corrected DNS plus a fresh external invoice test with authentication results. |
| Unrecognised newsletter include | Client marketing owner confirms whether the account and any scheduled campaigns remain active. | Documented ownership or retirement, followed by an appropriate policy decision. |
| SPF passes; DMARC fails for CRM mail | CRM administrator reviews custom DKIM and return-path alignment. | A new CRM message with an aligned authentication pass and DMARC pass. |
| Annual statement workflow not tested | Finance owner arranges a controlled test or supplies suitable retained evidence. | Workflow-specific evidence; keep the item open until verified. |
Avoid automatic cleanup based only on the absence of recent traffic. Likewise, a broad SPF pass caused by an overly permissive policy is not a successful security outcome. The authorisation must match the client’s intended sending services.
6. Make and verify the change
Keep diagnosis and remediation as distinct ticket actions. Once a change is authorised within your client process, save a reviewed recovery policy, identify who can restore it, and agree which failures would trigger recovery.
Apply the smallest complete correction and read back the published DNS. Repeat affected workflow tests, then retain the final values and results. DNS caching affects both a change and its reversal; do not close an incident on the strength of the DNS editor’s success message alone.
The provider-change guide includes a printable checklist. Use it to keep previous settings, tests and anything left to verify together.
7. Assign ongoing ownership
Record who updates the inventory when a department buys a new SaaS product, changes a website integration or retires a service. Review after those events and at an interval appropriate to the client’s rate of change. A calendar review complements change management; it does not replace it.
If managed SPF is appropriate, document the selected providers, compatibility limits and recovery route. Confirm which responsibilities remain with the MSP, especially sender selection, DKIM configuration, DMARC review and real-message testing.
Emailmetry lists Microsoft 365 and Google Workspace in its launch plans. MSPs can review the white-label reseller offering and bulk pricing enquiry. Use the audit to establish a valid, understood policy before considering ongoing management; existing evaluation-limit errors and unsupported rules need separate attention.