A new marketing supplier asks you to add a DNS record. Your domain already has an SPF record for business email, so somebody publishes the supplier’s SPF value as a second record at the same name. Both instructions looked reasonable in isolation, but the combined configuration can be invalid.

Before changing DNS, ask who currently sends mail for the business and which domain each system uses. This is a sender-inventory problem as well as a record-editing task. Keep ordinary business mail, website messages and marketing systems in the review.

Concept illustration of consolidating sender authorisation; not a DNS management interface or an actual ITZ project.

One domain name needs one SPF policy

Microsoft’s SPF configuration guidance states that multiple SPF TXT records for the same domain or subdomain cause a permanent error. Other TXT records can legitimately exist at that name; the issue is multiple SPF policies, not the total number of TXT entries.

Do not delete an unfamiliar record on sight. Ask the administrator to inspect the exact DNS name and values and distinguish SPF from verification tokens and other mail authentication records. A supplier using a dedicated subdomain may need a separate policy at that subdomain rather than another policy at the main domain.

Build a sender inventory first

  • Business mail: identify the active mailbox platform and the administrator who owns its configuration.
  • Website messages: identify the service that actually sends forms, invoices or notifications, not just the host serving the website.
  • Marketing: list active platforms, the configured sending domain and the person who approves campaigns.
  • Other systems: check helpdesk, CRM and finance tools that send externally.
  • Retired suppliers: confirm that they no longer send before removing authorisation.

ITZ’s domain, hosting and business email service can help coordinate the DNS and mail-system boundaries. Review your email sender configuration with a list of platforms and domain names; do not submit DNS account passwords.

Agree one reviewed change

Ask the responsible administrator to prepare a single policy containing only approved sources for the exact domain. Check the current vendor instructions for every active platform and review the combined policy’s DNS lookup requirements. Microsoft warns that excessive SPF DNS lookups can also produce a permanent error; merging strings without evaluating the result is not sufficient.

Preserve the pre-change values, the approved replacement and a rollback owner. Choose a change window when someone can investigate failures. Do not weaken the policy broadly to make a test pass, and do not remove the existing business-mail source simply because a new supplier supplied a complete example record.

Validate each mail stream separately

Use authorised test messages containing no sensitive business data. Test ordinary company email and each relevant third-party sender against approved recipient systems. Have the mail administrator inspect the received authentication results and actual envelope sender domain. A successful delivery alone does not establish that SPF evaluated the domain you expected.

Record the sending platform, test time, recipient and observed result. Allow for DNS caching during the investigation, and verify the authoritative configuration rather than repeatedly editing the record in response to one stale lookup. If delivery is missing, the Microsoft 365 message-trace guide provides a separate diagnostic path.

Keep SPF in its proper scope

SPF is one part of email authentication. It does not by itself prove that every visible sender identity is trustworthy or prevent every impersonation attempt. Use the DMARC rollout guide to consider alignment and other authentication controls as a separate, staged task.

The domain, hosting and email planning guide also helps establish who owns DNS access and supplier coordination. Keep this incident focused on the configuration actually observed; it is not evidence that a provider is unreliable or that a domain has been compromised.

Review Your Email Sender Configuration

Bring ITZ the domain name, active sending platforms and a redacted example of the reported failure. We can discuss sender inventory, the current SPF policy and controlled validation. Review Your Email Sender Configuration using the contextual form below.

Official Microsoft guidance reviewed on 28 October 2026. Examples are proposed checks, not client case studies.