How to Set Up SPF Records Without Breaking Your Email

SPF records tell receiving mail servers which IP addresses are allowed to send email for your domain. Without one, anyone can forge your domain. But a bad SPF record is worse than none — it can block legitimate email, frustrate recipients, and damage sender reputation. This guide explains exactly how to set up SPF records without breaking your email.

What is an SPF record and why do you need one?

An SPF (Sender Policy Framework) record is a TXT record in your DNS that lists all servers authorized to send email on behalf of your domain. Recipient mail systems check it to decide whether to accept or reject incoming mail. Without SPF, spammers can spoof your domain. With a broken SPF record, your own mail may bounce or land in spam.

Step-by-step: How to set up an SPF record

Step 1: Identify all email sources for your domain

Make a list of every service that sends email from your domain. Common sources include your office email server (like Microsoft 365 or Google Workspace), your email marketing platform (like Mailchimp or SendGrid), your CRM, transaction emails, and your own web server. For each source, get the exact sending IP address or the domain from which they send. Don’t forget automated tools like helpdesk systems or analytics platforms that send reports. Check with your IT team or review your email logs to find every outbound SMTP server. If you’re unsure, temporarily set a neutral policy and monitor who sends, but be aware that this leaves your domain open to spoofing.

Step 2: Write your SPF record

An SPF record always starts with v=spf1. Then you add mechanisms. Here is a typical structure for a small business using Google Workspace and SendGrid:

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

The include mechanism authorizes the listed domains. The -all mechanism tells recipients to reject mail from any server not listed. This is a hard fail policy. Use ~all (soft fail) during testing, but switch to -all in production. If you have a handful of static IPs, use ip4 statements instead of include to avoid extra DNS lookups. For example: v=spf1 ip4:203.0.113.1 ip4:198.51.100.2 -all. This is the simplest and most reliable record when you control all sending IPs.

Step 3: Keep DNS lookups under 10

Each include, a, mx, or ptr mechanism counts as a DNS lookup. The SPF specification limits the total to 10 lookups per record, including lookups inside included domains. If you exceed 10, your SPF record becomes invalid (permerror). Receivers will treat it as neutral and may deliver your mail but more likely reject it. To stay under 10, consolidate services that share a sending infrastructure, or use IP-based mechanisms instead of include where possible. For example, if you use multiple SendGrid accounts, a single include:sendgrid.net covers them all. Also check how many lookups each include domain uses. Some providers like Mailchimp use few lookups; others may add many. Use a tool like dig or an online SPF inspector to count the total before publishing.

Step 4: Test your SPF record before publishing

Publish your SPF record as a TXT record for your domain (e.g., example.com, not sub.example.com). Wait for DNS propagation (up to 48 hours). Then test with a free SPF validator like MXToolbox or Kitterman SPF Tester. The tool will report syntax errors, too many lookups, or unexpected mechanisms. Fix any issues before going live. Test from multiple locations to ensure the record resolves correctly across different DNS servers.

Step 5: Monitor delivery after deployment

After publishing, check your email logs for bounced messages or spam complaints. Look for SPF fail errors on mail that should be legitimate. Adjust the SPF record by adding missing IPs or removing obsolete ones. Repeat testing until all legitimate sources pass SPF. Set up DMARC reporting to get aggregate data about SPF failures. This helps identify sources you may have missed. If you start seeing bounces from a particular recipient domain, check if they enforce SPF strictly. Some ISPs are more aggressive than others.

SPF mechanisms and qualifiers explained

An SPF record uses mechanisms and qualifiers to tell receivers how to handle mail from a given source. Common mechanisms:

• a — authorizes mail from the domain’s A record.
• mx — authorizes mail from the domain’s MX servers.
• ip4 — authorizes a specific IPv4 address or range.
• include — authorizes servers listed in another domain’s SPF record.
• all — matches all IPs (always the last mechanism).

Qualifiers set the action:

• + (pass) — the default; allow the mail.
• – (fail) — reject the mail.
• ~ (soft fail) — mark but don’t reject.
• ? (neutral) — no policy.

Common mistakes that break your email

Using a catch-all mechanism like +all

Some records use +all to allow all senders. This defeats the purpose of SPF. Anyone can spoof your domain. Never use +all in a production SPF record. Always use -all or at least ~all.

Too many DNS lookups

