How to setup an SPF record?

Setting up an SPF record correctly is a thirty-minute job that prevents most email spoofing attacks on your domain and is mandatory under Gmail, Yahoo and Microsoft's 2026 bulk sender rules. The tricky parts are not the syntax — which is simple — but getting the list of authorised senders complete, staying under the 10 DNS lookup limit, and choosing the right fail policy. This guide walks through a production-ready SPF setup from scratch.

What an SPF record is

An SPF record is a DNS TXT record published on the apex of your sending domain (and on any subdomain that also sends mail). It lists the IP addresses and hostnames that are authorised to send mail using your domain in the envelope sender (MAIL FROM). A receiving mail server looks up this record, compares the connecting IP, and decides whether to accept, soft-fail, or hard-fail the message.

A minimal SPF record for a domain using only Google Workspace looks like this:

example.com. TXT  "v=spf1 include:_spf.google.com ~all"

A more realistic record for a domain using Google Workspace plus Mailgun for transactional mail plus a static IP for a legacy app:

example.com. TXT  "v=spf1 ip4:185.71.60.245 include:_spf.google.com include:mailgun.org ~all"

Step-by-step setup

Step 1: Inventory your senders. This is the step most people skip. List every system that sends mail using your domain:

• Your primary mail platform (Google Workspace, Microsoft 365, etc.)
• Transactional ESPs (Mailgun, Postmark, Amazon SES, SendGrid)
• Marketing ESPs (Mailchimp, HubSpot, Klaviyo)
• CRM and support tools (Salesforce, Zendesk, Intercom)
• Monitoring and alerting (PagerDuty, Statuscake)
• Application servers sending direct from the VPS

Miss one and that system's mail will start failing SPF the moment you publish the record.

Step 2: Get the SPF include or IP for each sender. Every commercial sender publishes one. Common examples:

Google Workspace       include:_spf.google.com
Microsoft 365          include:spf.protection.outlook.com
Mailgun                include:mailgun.org
SendGrid               include:sendgrid.net
Amazon SES             include:amazonses.com
Mailchimp              include:servers.mcsv.net
Postmark               include:spf.mtasv.net
HubSpot                include:_spf.hubspotemail.net
Zendesk                include:mail.zendesk.com

For your own VPS or application server, use the static IPv4 and IPv6 addresses:

ip4:185.71.60.245
ip6:2a01:4f8:c17:abcd::1

Step 3: Build the record. Start with the version tag, list ip4: and ip6: mechanisms first, then include: mechanisms, then close with a fail policy:

v=spf1 ip4:185.71.60.245 include:_spf.google.com include:mailgun.org ~all

Rules:

• Only one SPF record per domain (multiple records is a configuration error and breaks SPF).
• Total length under 450 characters (DNS TXT records can be longer, but many resolvers struggle above 450).
• Under 10 DNS lookups total across all include, a, mx, ptr, and exists mechanisms.

Step 4: Choose your fail policy.

• ~all (softfail) — unlisted senders marked as suspicious but usually delivered. Use this during initial rollout.
• -all (hardfail) — unlisted senders rejected. Use this once you are confident your inventory is complete.
• ?all (neutral) — no opinion. Equivalent to no SPF record. Do not use.
• +all — authorise everyone. Never use.

Step 5: Publish the record. Add the TXT record at your DNS provider. The host field depends on the provider:

• On Cloudflare, Route 53, DigitalOcean: use @ or the bare domain.
• On GoDaddy: use the domain name directly.
• On some providers: leave the host blank.

Set TTL to 300 seconds during rollout so mistakes propagate out of cache quickly.

Step 6: Verify. Use IntoDNS.ai to scan your domain. You want:

• SPF record found
• Syntactically valid
• DNS lookup count under 10
• No redundant or unreachable mechanisms
• Ends with ~all or -all

The 10 DNS lookup limit

