How to Build an SPF Record

What an SPF Record Does

An SPF (Sender Policy Framework) record is a DNS TXT record that declares which servers are authorized to send email for your domain. Receiving mail servers query this record to verify whether a message came from an approved source. Without SPF, any server on the internet can claim to send email as your domain and the recipient has no way to challenge it.

The mxio SPF Builder generates a syntactically correct SPF record based on your selected providers and policy, so you can publish it with confidence instead of hand-assembling DNS syntax.

SPF Syntax Basics

Every SPF record starts with v=spf1 and ends with an all mechanism. Between those two anchors, you list the mechanisms that authorize your legitimate senders.

v=spf1 include:_spf.google.com ip4:203.0.113.0/24 -all

Mechanisms

Qualifiers (the all Mechanism)

The all mechanism at the end of your record defines the default policy for senders not matched by any other mechanism:

• -all (hard fail) — Unauthorized senders fail SPF outright. Recommended for domains with a complete sender inventory.
• ~all (soft fail) — Unauthorized senders get a softfail result. Safer during initial deployment when you might be missing a sender.
• ?all (neutral) — SPF takes no position. Rarely useful.
• +all (pass all) — Authorizes every server on the internet. Never use this.

Building Your Record Step by Step

Step 1: Inventory Your Senders

List every service that sends email as your domain. Common sources include your mail platform (Google Workspace, Microsoft 365), marketing tools (Mailchimp, HubSpot), transactional email (SendGrid, Postmark, Amazon SES), CRM systems, helpdesk software, and email security/filtering services (MailRoute, Mimecast, Proofpoint) that relay outbound mail. Check with each department — marketing, sales, support, and engineering may each have services sending as your domain.

Step 2: Use the SPF Builder

Open the mxio SPF Builder and select your providers from the list. The builder knows the correct include: values for major providers and assembles the record for you. Add any custom IP addresses for your own mail infrastructure.

Step 3: Choose Your Policy

If you are confident in your sender inventory, use -all (hard fail). If this is your first SPF record and you want a safety margin while you verify coverage, start with ~all (soft fail) and tighten to -all once you have confirmed all legitimate senders are included.

Step 4: Publish the Record

Add the generated TXT record to your domain's DNS. Publish exactly one SPF record per domain — multiple SPF records cause a PermError that breaks authentication entirely.

Step 5: Verify

Use the mxio SPF Checker to confirm your record is valid, your senders are covered, and your DNS lookup count is within the 10-lookup limit.

The 10-Lookup Limit

SPF evaluation is capped at 10 DNS lookups per RFC 7208. Every include:, a:, mx:, and redirect= costs at least one lookup, and nested includes within those records count against your total. Google Workspace alone typically consumes 3-4 lookups.

If your record exceeds 10, receiving servers return a PermError and your SPF is invalid. The SPF Builder shows your lookup count as you add providers. If you are approaching the limit, see What Is SPF Flattening? for strategies, or use mxio's Managed SPF to flatten your record automatically.

Real-World Examples by Provider

Every email service has its own include: mechanism. Here are the most common configurations and what they cost against your 10-lookup budget.

Google Workspace

v=spf1 include:_spf.google.com -all

Google Workspace uses _spf.google.com, which nests several sub-includes internally. This single include: costs 3 DNS lookups against your budget. See the Google Workspace setup guide for full SPF, DKIM, and DMARC configuration.

Microsoft 365

v=spf1 include:spf.protection.outlook.com -all

Microsoft 365 uses spf.protection.outlook.com and costs 2 DNS lookups. If you use Exchange Online with on-premises hybrid, you may need additional ip4: entries for your outbound relay servers. See the Microsoft 365 setup guide.

Google Workspace + SendGrid + Mailchimp

A typical multi-provider setup looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net -all

This record costs 5 DNS lookups (3 for Google, 1 for SendGrid, 1 for Mailchimp). Add a CRM like Salesforce (include:_spf.salesforce.com) and you're at 6. Add MailRoute for email security and you're at 7. You can see how quickly the 10-lookup limit approaches with a typical email stack.

Microsoft 365 + Amazon SES + HubSpot

v=spf1 include:spf.protection.outlook.com include:amazonses.com include:spf.hubspot.com -all

This costs 4 DNS lookups (2 for Microsoft, 1 for Amazon SES, 1 for HubSpot). Amazon SES also requires setting a custom MAIL FROM domain for SPF alignment — see the Amazon SES setup guide.