Each include may pull in multiple lookups from the included domain. If you include three email providers, each with three lookups, you might hit the 10-lookup limit quickly. Check the SPF records of services before including them. Some providers publish a flat record with few lookups. If you hit the limit, consider using ip4 or ip6 for small ranges to reduce lookups. For example, instead of include:sendgrid.net, you could use ip4:167.89.0.0/17 if you want to be more specific, but note that IP ranges can change without notice.

Leaving out a legitimate sending source

If you miss an IP or service, emails from that source will fail SPF. This can cause silent bounces or spam placement. Regularly audit your email sources and update your SPF record. Create a process: every time you add a new email service, update the SPF record immediately. Use DMARC reports to catch unknown senders.

Using the wrong syntax

SPF records require precise syntax. A misplaced space or missing mechanism can invalidate the entire record. Always copy-paste tested records and avoid manual editing. Use an SPF record generator from your email provider if available. Double-check that there is no extra whitespace at the end.

Comparison: Hard fail vs. soft fail

Policy	Qualifier	Behavior	Recommended for
Hard fail	-all	Reject unauthorized mail	Established domains with control over all sending
Soft fail	~all	Tag but don’t reject	Testing, new domains, or when unsure of all sources
Neutral	?all	No preference	Minimal configuration, but offers little protection

Start with soft fail during testing. Once you’re confident all legitimate sources are covered, switch to hard fail. If you have multiple domains, each should have its own SPF record. Subdomains can have their own record that overrides the parent domain’s record.

How to fix a broken SPF record

If you accidentally publish a bad SPF record, here’s the fix:

1. Use a DNS checker to see your current TXT record.
2. Copy the record and paste it into an SPF validator.
3. Identify errors: too many lookups, invalid mechanism, or missing include.
4. Correct the record locally. Reduce lookups by replacing include with ip4 for small ranges.
5. Publish the corrected TXT record. There can be only one SPF record per domain. If you have multiple, combine them.
6. Wait for propagation and test again.
7. If you’re unable to edit the TXT record immediately, consider removing the record temporarily (which disables SPF for your domain) while you prepare a correct one. That’s safer than having a broken record that blocks all mail.

SPF and your broader email authentication strategy

SPF alone isn’t enough. Pair it with DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting, and Conformance). SPF checks the envelope sender, while DKIM verifies the message integrity. DMARC tells receivers what to do when SPF or DKIM fails and gives you reports on authentication results. For a full audit, check out our Email Deliverability Audit: A Step-by-Step Guide for Marketers.

How to audit existing SPF records regularly

Email sources change frequently. New services are added; old ones are decommissioned. Review your SPF record at least once per quarter. To audit, export your current DNS TXT record and cross-reference it with your list of sending services. Check each include domain to see if its SPF record has changed. If an included provider modifies their record, it may affect your lookup count or authorization. Use a monitoring tool that alerts you when your SPF record changes or when your lookup count approaches the limit. Many DNS management platforms offer change detection. Keep a spreadsheet of all authorized senders and their IPs or domains. This makes it easier to update the record quickly when needed.

Final checklist for a safe SPF setup

• List all sending sources.
• Write SPF record with v=spf1 and mechanisms.
• Count DNS lookups: stay under 10.
• Use -all or ~all at the end.
• Test with a validator before publishing.
• Monitor delivery for 48 hours.
• Combine with DKIM and DMARC.
• Audit quarterly and update as needed.

Set it once, review it quarterly. A well-configured SPF record is the foundation of email authentication. Get it right, and your mail will reach the inbox. Get it wrong, and you’ll have a mess to clean up.

Frequently asked questions

What does SPF stand for?

SPF stands for Sender Policy Framework. It is an email authentication method that uses a DNS TXT record to specify which IP addresses are authorized to send email on behalf of your domain.

Can I have multiple SPF records for one domain?

No. A domain can have only one SPF record. If you add multiple TXT records that start with v=spf1, they will conflict. Instead, merge all mechanisms into a single record.

What happens if my SPF record has more than 10 DNS lookups?

Receiving servers will treat the record as invalid (permerror). They may accept the mail or reject it depending on their own policy. To fix it, reduce the number of includes or use ip4 mechanisms.

Should I use -all or ~all?

Use ~all (soft fail) during testing or if you are not sure you have listed all sending sources. Once you are confident, switch to -all (hard fail) for stronger protection.

How do I test my SPF record?

You can use free online SPF validators like MXToolbox or Kitterman’s SPF Tester. Enter your domain, and the tool will parse your record, check for syntax errors, and count DNS lookups.