Free SPF record generator

What an SPF TXT record does

SPF tells a receiver which hosts may send mail for a domain. The check uses the domain in MAIL FROM, or the HELO name when MAIL FROM is empty. The receiver looks up TXT records at that domain and keeps the ones that begin with exactly v=spf1 (RFC 7208 sections 4.4 and 4.5). Mechanisms are tested from left to right. The first match wins, and its qualifier is the result: + pass, - fail, ~ softfail, or ? neutral. The qualifier defaults to + when it is left off (section 4.6.2).

all always matches, so it is the rightmost mechanism and the result for every host that did not match earlier (section 5.1). Mechanisms after all are ignored. ~all is a softfail: the domain believes the host is probably not authorized, and receivers should not reject the message based solely on that result (sections 2.6.5 and 8.5). -all is a fail: the client is not authorized (sections 2.6.4 and 8.4). ?all is neutral, and receivers must treat neutral exactly like none (section 8.2). If the record has no all and no redirect, the default result is neutral, as if ?all had been written (section 4.7).

+all is the pass qualifier on a mechanism that always matches. Any client IP passes. RFC 7208 Appendix A.1 shows v=spf1 +all as a record where any IP passes. This generator does not emit +all.

A domain name must not have multiple records that would cause a check to select more than one (section 3.2). If more than one TXT record begins with v=spf1, the result is permerror (section 4.5). Add new senders to the record you already have. If no record begins with v=spf1, the result is none.

The limit of 10 DNS lookups

include, a, mx, ptr, and exists, and the redirect modifier, each cause a DNS query. Implementations must limit the total number of those terms to 10 during one SPF check. Over 10, the result is permerror (section 4.6.4). ip4, ip6, and all do not cause a DNS query when the record is evaluated, so they do not count. The exp modifier looks up a name only after a fail, and it does not count toward this limit.

The limit is one global limit for the whole check, including recursive checks from include (section 4.1). An include that itself contains includes can spend several of the 10 lookups. This page counts the mechanisms it writes. It does not fetch the included records, so a count under 10 here can still go over the limit at a receiver. ptr is not offered. RFC 7208 section 5.5 says the ptr mechanism should not be published.

The mx mechanism has a second limit. After the MX lookup, which counts as one of the 10, checking more than 10 address records for that mechanism is a permerror (section 4.6.4). If a name has no MX record, receivers must not fall back to an A or AAAA record for the same name (section 5.4). The a mechanism matches an A record for an IPv4 client and an AAAA record for an IPv6 client (section 5.3).

One character-string inside a TXT record is at most 255 octets. Several strings may be published in one record, and receivers concatenate them with no added space (section 3.3). The published record should stay small enough that a query for it fits in 512 octets (section 3.4).

Includes from provider documentation

The checkboxes add include domains copied from each provider's own documentation. A provider that gives you an include unique to your account, or that authenticates with a CNAME instead of a TXT include, is not in the list. Paste a domain you were given into custom include domains.

• Google Workspace. include:_spf.google.com. Provider documentation.
• Microsoft 365. include:spf.protection.outlook.com. Provider documentation.
• Microsoft 365 GCC High and DoD. include:spf.protection.office365.us. Provider documentation.
• Microsoft 365 operated by 21Vianet. include:spf.protection.partner.outlook.cn. Provider documentation.
• Amazon SES custom MAIL FROM. include:amazonses.com. Provider documentation.
• Twilio SendGrid. include:sendgrid.net. Provider documentation.
• Mailgun. include:mailgun.org. Provider documentation.
• Postmark. include:spf.mtasv.net. Provider documentation.
• Zoho Mail. include:zohomail.com. Provider documentation.
• Zoho, several services. include:one.zoho.com. Provider documentation.
• Salesforce. include:_spf.salesforce.com. Provider documentation.
• Zendesk. include:mail.zendesk.com. Provider documentation.
• Proton Mail. include:_spf.protonmail.ch. Provider documentation.
• Cloudflare Email. include:_spf.mx.cloudflare.net. Provider documentation.
• Shopify email forwarding. include:_spf.hostedemail.com. Provider documentation.

Google's setup guide says an SPF record can have up to 10 include tags, and it recommends ~all. The rule receivers implement is the one in RFC 7208 section 4.6.4: 10 DNS-lookup terms in the whole check, not 10 include tags on the first record. Microsoft recommends -all for Microsoft 365 domains because Microsoft also recommends DKIM and DMARC, and Microsoft says the DMARC policy is effectively ignored for an SPF softfail when the message has no DKIM signature. Microsoft says ?all is for testing.

The mechanism rules on this page are from RFC 7208. The include values are from the provider pages linked above.

After the TXT record is live, use the email DNS checker to read the SPF record receivers will see. To publish a policy for mail that fails SPF or DKIM alignment with the From domain, use the DMARC record generator.