SPF Record Generator

SPF (Sender Policy Framework) is a TXT record on your domain that lists the servers allowed to send email for it. A receiving server looks at the address in the envelope of each message, the return-path (also called MAIL FROM), fetches the SPF record of that domain and checks whether the sending server's IP address is on the list. That return-path is often, but not always, the domain people see in the From line: many newsletter and transactional services send with a return-path on their own domain.

A record is one line of text that starts with v=spf1 and ends with an instruction for every server that is not on the list:

v=spf1 ip4:192.0.2.10 include:_spf.google.com ~all

This SPF generator writes that line for you. Each email service you select becomes the include: value from that provider's own documentation; IP addresses become ip4: and ip6: terms; your own web or mail servers become a and mx. Terms that cost no DNS lookups come first. Duplicates and addresses already covered by a wider network are left out, and the page says which.

Then the record is checked the way a receiver will read it: the ending must not let every server on the internet send as you, IP addresses must be written correctly, and the whole record must stay within the 10 DNS lookups a receiver will make. The result tells you in plain words what is fine, what to look at, and what would break SPF.

With JavaScript on, nothing you type leaves your browser: the generator makes no DNS lookups and sends nothing to our server, which is why the cost of an include we do not know yet shows as “could not check” instead of a guess (see the lookup limit). The one exception is the Count lookups now button, which appears only once our SPF checker is live, and only for includes we have not measured: pressing it sends those include names, one check per name, and nothing else you typed, to that checker. Without JavaScript, the Generate SPF record button sends the form to our server once; the record is built there from your fields and the page comes back with it. We do not store what you typed (privacy policy).

The panel above the record is the verdict of the record you are about to publish: a colored icon and a short label. Pass means it follows every rule we check. Warning means it works but something needs your attention. Fail means no working record can be built from this input, so none is shown. Could not check means the record is built, but part of it depends on something only live DNS can answer. It is neither a pass nor a fail.

The limit of 10 DNS lookups

A receiver may make at most 10 DNS lookups while it evaluates your SPF record. Every include:, a, mx, ptr, exists and redirect= costs one, and so does every such term inside the records you include. Above 10, the receiver stops with an error (a “permerror”) and your mail no longer passes SPF (RFC 7208 §4.6.4). ip4:, ip6: and all cost nothing.

We count the terms of your record exactly. For the providers in the list we add what their own include costs, measured on 22 September 2026: for example _spf.google.com costs 1 lookup in total and mailgun.org 5. Providers change their records, so treat the total as an estimate and check the published record.

• Pass: 8 lookups or fewer. Warning: 9 or 10, which leaves almost no room for the next service you add. Fail: more than 10; remove includes you no longer use, or move a sending service to a subdomain with its own SPF record.
• Could not check: you added an include we have not measured. Its cost is only known by looking up its record in live DNS, and this page does not do that on its own. We never count it as zero. Once our SPF checker is live, a Count lookups now button appears in the result and asks it to look the include up; until then, check the published record with our Domain health check, which counts its DNS lookups.

The mx term and the limit of 10 mail servers

With mx in the record, receivers look up your MX records and then the address of each mail server. RFC 7208 §4.6.4 allows at most 10 mail servers per mx term; with more, SPF ends in an error. This depends on your live MX records, so the generator only reminds you of it. If you do not send outgoing mail from your incoming mail servers, leave mx out: it costs a lookup for nothing.

How the record ends: ~all, -all or ?all

The last term says what happens to mail from servers that are not listed. ~all (soft fail) asks receivers to treat such mail as suspicious without rejecting it on SPF alone (RFC 7208 §8.5). -all (fail) asks them to reject it. Some receivers check SPF before DMARC, so with -all they may reject a message that your DKIM signature would have let pass DMARC, for example a forwarded one (RFC 9989 §7.1). ?all (neutral) gives no instruction and counts as if you had no SPF record (RFC 7208 §8.2), so we show a warning for it.

We never generate +all or a bare all: both let every server on the internet pass SPF as your domain (RFC 7208 Appendix A.1). Any other ending is not valid SPF and is refused.

IP addresses and networks

Write IPv4 addresses as four numbers without leading zeros (192.0.2.10) and networks with a prefix length (192.0.2.0/24); IPv6 in the usual form (2001:db8::10, 2001:db8::/48). An address in the wrong list, a leading zero or a prefix longer than 32 (IPv4) or 128 (IPv6) is refused.

• Host bits set: 192.0.2.7/24 authorizes the whole network 192.0.2.0/24, not just one server. If you meant one server, drop the /24.
• Very large network: a network wider than /16 (IPv4) or /48 (IPv6) is shown as a warning. Make sure every address in it is yours; anyone else there could send mail as you.
• Not public address space: private ranges such as 10.0.0.0/8 or 192.168.0.0/16, loopback and documentation ranges never appear as the sender of internet mail, so listing them does nothing. Enter the public address your mail leaves from.

Networks that cover the whole internet

A network such as 0.0.0.0/0, or several networks that together cover every address mail can come from, work exactly like +all: every server passes. The generator refuses them. It also refuses networks that cover half or more of all public addresses, because no organization's mail servers need that many and it would let almost anyone send as you.

Providers and custom includes

Each provider in the list adds the include value from its own documentation. Some providers need no include in this record at all, and the result says so:

