Adding a third-party sender to your SPF record is a normal part of using modern business email. It can also quietly break delivery when someone adds a second SPF record, removes an existing service, or copies a provider example without checking what already sends mail for the domain. The safe approach is to identify every legitimate sender first, make one controlled DNS change, and then test the result.
What SPF is authorizing
SPF is a DNS TXT record that tells receiving mail servers which systems may send mail using your domain in the envelope-from address. Google Workspace, Microsoft 365, a helpdesk, a newsletter platform, an invoicing tool, and a CRM may each need authorization. SPF does not prove that a message is good; it prevents an unauthorized server from passing SPF as your domain.
Make an inventory before editing DNS
List the services that actually send mail as your domain. Include employee mailbox providers, website forms, transactional platforms, support desks, marketing systems, accounting tools, and any agency-operated platform. Look at a recent message header from each service if you are unsure. Many tools only send from their own domain and do not belong in your SPF record, so use the provider’s current documentation and the header evidence rather than guesses.
Use one SPF record, not one per vendor
A domain must publish exactly one SPF TXT record. Adding a new TXT record that begins with v=spf1 creates an SPF PermError for many receivers. Instead, edit the existing record and add the new provider’s approved include: mechanism before its final ~all or -all. Preserve the mechanisms that authorize your existing senders. An illustrative pattern is v=spf1 include:_spf.google.com include:provider.example ~all; do not use that literal provider value in production.
Watch the ten-DNS-lookup limit
Each include can cause further DNS lookups. SPF allows a maximum of ten during evaluation, and a complex vendor stack can exceed it without looking unusually long. Count the full include chain or use a validator after the change. If you are already close to the limit, consolidate senders, remove retired systems, or ask a deliverability specialist about a supported flattening approach. Read our SPF lookup troubleshooting guide before adding another include.
Change, wait, and verify
- Copy the current TXT value somewhere safe.
- Edit the one existing SPF record.
- Wait for the DNS TTL and send a fresh test from the new service.
- Inspect the received message header for
spf=pass. - Confirm that ordinary mailbox mail still passes too.
DNS propagation is not instant everywhere. If results differ between tools, avoid repeated edits; compare the published TXT record and allow caches to expire. Our DNS propagation guide explains what to check during that window.
Keep authentication aligned
SPF is only one signal. Configure DKIM in the new sending service and ensure its domain aligns with your DMARC policy. Review SPF, DKIM, and DMARC together if you need the plain-English relationship. Once the new sender works, document its owner and review it whenever vendors change.
Run Beacon’s free domain check to see the public SPF, DKIM, and DMARC signals before and after your DNS update.
Common mistakes to avoid
Do not authorize a vendor before you know whether it actually sends with your domain, and do not remove an old include while a service is still in use. Avoid using an IP address copied from a help article unless the provider specifically documents it for your account. Finally, do not interpret a successful SPF change as permission to skip DKIM. A provider that signs with its own unrelated domain can still cause DMARC alignment trouble even when SPF passes.
A simple change record helps
Record the date, DNS host, original value, new value, sending service, and test result. That small record is invaluable when a future campaign, vendor migration, or employee asks why an include exists. It also makes it easier to remove authorization safely when a service is retired.