An SPF record is a DNS TXT record that identifies which mail systems may send using your domain in the envelope-from address. Examples are useful for understanding the structure, but they are not copy-and-paste recipes: the right record depends on the providers that actually send mail for your business. Copying a record from another company can authorize the wrong service or break mail that already works.
What every SPF record has in common
An SPF value starts with v=spf1, contains one or more authorization mechanisms, and ends with an all mechanism such as ~all or -all. A simple conceptual example is v=spf1 include:provider.example ~all. The provider name in that illustration is intentionally not real. Obtain the actual mechanism from your mail provider’s current documentation.
Example: a single mailbox provider
Many businesses begin with only Microsoft 365 or Google Workspace for employee mail. Their record usually contains the provider’s documented include: entry plus an all mechanism. Do not add a second record just because a provider gives you a full-looking example. Find the existing SPF TXT value and edit it only when you have confirmed that it represents the same domain and active mail service.
Example: mailbox plus marketing platform
A business may use a mailbox provider for staff mail and a separate platform for newsletters. In that situation, one SPF record may need both authorized mechanisms, for example v=spf1 include:mail-provider.example include:marketing-provider.example ~all. The order may not be important to SPF evaluation, but each include can trigger further DNS lookups. Test both a staff message and a campaign test after the change.
Example: a dedicated sending IP
Some providers ask you to authorize an IP address. That might appear as ip4:203.0.113.10 in addition to a provider include. Only use an IP supplied specifically for your service. A copied IP entry can authorize another organization’s infrastructure or become stale when the provider changes its network.
Use only one SPF record
A domain must have one SPF policy. Two TXT records beginning with v=spf1 often cause a permanent SPF error because receivers cannot determine which policy to evaluate. This is one of the most common errors after a team adds a newsletter tool or an agency deploys a new platform. Combine the legitimate mechanisms into the existing record instead.
Watch the ten-lookup limit
SPF allows no more than ten DNS lookups during evaluation. An include can reference other includes, so a short-looking record may still exceed the limit. Every new vendor should trigger a lookup-count review. Read the SPF lookup-limit guide before adding another service, especially if the domain has a CRM, helpdesk, marketing, and transactional sender.
Verify from a real message
- Save the original DNS value.
- Update the one SPF record using provider-approved entries.
- Wait for the published DNS value to become visible.
- Send a fresh message from each sender.
- Inspect message headers for
spf=pass.
Do not rely only on a DNS dashboard saying the record was saved. The recipient-side result confirms what mail systems actually evaluated. If results differ after a recent update, see DNS propagation and email issues before making repeated edits.
SPF is not the whole authentication plan
Enable DKIM for every sending platform that supports it, then use DMARC to evaluate aligned results. A sender can pass SPF and still have an alignment issue, while DKIM may provide the aligned signal that lets DMARC pass. Review SPF versus DKIM versus DMARC for the full relationship.
Run Beacon’s free domain check to inspect the publicly visible SPF, DKIM, and DMARC records before and after a change.