• Services such as SendGrid and Amazon SES send with a return-path on their own domain or on a subdomain you set up for them, so SPF is checked there, not against this record. If you add their include anyway, we keep it but warn: it costs lookups for nothing.
• Mailgun's include belongs in the SPF record of the domain you added to Mailgun, which is often a subdomain such as mg.example.com.
• Zoho: the Zoho Mail entry adds include:zohomail.com, the value Zoho documents. The value can depend on your organization's data center, so check the SPF value in your Zoho admin console.
• A provider whose value we could not confirm in its documentation is marked with a warning.

A custom include must be a domain name. An include of your own domain would make the record include itself until the lookup limit ends it in an error, so it is refused.

Your own servers: a and mx

a authorizes the addresses your domain's A and AAAA records point to, and mx your incoming mail servers. Select them only if those servers really send mail. Other host names are written as a:mail.example.com; each costs one lookup. A host name must be a valid domain name.

A record that lists no servers

With nothing selected, the record is just v=spf1 -all, v=spf1 ~all or v=spf1 ?all. For a domain that sends no email at all, v=spf1 -all is the recommended record (RFC 7208 §10.1.2) and shows as a pass. The other two endings give such a domain little protection, so they show a warning.

Entries we left out

The same include twice, an address listed twice, or an address inside a network you also listed is left out of the record. The result lists each one and the entry that already covers it.

Record length and input size

RFC 7208 §3.4 advises keeping the domain name and all its TXT records together under 450 characters so the DNS answer fits in one small packet; other TXT records at the same name, such as site verifications, use up the same room. We can measure only this record: when the name and this record go over 450, we show a warning. A record too big for any DNS answer, or a list of more than 1,000 entries, is refused. Long records are split into strings of up to 255 characters inside one TXT record, and receivers join them without spaces (§3.3).

The domain name

Enter the domain the record is for, such as example.com or mg.example.com, without https:// or an email address. International domain names are converted to the ASCII form DNS uses.

1. List every service that sends mail with your domain: your mailbox provider, newsletter tool, CRM, help desk, website and billing system. A service you forget will fail SPF.
2. Generate the record above and read the verdict.
3. Publish it as one TXT record at the domain itself (host @ in most DNS dashboards), at the DNS provider your domain's NS records point to.
4. Replace, do not add. If a record starting with v=spf1 already exists, edit it into the new one. Two SPF records make every SPF check end in an error (RFC 7208 §3.2, §4.5).
5. Check the published record with a TXT record lookup once your DNS provider has saved it.

Google Workspace

Google's documented record is v=spf1 include:_spf.google.com ~all. Select Google Workspace above; if other services also send your mail, select them too so everything ends up in one record.

Microsoft 365

Microsoft 365 uses include:spf.protection.outlook.com. Other Microsoft clouds use their own value: spf.protection.office365.us for GCC High and DoD, and spf.protection.partner.outlook.cn for Microsoft 365 operated by 21Vianet. Each is a separate entry in the list above.

Zoho Mail

Zoho documents v=spf1 include:zohomail.com -all, and include:one.zoho.com when you send through several Zoho services. Check the SPF value in your Zoho admin console: it can depend on your organization's data center. If it shows an include other than these two, leave Zoho cleared above and enter just that include (for example include: followed by the host), not the whole record, under Other includes.

SendGrid

SendGrid's domain authentication puts SPF on its own return-path subdomain (for example em1234.example.com) through the records SendGrid gives you. Your main SPF record does not need include:sendgrid.net; set up domain authentication in SendGrid instead.

Mailgun

Mailgun asks for v=spf1 include:mailgun.org ~all on the domain you added to Mailgun. When that is a subdomain such as mg.example.com, generate the record for mg.example.com, not for your main domain. Measured on 22 September 2026, this include costs 5 of the 10 lookups.

Amazon SES

By default Amazon SES sends with a return-path on a subdomain of amazonses.com, so SPF passes without any record of yours. With a custom MAIL FROM domain, which must be a subdomain such as bounce.example.com, AWS asks you to publish v=spf1 include:amazonses.com ~all on that subdomain. Generate it for the subdomain, not for your main domain.

Cloudflare

1. In the Cloudflare dashboard, open your domain and go to the DNS Records page.
2. Select Add record, choose TXT, enter @ as the Name for the domain itself (or the subdomain part, such as mg).
3. Paste the record into Content and select Save. Cloudflare adds the quotes itself if you leave them out.

GoDaddy

1. In your Domain Portfolio, select the domain, then DNS.
2. If a TXT record with v=spf1 exists, edit it. Otherwise select Add New Record, choose TXT and enter @ as the Name.
3. Paste the record into Value and select Save.

Namecheap

1. Open Domain List, select Manage next to the domain, then the Advanced DNS tab.
2. Edit the existing SPF record, or select Add New Record, choose TXT Record and enter @ as the Host.
3. Paste the record into Value and select Save all changes.

What each part of a generated record means and what it costs against the lookup limit:

The generator never writes ptr: RFC 7208 §5.5 says it should not be used, because it is slow and unreliable. It also does not write redirect=, exists: or macros, which are for setups where one domain's policy is shared with others (redirect=) or the check depends on the sender (exists: and macros).