Adding Custom IP Addresses

If you run your own mail servers, add their IPs directly with ip4: or ip6: mechanisms. These do not cost DNS lookups:

v=spf1 include:_spf.google.com ip4:203.0.113.10 ip4:198.51.100.0/24 -all

Use CIDR notation (/24, /28, etc.) for ranges. Avoid a: and mx: mechanisms when you can use ip4: or ip6: directly — they accomplish the same thing but without spending a lookup.

Troubleshooting Your SPF Record

SPF Record Not Working

If your SPF record is published but emails are still failing SPF checks:

1. Verify the record exists — Run the mxio SPF Checker to confirm the record resolves correctly. DNS propagation can take up to 48 hours, though most changes appear within minutes.
2. Check for multiple records — Run dig TXT yourdomain.com or use the SPF Checker. Two v=spf1 records cause a PermError that invalidates both.
3. Confirm the sender is listed — The sending server's IP must match a mechanism in your record. If you added include:sendgrid.net but SendGrid sends from a dedicated IP not covered by that include, SPF will fail.
4. Check alignment — SPF checks the envelope sender (MAIL FROM), not the header From address. If these use different domains, SPF may pass for the wrong domain.

PermError: Too Many Lookups

If the SPF Checker reports a PermError due to lookup count:

1. Count your includes — Each include: costs at least 1 lookup, plus any nested includes inside it. Use the SPF Checker's lookup breakdown to see the real cost.
2. Replace a: and mx: with ip4:/ip6: — If you know the IP addresses, hardcoding them saves lookups.
3. Remove unused includes — Decommissioned services still count against your budget. Audit quarterly.
4. Consider Managed SPF — SPF flattening resolves includes to IP addresses, reducing lookup count. mxio's Managed SPF handles this automatically and keeps the flattened record updated as provider IPs change.

Record Too Long (255-Character Limit)

DNS TXT records have a 255-character string limit, but most DNS providers handle long records by splitting them into multiple strings automatically. If your provider does not, you can split the record manually:

"v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net" " include:spf.hubspot.com -all"

Both strings are concatenated during evaluation. However, if your record is this long, you likely have a lookup count problem too — address that first.

Testing and Verification

After publishing your SPF record, verify it works end-to-end:

Step 1: Check Syntax

Run the mxio SPF Checker against your domain. It validates syntax, counts lookups, and identifies any issues.

Step 2: Send a Test Email

Send an email from each service in your SPF record to a test address. Check the email headers for spf=pass. If you see spf=softfail or spf=fail, the sender is not covered by your record.

Step 3: Monitor DMARC Reports

If you have DMARC configured with rua reporting, your aggregate reports will show which senders pass and fail SPF. This is the most reliable way to catch missing senders over time.

Step 4: Set Up Domain Monitoring

Use the mxio Domain Health Check to monitor your SPF record continuously. You will be alerted if your lookup count changes, if the record becomes invalid, or if a provider changes their include chain.

Common Mistakes

• Multiple SPF records — Only one v=spf1 record per domain. A second record invalidates both. See how to merge multiple SPF records.
• Missing senders — Forgetting a service means its email fails SPF. Audit before publishing. Check with marketing, sales, support, and engineering — any department may have services sending as your domain.
• Using +all — This authorizes the entire internet. It is equivalent to having no SPF at all.
• Ignoring nested lookups — An include: that itself has 4 includes costs 5 lookups total, not 1. Always check the total with the SPF Checker.
• Forgetting email security services — If you use MailRoute, Mimecast, Proofpoint, or Barracuda for inbound filtering and they also relay outbound mail, they need to be in your SPF record.
• Not updating after provider changes — When you add or remove an email service, update your SPF record the same day. Stale records cause authentication failures for new services and waste lookups on decommissioned ones.

Next Steps

Once your SPF record is published and verified:

1. Set up DKIM — SPF and DKIM together provide the authentication foundation for DMARC. Each provider has its own DKIM configuration — see the provider setup guides.
2. Deploy DMARC — Follow the DMARC deployment guide to move from p=none monitoring to p=reject enforcement.
3. Monitor ongoing — DNS records drift. Providers change their include chains. New services get added without updating SPF. Set up continuous monitoring to catch issues before they affect deliverability.

Build your SPF record now