Using more than one email provider does not require more than one SPF record. In fact, publishing two SPF records is one of the fastest ways to create an SPF failure. A business might use Microsoft 365 for staff mail, a marketing platform for campaigns, and a support platform for customer messages. The goal is one accurate authorization policy that covers every legitimate sender without exceeding SPF’s lookup limit.
Why multiple providers create risk
Each provider gives DNS instructions, often presented as a complete SPF record. Those examples are designed for a new domain, not necessarily for a domain with existing mail services. If an administrator pastes a second v=spf1 TXT record into DNS, receiving servers can return a permanent SPF error. If they replace the original record, employee or transactional mail may lose authorization.
Build a sender map
Start with outcomes, not vendor names: who sends invoices, account notices, sales mail, support replies, contact-form messages, newsletters, and normal staff messages? For each source, identify the envelope-from domain and whether the service provides SPF, DKIM, or both. Look at recent message headers and current vendor documentation. Old trials and disconnected accounts should not remain authorized indefinitely.
Combine approved mechanisms into one record
Publish one TXT record beginning with v=spf1. Add the provider-specific mechanisms from each legitimate sender, then finish with the domain’s existing all mechanism. For example, a record might contain two vendor includes and an IP address, but the exact entries must come from the services you actually use. Do not copy an example from another domain. Maintain the current authorization for a working mailbox provider while you add the new sender.
Count DNS lookups, not visible words
An include can include other records, and SPF stops after ten DNS-based lookups. Marketing, CRM, and security tools can make a record fail even when it looks short. Validate the expanded record after each addition. Our guide to the SPF ten-lookup limit explains why this matters and what not to do when you hit it.
Test every sending path
- Send a new message from employee mailboxes.
- Trigger one transactional message where possible.
- Send a test campaign only to an approved internal recipient.
- Check headers for SPF results and DKIM signatures.
Do not judge success solely by a dashboard saying DNS saved. A receiving mailbox’s authentication results show whether the policy works in practice. If you see inconsistent results after a change, read how DNS propagation affects email before changing the record again.
Use DMARC as the safety net
DKIM should be enabled for every provider that supports it. DMARC then evaluates alignment and gives you reporting or enforcement options if a sender is wrong. See DMARC policy choices for the safe progression from monitoring to enforcement. Keep a simple sender inventory with an owner for each service; it turns the next vendor change from an emergency into routine maintenance.
Run a free Beacon domain check to review your visible email-authentication records after consolidating providers.
Decide which domain is actually being used
A vendor may let you choose a custom return-path domain or may use its own. That detail affects SPF alignment under DMARC. Ask the vendor which identity appears in the envelope-from address and which domain it uses for DKIM signing. A system that uses its own identity might not need your SPF authorization, while a platform sending directly as your domain almost certainly does. Testing a real message is more reliable than assumptions based on its dashboard.
Review the record after every vendor change
SPF is a living inventory, not a one-time setup task. Remove mechanisms for retired mail services, check lookup count after additions, and retain the person who approves DNS changes. These habits reduce both delivery risk and the chance that a former supplier stays authorized indefinitely.