How to Set Up SPF Records Without Breaking Email

Setting up an SPF record incorrectly can block legitimate email or open your domain to spoofing. This guide walks through the exact steps to configure SPF authentication without breaking delivery.

What Is an SPF Record?

An SPF (Sender Policy Framework) record is a TXT record in your DNS that lists every IP address or domain authorized to send email for your domain. When a receiving server gets a message from your domain, it checks the SPF record to see if the sending server is allowed. If not, the email may be rejected or marked as spam.

The record lives in your DNS zone file as a TXT record starting with v=spf1. The rest of the record defines mechanisms and qualifiers that describe which senders are allowed.

How to Build Your SPF Record

Start by identifying every source that sends email as your domain. This includes your own mail server, your ESP (like Mailchimp or SendGrid), your CRM (like Salesforce or HubSpot), your transactional email service (like Postmark or Amazon SES), and any other tool that sends on your behalf.

For each source, add the corresponding mechanism:

• ip4: – Specify a single IPv4 address or a CIDR range. Example: ip4:192.0.2.0/24
• ip6: – Same for IPv6 addresses.
• include: – Include the SPF record of another domain. Use this for third-party services. Example: include:_spf.google.com
• a – Authorize the A record of your domain.
• mx – Authorize your domain’s MX servers.
• exists: – Use a DNS query to check authorization. Rarely needed.

After listing all mechanisms, add an all mechanism to define the default action for senders not matched. Common values:

• +all – Allow anything. Never use this.
• ?all – Softfail. Treat as neutral. Good for testing.
• ~all – Softfail. Mark as suspicious but deliver.
• -all – Hardfail. Reject unauthorized senders. Use for production after testing.

Step-by-Step SPF Setup Process

1. List all email sources – Collect IPs or domains for every service that sends mail from your domain.
2. Get the include value – For each third-party service, find their SPF include value (usually documented in their help center). Example: SendGrid uses include:sendgrid.net.
3. Write the record – Combine all mechanisms in one string. Example: v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.0/24 ~all
4. Check the 10-lookup limit – Each include, a, mx, and exists counts as a DNS lookup. If the total exceeds 10, your record is invalid. Use SPF testing tools to check.
5. Publish the record – Add a new TXT record in your DNS zone with host @ for the domain (or a subdomain if needed).
6. Verify – Use an SPF lookup tool to confirm the record is published and valid.
7. Monitor – Review your email delivery logs to catch any legitimate senders still failing SPF. Adjust the record as needed.

Common Mistakes That Break Email

Multiple SPF Records

You can only have one SPF record per domain. Having two or more causes a permerror (permanent error) and receivers treat the result as neutral, meaning SPF offers no protection. Never split your rules across multiple records.

Using Too Many Lookups

Each include pulls in the target domain’s entire SPF record, which may itself contain more includes. The total DNS lookups required to evaluate your record must be 10 or fewer. If you exceed 10, the record fails. Simplify by removing redundant includes or using IP-based mechanisms.

Softfail on Critical Mail

Using ~all or ?all for transactional or marketing mail sends a weak signal. Some receivers still deliver mail that fails SPF, which can hurt your sender reputation. For important mail, use -all after testing.

Forgetting Subdomains

If you send from newsletter.example.com, that subdomain needs its own SPF record if the parent domain’s record doesn’t apply. Many senders forget this and wonder why subdomain mail fails SPF.

SPF Syntax Reference Table

Mechanism	Syntax Example	Purpose
ip4	ip4:192.0.2.0/24	Allow a specific IPv4 address or CIDR range.
ip6	ip6:2001:db8::/32	Allow a specific IPv6 address or range.
include	include:_spf.google.com	Delegate authorization to another domain’s SPF record.
a	a	Allow the domain’s A record IPs.
mx	mx	Allow the domain’s MX servers.
exists	exists:%{i}.spf.example.com	Check if a domain exists via DNS.
all	-all	Qualifier for unmatched senders: + pass, ? neutral, ~ softfail, - fail.

Testing Your SPF Record Before Deploying

Before updating DNS, test your proposed record. Online SPF validation tools parse your record and report errors like too many lookups, missing v=spf1, or syntax issues. They also show how many lookups are used so you can stay under ten.

Once published, wait for DNS propagation (up to 48 hours but often minutes), then check again. Many ESPs provide a test address that will send you back the authentication results. Use that to confirm SPF passes for each of your sending servers.

How to Handle SPF Failures in Your Logs

When a legitimate email fails SPF, check your logs for the failing IP. If it belongs to a service you use, add that IP via ip4: or the service’s include: mechanism. If the IP changes frequently, use the include: instead. Also verify that the envelope domain matches your SPF-record domain — some senders use a different envelope domain by mistake.

If the failure is due to forwarding, SPF alone can’t fix it. The forwarder changes the envelope sender, which breaks SPF. In that case, rely on DKIM and DMARC. DMARC can still pass if DKIM aligns, even if SPF fails.

When to Use a Subdomain Instead of the Apex Domain

If you send marketing or transactional email from many different services, consider using a dedicated subdomain like marketing.yourdomain.com. This isolates the reputation of your main domain. You can then publish a looser SPF record on the subdomain without affecting the apex domain’s strict policy.

For example, use v=spf1 include:sendgrid.net ~all on your subdomain, while the apex domain may have v=spf1 ip4:your-server-ip -all. This way, a mistake on the subdomain doesn’t hurt your primary domain’s deliverability.

Next Steps: Pair SPF with DKIM and DMARC

SPF alone is not enough. SPF authentication can fail when email is forwarded, because the forwarder changes the envelope sender. DKIM (DomainKeys Identified Mail) uses a cryptographic signature that survives forwarding. DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells receivers what to do when SPF or DKIM fails, and gives you reports to monitor authentication.

After setting up SPF, move on to DKIM signing for all outgoing mail, then publish a DMARC policy. Start with p=none to collect reports, then tighten to p=quarantine or p=reject once you are confident all legitimate senders are authenticated. For more on email infrastructure fundamentals, check out this overview.

Frequently asked questions

What happens if I have more than one SPF record?

Multiple SPF records for the same domain cause a permerror (permanent error). Receivers treat the SPF result as neutral, which offers no protection. Always merge all mechanisms into a single TXT record.

How do I include multiple third-party senders in SPF?

Use the include mechanism for each sender. For example, include:_spf.google.com include:sendgrid.net. Keep the total DNS lookups under 10, including those from each included domain.

What is the 10-lookup limit and how do I avoid exceeding it?

The 10-lookup limit means your SPF record cannot require more than 10 DNS queries to evaluate. Each include, a, mx, and exists counts as one lookup. Use ip4/ip6 mechanisms when possible to reduce lookups.

Should I use -all or ~all in my SPF record?

Use -all (hardfail) for production environments after testing, because it instructs receivers to reject unauthorized senders. Use ~all (softfail) during testing to avoid blocking legitimate email. Never use +all.

Does SPF protect my domain from spoofing?

SPF alone provides some protection but is not foolproof because it can break when email is forwarded. Combine SPF with DKIM and DMARC for stronger protection against spoofing and phishing.