An SPF record lists every server allowed to send email for your domain. It is one TXT record, and it has strict rules: one record per domain, a single all at the end and no more than 10 DNS lookups. Getting those rules right by hand is fiddly, especially when you use several tools.
This generator builds the record for you. Choose your services, add any IPs and see the lookup count update in real time, because it resolves each include as you add it.
How to use the generator
- Pick your services. Tick every platform that sends mail as your domain.
- Add your own infrastructure. Include
mxif your MX servers also send,aif your web server sends (for example, contact form notifications), and any fixed IPv4 or IPv6 addresses. - Add custom includes. For services not in the list, paste the include value from their documentation.
- Choose the all qualifier.
~allfor most domains,-allif you are confident the list is complete. - Check the lookup count. Stay at 10 or below, ideally with a couple to spare.
- Copy and publish. Add the record as a TXT on your root domain.
Services and their SPF includes
The generator knows the standard values for these providers. Always compare with the provider’s current documentation, since values do change.
| Service | Typical include | Notes |
|---|---|---|
| Google Workspace | include:_spf.google.com |
Costs several lookups because of nested includes |
| Microsoft 365 | include:spf.protection.outlook.com |
Covers Exchange Online outbound |
| SendPulse | include:mxsmtp.sendpulse.com |
Covers campaigns and SMTP |
| Brevo | include:spf.brevo.com |
Older setups may show spf.sendinblue.com |
| Mailchimp | include:servers.mcsv.net |
Mailchimp uses its own Return-Path by default, so this is often optional |
| SendGrid | include:sendgrid.net |
Needed with a branded Return-Path |
| Amazon SES | include:amazonses.com |
Only relevant with a custom MAIL FROM domain |
| Mailgun | include:mailgun.org |
Region-specific setups may differ |
| Postmark | include:spf.mtasv.net |
Applies to a custom Return-Path domain |
| Zoho Mail | include:zohomail.com |
EU and other regions use regional variants |
| HubSpot | Account-specific, like include:1234567.spf01.hubspotemail.net |
Copy it from HubSpot’s domain settings |
| Zendesk | include:mail.zendesk.com |
For support email sent from your domain |
If you send through an ESP not listed here, copy the SPF value from its domain authentication page into the custom include field.
The 10-lookup budget
Receivers stop evaluating SPF after 10 DNS lookups and return a permanent error. That fails SPF for every message, not just the ones from the last service you added.
| Mechanism | Lookup cost |
|---|---|
include: |
1, plus whatever it contains |
a, mx |
1 each |
exists:, redirect= |
1 each |
ptr |
1 or more (avoid) |
ip4:, ip6:, all |
0 |
The generator shows the resolved total. If it goes past 10, try these before anything drastic:
- Remove services you no longer use.
- Replace
aandmxwith the fixedip4addresses they point to. - Move marketing or transactional mail onto a subdomain with its own SPF record.
- Drop includes for ESPs that use their own Return-Path.
Soft fail or hard fail
The final mechanism decides what happens to mail from servers you did not list.
| Ending | Result | When to use |
|---|---|---|
~all |
Softfail: accept but treat as suspicious | Default for most domains, especially while rolling out DMARC |
-all |
Fail: tell receivers to reject | Complete, stable sender list with DMARC enforcing |
?all |
Neutral: no opinion | Not recommended, offers no protection |
+all |
Pass for everyone | Never use |
In practice, once DMARC is at p=reject, the DMARC policy drives enforcement and the choice between ~all and -all matters less. Softfail also avoids some forwarding problems.
Example records
Google Workspace plus one ESP:
v=spf1 include:_spf.google.com include:spf.brevo.com ~allMicrosoft 365, a help desk and a fixed server IP:
v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com include:mail.zendesk.com ~allA domain that should never send mail:
v=spf1 -allWhy a generated record can still fail
A syntactically perfect record can still produce SPF failures in real mail. The usual reasons:
- A sender is missing. The most common cause. Check a few weeks of DMARC aggregate reports for sources you did not know about, such as an invoicing tool or a web form plugin.
- The Return-Path is not your domain. SPF is checked against the envelope sender. If your ESP uses its own bounce domain, your record is never consulted for that mail.
- Forwarding. When a recipient forwards your message, the forwarding server’s IP is not in your record, so SPF fails. DKIM usually survives, which is why DMARC accepts either.
- The old record is still cached. Wait for the previous TTL to expire before judging the new one.
- A provider changed its include. Brevo’s move from
spf.sendinblue.comtospf.brevo.comis one example. Old values usually keep working for a while, then stop.
Publishing the record
In your DNS provider, create a record with:
- Type: TXT
- Host / Name:
@(or blank) for the root domain, or the subdomain name - Value: the generated record, without extra quotes unless your panel requires them
- TTL: 3600 is fine; use 300 while testing
If an SPF record already exists, replace it rather than adding a second one. Two v=spf1 records cause a PermError.
After publishing, wait a few minutes and verify the live record with the SPF checker, which also shows the include tree. Then set up signing with the DKIM checker and a policy with the DMARC generator. The email authentication guide explains how the three records work together.