This is the most common SPF failure mode. Every include:, a, mx, ptr, exists, and redirect mechanism counts as one lookup. Nested includes count through the entire chain. ip4: and ip6: do not count.

Example of how the limit is reached:

v=spf1
  include:_spf.google.com      (4 lookups internally)
  include:spf.protection.outlook.com (3 lookups internally)
  include:mailgun.org          (2 lookups internally)
  include:servers.mcsv.net     (1 lookup)
  include:sendgrid.net         (3 lookups internally)
  ~all

Even though this has 5 include: directives, the actual lookup count is 13. Any SPF evaluation returns permerror, which most DMARC implementations treat as fail.

Solutions:

• Remove unused senders. If you haven't used SendGrid in two years, take it out.
• Use ip4 directly. For your own infrastructure, list IPs instead of hostnames.
• SPF flattening. Replace include: with the IPs it resolves to. Requires automation because IPs change.
• Subdomain segmentation. Send transactional from mg.example.com (short SPF) and marketing from mail.example.com (separate SPF).

Subdomain strategy

SPF does not inherit from parent to subdomain. If you send from [email protected] and [email protected], both need their own SPF record. DMARC does inherit (via the sp= tag), but SPF explicitly does not.

For most domains, publish SPF on:

• The apex domain (example.com)
• Any subdomain that sends mail
• *.example.com wildcard if many subdomains send

And on subdomains that should never send mail, publish a null record:

v=spf1 -all

This tells receivers that no IP is authorised to send as this subdomain, protecting it from spoofing.

Troubleshooting

"SPF permerror" in Authentication-Results. You are over the 10 lookup limit. Count and trim.

"SPF softfail" but you expected pass. The connecting IP is not in your SPF record. Add it or verify which IP the sender actually uses.

"SPF none" in Authentication-Results. No SPF record found at the MAIL FROM domain. Check that the record is at the correct host and has propagated.

SPF passes but DMARC fails. SPF aligns with the envelope MAIL FROM domain, not necessarily the From: header. If your ESP uses its own domain in MAIL FROM, SPF will not satisfy DMARC alignment and you need DKIM to align instead.

When to use IntoDNS.ai

IntoDNS.ai parses your SPF record, counts DNS lookups, lists every resolved IP and mechanism, flags syntax errors, and tells you exactly how close to the 10-lookup limit you are. For any new SPF setup, scan after publishing to catch mistakes before they break mail.

SPF and forwarding

SPF has a known weakness: it breaks on traditional forwarding. When [email protected] forwards mail to [email protected], the message arrives at Gmail from the forwarding server's IP — which is almost never in the original sender's SPF record. SPF fails, and if the only passing mechanism was SPF, DMARC alignment also fails.

Two mitigations exist:

• DKIM for forwarded mail. DKIM signs headers and body; forwarding rarely breaks it. As long as DKIM passes and aligns, DMARC passes even when SPF fails.
• SRS (Sender Rewriting Scheme). The forwarder rewrites the envelope sender to an address under its own domain, so SPF checks against the forwarder's domain instead. Most mature MTAs (Postfix, Exim, Exchange) support SRS as an option.

For most domains the practical lesson is: make sure DKIM is configured and aligning, because SPF will not survive every mail path.

How SPF interacts with DMARC alignment

A subtle point that catches many domains: SPF "pass" and DMARC "SPF aligned" are different things. SPF is checked against the envelope MAIL FROM (also called Return-Path). DMARC requires that domain to align with the visible From: header. Many ESPs use their own bounce domain in MAIL FROM (e.g. [email protected]). SPF passes, but it passes for sendgrid.net, not for your domain — so it does not help DMARC.

Fix by configuring the ESP to use a subdomain of your domain as the envelope sender (mg.yourdomain), which requires you to delegate that subdomain's SPF to the ESP. This is where a surprisingly large percentage of DMARC fails come from and is one of the few SPF configuration details that differs per vendor.