SPF Record Generator

Our SPF record generator builds one valid Sender Policy Framework record from the services and servers that send email as your domain. Search the provider list, tick the platforms you use, add any IP addresses or extra includes, and choose how strictly unlisted senders should be treated. The record updates as you go, with a running count against the 10-lookup limit, warnings for duplicates and records over 255 characters, and a live check that expands every include over DNS before you publish.

How to use the SPF generator

1. 1 Tick the services that send for youSearch the list and tick each mailbox, marketing, helpdesk or CRM platform that sends as your domain. Providers whose own docs say no root include is needed are marked, and the generator explains why instead of adding a value.
2. 2 Add your own servers if neededTick a or mx only if your web or mail server sends mail directly, and enter any IPv4 or IPv6 addresses or ranges you control. Paste any other includes from a provider's setup guide in step 3.
3. 3 Choose the all qualifierPick ~all (soft fail) while you confirm every sender, then switch to -all (hard fail) once you are sure nothing is missing.
4. 4 Check the lookup countWatch the counter and warnings, then use Check live lookup count to see the real total once every nested include is followed.
5. 5 Publish and testCopy the record into a TXT record at host @, replacing any existing v=spf1 record, then run the SPF Checker on your domain once the change has propagated.

What an SPF record generator does for you

An SPF record is a single line of text, but the rules around it are strict. RFC 7208 allows only one v=spf1 record per domain, expects mechanisms separated by single spaces, limits evaluation to ten DNS lookups and puts the all mechanism last. One slip, such as a second record, a stray comma or a typo in an include, turns the result into a PermError, and receivers then treat your legitimate mail as unauthenticated.

A good SPF generator removes most of that risk. This one always starts with v=spf1, adds the ip4:, ip6: and include: prefixes for you (or strips them if you paste them twice), removes duplicate mechanisms and tells you it did, refuses invalid addresses and domains, and always places your qualifier at the end. It never generates ptr, which RFC 7208 says not to use, and it never offers +all, which would let every server on the internet send as you.

Where the provider values come from

Every include in the provider list is taken from that provider's own documentation, and each entry links to its source. Where we could not confirm a value from the provider itself, it is left out rather than guessed. That matters because a misspelt include points at a domain with no SPF record, which RFC 7208 treats as a PermError for your whole record.

Some well-known platforms are listed with no include at all. Mailchimp, Mailchimp Transactional, SendGrid, Amazon SES, Postmark, Klaviyo, Constant Contact, Shopify store email, Squarespace Email Campaigns and Brevo on shared IPs all send with their own return-path (envelope) domain, or one you point at them with a CNAME. Receivers check SPF on that domain, not on your root, so adding an include there wastes a lookup and changes nothing. DMARC alignment for these services comes from DKIM, so publish the DKIM records they give you instead.

A few providers have variants. Microsoft 365 uses a different include for GCC High and DoD tenants and for the service operated by 21Vianet. Brevo needs spf.brevo.com only on a dedicated IP. HubSpot gives each account its own include, shown in its domain settings, so the generator asks you to paste it rather than inventing one.

How the SPF generator counts DNS lookups

Receivers stop evaluating an SPF record after ten DNS lookups and return a PermError, which DMARC treats as a fail. Each include, a and mx mechanism costs one lookup, and so does every include nested inside a provider's record. The ip4, ip6 and all mechanisms cost nothing.

While you build, the counter adds one lookup for each a and mx and at least one for each include, and labels the total "at least" whenever an include is present. Providers rarely publish how many lookups their includes use, and they can change them at any time, so a fixed number would be a guess. To see the real figure, press Check live lookup count: the tool follows every include in your generated record over DNS, exactly as a receiver would, and shows the cost of each one, before anything is published. The SPF Checker does the same for the record that is already live.

If you are over the limit, remove services you no longer use first. Then consider replacing a and mx with the specific ip4 addresses they resolve to if those rarely change, using a provider's narrower regional include where it documents one, or moving bulk and marketing mail to a subdomain with its own SPF record.

Choosing between ~all and -all

The final mechanism tells receivers what to do with mail from servers that are not in your list. This SPF record generator offers the two settings worth publishing.

• ~all, soft fail: unlisted servers are marked as suspicious but usually still accepted. The safest place to start while you confirm every service that sends for you.
• -all, hard fail: unlisted servers should be rejected. The strongest setting once you are confident the list is complete, and the right one for domains that never send email (v=spf1 -all on its own).
• +all is never offered because it passes every server on the internet, and ?all is left out because it offers no protection at all.

Long records and the 255-character limit

A single string inside a DNS TXT record can hold at most 255 characters. A record with many includes can pass that, and the generator warns you as soon as it does. Most DNS panels split long values automatically, so try pasting the full record first.

If your panel rejects it, copy the split version the generator shows. It breaks the record into quoted strings at spaces, such as "v=spf1 include:a.example ... " "include:b.example ~all", all inside the same TXT record. Receivers join the strings back together without adding anything between them, so each string except the last keeps its trailing space; without it, two mechanisms would run together and break the record. Very long records, above roughly 450 characters, can also outgrow a single DNS response, which is another reason to keep the list short.

Publishing the record and testing it

Before you publish, check whether the domain already has a v=spf1 record. If it does, edit that record rather than adding another, and make sure anything it contained that you still need is in the generated version. Two SPF records cause a PermError for every message, which is one of the most common causes of sudden delivery problems after a new service is set up.

Publish the record wherever your domain's nameservers point, which may be your registrar, your web host or a DNS service rather than your email provider. Add or edit a TXT record with the host @ (some panels want the host left blank for the root domain), paste the record as the value and save. A subdomain that sends its own mail, such as news.example.com, needs its own record, because subdomains do not inherit the root domain's SPF.

Allow time for the old record's TTL to expire, then run the SPF Checker on the domain. It reads the live record, expands every include and reports the lookup count, void lookups and any syntax problems, so you can confirm that what is published matches what you built.

SPF best practice for any domain

Gmail and Yahoo require senders to pass SPF or DKIM, and bulk senders to have both plus a DMARC record with alignment. Microsoft applies comparable requirements to high-volume senders to Outlook.com addresses. For most organisations, a correct SPF record built with an SPF generator, DKIM switched on with every provider and a DMARC record starting at p=none meet these rules wherever in the world you send from.

Review the record whenever you add or retire a tool that sends email, and keep a note of why each include is there. Months later, nobody remembers which include belonged to a trial CRM, and unused includes waste lookups. Domains you own but never send from should publish v=spf1 -all, plus a DMARC reject policy, so nobody can use them to impersonate you.

Examples you can copy

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

v=spf1 ip4:198.51.100.25 include:spf.protection.outlook.com include:mail.zendesk.com -all

v=spf1 a ip6:2001:db8::/32 include:zohomail.com ~all

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

v=spf1 -all

"v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:mailgun.org " "include:mail.zendesk.com include:_spf.salesforce.com -all"

Common mistakes to avoid

Frequently asked questions