When several services send email for your business, give each one a named owner and a documented authentication setup. Start with the mailbox, website and business applications you use, then record how each sends. A list of providers is useful only when you can connect it to the actual messages customers receive.
This is a preparation guide for the person coordinating email and DNS work. The correct record values come from your own provider accounts; there is no SPF or DKIM record that can safely be copied into every business domain.
Build the sender list around real business jobs
Walk through the work that generates mail: replying to an enquiry, sending an invoice, confirming a booking, resetting a customer password and notifying staff about a form. Check which system performs each job. A website may pass its mail to a separate delivery service, so “WordPress” alone may not identify the sender that needs checking.
For every route, record:
- The business job and the person responsible for it.
- The application and sending provider, including the relevant account or tenant reference kept privately.
- The address customers see in From, and the reply destination.
- The envelope-sender domain and DKIM signing domain found in a representative message.
- The provider’s current authentication instructions, the DNS names requested and the result of a fresh test.
Include occasional services such as annual reminders. Mark retired routes as retired and confirm that they have stopped sending before asking an administrator to remove related authorisation.
Understand the three domain identities
The visible From address is the identity a customer recognises. SPF checks the domain used by the envelope sender, also called MAIL FROM; this can differ from the visible address. DKIM checks a digital signature associated with a signing domain, shown as d= in the signature.
DMARC brings these identities together by checking alignment with the visible From domain. A message can pass SPF for a supplier’s domain without that result aligning with your business domain. A passing, aligned SPF or DKIM result can support a DMARC pass. Your administrator needs the domains as well as the pass/fail labels.
Microsoft’s authentication overview explains these identities. Ask a third-party platform whether it supports domain signing or a custom envelope-sender domain for your account, and follow its supported setup.
Keep one SPF policy at each relevant DNS name
If two providers both ask for an SPF record at the same hostname, do not publish two separate SPF policies there. Have the administrator combine the required authorisations into one valid policy while preserving the other legitimate senders. Other TXT records can coexist at that name; the restriction concerns multiple SPF policies.
Microsoft’s SPF guidance covers this multiple-record failure. Check the exact hostname too: a policy for a sending subdomain and a policy at the main domain are separate records, each needing its own review.
There is also a processing limit. The SPF standard limits DNS-lookup-causing terms to ten during evaluation, including nested processing. Counting the providers or the visible include entries in your own record can miss work performed by an included policy. Ask the administrator to check the complete evaluation and any reported errors rather than deleting a necessary sender to make a checker look better.
Keep each provider’s DKIM selectors identifiable
A DKIM selector identifies the key used to verify a signature. Several services can use different selectors for the same business domain. Record the selector names and which provider owns them, so a later website move or staff handover does not leave unexplained records behind.
Providers may request TXT or CNAME records for DKIM. For example, Microsoft 365 uses provider-supplied CNAME values. Copy the exact names and values from the authenticated provider account into the change request, including any separate signing activation step. If two requests appear to use the same DNS name, stop and ask the providers how to resolve the collision.
Do not remove an older key simply because a newer selector exists. Confirm the provider’s rotation instructions and whether messages are still being signed with the older selector.
Make a controlled change and test every active route
Identify the authoritative DNS service, take a record export or suitable backup and save the existing values before any change. The domain and DNS change checklist covers the account, approval and recovery arrangements. If this is part of a hosting move, keep the website and email migration plan alongside the sender inventory.
After the administrator completes an agreed change, send a fresh, clearly labelled test from each affected application to agreed recipients. Compare the received authentication domains and results with the intended configuration. Confirm that replies reach the expected mailbox and that the normal business workflow still works.
Preserve existing DMARC protections while investigating individual senders. A DNS change and a decision to change domain policy are separate pieces of work. Give the responsible administrator the failing route and evidence so they can propose a suitable fix.
Leave a record the next person can use
Finish with a dated sender inventory, the change record, fresh-message results and any unresolved provider case. Name who reviews the inventory when a new website feature, accounts system or booking tool is introduced.
For unexplained ongoing failures, start with the outgoing-email diagnostic guide. If you have aggregate reports, use them to check for legitimate routes missing from the inventory. Neither requires turning a list of unknown IP addresses into new authorised senders.
When commissioning a website in Formby, Freshfield or L37, include the systems that need to send notifications in the project brief. Agree responsibility for the website, mail provider and DNS work before a new sending route goes live.
