SPF records for common email providers

14 May 2026 · 11 min read

Most broken SPF records are not broken because the owner misunderstood the syntax. They are broken because someone added a new sending service, copied the include from a support article, pasted it into DNS next to the old one, and quietly pushed the record past a limit nobody told them about. The result is a record that looks complete, scans as valid in a casual glance, and silently fails for some receivers. Mail that used to land starts going to spam, and because SPF failures are mostly invisible without DMARC reports, nobody notices for weeks.

This guide gives you the correct, current SPF include for the providers we see most often (Google Workspace, Microsoft 365, Mailchimp, SendGrid, Amazon SES, and several more), then shows you how to combine several of them in a single record without tripping the rules that make SPF fail. The mechanics matter more than the copy-paste, so each section explains why the value is what it is, not just what to type. If you want to check your live record against any of this as you read, the free SPF checker shows you exactly what is published and counts the lookups for you.

What an SPF record actually is

SPF (Sender Policy Framework) is a single DNS TXT record on your domain that lists the servers allowed to send mail using your domain in the envelope sender (the MAIL FROM, also called the return-path). A receiver looks up that record, checks whether the connecting server is authorised, and produces a pass or fail.

A minimal record looks like this:

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

The parts that matter:

• v=spf1 must come first. It identifies the record as SPF version 1. There is no version 2 in normal use.
• Mechanisms in the middle authorise senders: include:, a, mx, ip4:, ip6:.
• The all mechanism at the end is the catch-all. -all means "fail anything not listed" (hard fail), ~all means "soft fail" (suspicious but accept), and +all means "allow everything" (never use this, it disables SPF entirely).

One domain may publish exactly one SPF record. Two TXT records that both start with v=spf1 is a hard error called PermError, and many receivers treat that as an outright fail. When you add a new provider, you edit the existing record. You do not create a second one. This single rule causes more outages than any include value ever will.

For the deeper mechanics of how SPF interacts with DMARC and alignment, see SPF explained and the SPF product page. Here we focus on the include values themselves.

The 10-lookup limit, the rule that breaks records

Before the provider list, you need the single most important constraint in SPF, because every "my record stopped working when I added a service" story traces back to it.

SPF allows a maximum of ten DNS lookups to evaluate a record. Each include:, a, mx, ptr, and exists mechanism costs at least one lookup, and an include that itself contains more includes costs all of those too, recursively. If evaluating your record requires an eleventh lookup, the result is PermError, and a PermError means SPF did not pass. Under DMARC, that often means the message fails authentication outright.

The mechanisms that do not cost a lookup are ip4:, ip6:, and all. Listing IP addresses directly is free. This is the lever you pull when you run out of lookups, and it is the basis of SPF flattening, which we come back to at the end.

A worked example of how fast you burn lookups:

• include:_spf.google.com expands to three further includes inside Google's record. That is 4 lookups for Google alone.
• include:spf.protection.outlook.com is 2 lookups.
• include:servers.mcsv.net (Mailchimp) is 1 lookup.
• include:sendgrid.net is 1 lookup.
• include:amazonses.com is 1 lookup.

Add Google, Microsoft, Mailchimp, SendGrid, and SES together and you are at nine lookups before you have added your own mx or office IP. One more service and you are over the limit. This is why the order of operations is "know your senders, then count lookups", not "paste includes until it looks right". The SPF checker reports your exact lookup count so you never have to guess.

Google Workspace (Gmail)

If you send through Google Workspace, the include is:

include:_spf.google.com

A typical Google-only record:

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

Notes that matter:

• Google publishes _spf.google.com as a nested record that itself includes _netblocks.google.com, _netblocks2.google.com, and _netblocks3.google.com. So this single include costs 4 lookups, not one. Budget accordingly.
• Do not add Google's raw IP ranges by hand. Google rotates them, and a hand-pasted block goes stale and starts failing legitimate mail. Trust the include.
• Google's own guidance uses ~all (soft fail). That is fine while you build confidence, but the destination for a locked-down domain is -all once DMARC reporting confirms every sender is covered.

For the full DMARC-on-Workspace walkthrough, see DMARC for Google Workspace.

Microsoft 365 (Exchange Online)

For Microsoft 365, the include is:

include:spf.protection.outlook.com

A Microsoft-only record:

"v=spf1 include:spf.protection.outlook.com -all"

Notes:

• This include costs 2 lookups.
• Use spf.protection.outlook.com, not any older outlook.com or regional variant you may find in stale documentation. The spf.protection.outlook.com value covers Exchange Online globally.
• If you also send from an on-premises Exchange server or a scanning appliance, add its IP with ip4: rather than another include. That keeps the lookup count down and is more reliable than chasing hostname-based mechanisms.

The Microsoft-specific DMARC and alignment details live in DMARC for Microsoft 365.

Mailchimp

Mailchimp sends transactional and campaign mail from shared infrastructure, and the include is:

include:servers.mcsv.net

Notes:

• This costs 1 lookup.
• For SPF to actually align under DMARC, Mailchimp also needs you to authenticate your domain inside their dashboard, which sets up DKIM signing with your domain. SPF alone often will not align because Mailchimp uses its own return-path. DKIM is what carries the alignment here, so do both.
• Mailchimp Transactional (formerly Mandrill) is a separate product with its own setup. Do not assume the campaign include covers transactional sending.

SendGrid (Twilio SendGrid)

SendGrid's include is:

include:sendgrid.net

Notes:

• This costs 1 lookup.
• SendGrid strongly prefers domain authentication via CNAME records that delegate a subdomain to them, which sets up aligned DKIM and a branded return-path. When you complete SendGrid's domain authentication, the CNAME-based return-path is what makes SPF align, so for many SendGrid setups the bare include:sendgrid.net is less important than completing the CNAME authentication. Set up both: the include as a backstop, and domain authentication for alignment.
• If you only use SendGrid through their automated CNAME flow, you may not need the include at all, because the delegated subdomain carries its own SPF. Check what your account requires rather than adding the include blindly.

Amazon SES

Amazon Simple Email Service uses:

include:amazonses.com

Notes:

• This costs 1 lookup.
• SES is region-agnostic for SPF purposes; the single amazonses.com include covers the sending IPs regardless of which AWS region you send from.
• SES defaults to using its own MAIL FROM domain (something under amazonses.com), which means SPF will not align with your domain out of the box. To get SPF alignment you must configure a custom MAIL FROM domain in SES (a subdomain of yours, with the MX and SPF records SES tells you to publish). Without that, rely on SES's easy-DKIM for DMARC alignment instead. This is the single most common SES misconfiguration.

More providers worth knowing

These follow the same pattern. Confirm the current value in each provider's own documentation before publishing, because vendors do occasionally change them.

• Zoho Mail: include:zoho.com (or include:zohomail.eu / regional variants depending on your data centre). 1 lookup.
• Mailgun: include:mailgun.org. 1 lookup. Like SES, configure DKIM for alignment.
• Postmark: include:spf.mtasv.net. 1 lookup.
• Brevo (formerly Sendinblue): include:spf.sendinblue.com. 1 lookup.
• Mandrill / Mailchimp Transactional: include:spf.mandrillapp.com. 1 lookup.
• HubSpot: include:_spf.hubspotemail.net if you send marketing mail through HubSpot's connected sending domain. 1 lookup.
• Salesforce (Marketing Cloud / Pardot): varies by tenant; Salesforce gives you a specific include during sender authentication. Use the value from your own account, not a generic one.
• Zendesk: include:mail.zendesk.com. 1 lookup. Required if you send support email "from" your own domain via Zendesk.
• Freshdesk: include:email.freshdesk.com. 1 lookup.
• Klaviyo: uses a dedicated sending subdomain you delegate via CNAME, so often no apex include is needed; follow their domain setup.

The recurring theme: an include authorises the sending IPs, but alignment under DMARC usually comes from DKIM, especially for any provider that uses its own return-path. Publishing the include is necessary but rarely sufficient. Always complete the provider's DKIM/domain-authentication step too, and verify it with the DKIM checker.

Combining several providers in one record

Now the real-world case: you send from Google Workspace, blast campaigns through Mailchimp, fire transactional mail through SendGrid, and run some app notifications through SES. You need all of them in one record. Here is the disciplined way to build it.

Step 1: inventory your real senders

Do not guess. The senders you forget are the ones that break when you tighten all to -all under DMARC. The most reliable inventory comes from DMARC aggregate reports, which list every server sending as you. The DMARC report analyzer turns that raw XML into a readable list. If you are not yet collecting reports, that is the first job; see DMARC RUA and RUF reports.

Step 2: write a single record, includes in order

Combine the includes into one v=spf1 record. Order does not affect correctness, but grouping by type keeps it readable:

"v=spf1 include:_spf.google.com include:servers.mcsv.net include:sendgrid.net include:amazonses.com ip4:198.51.100.25 -all"

That ip4:198.51.100.25 is the example office mail server or a scanning appliance, added directly because direct IPs cost zero lookups.

Step 3: count the lookups before you publish

For the record above:

• include:_spf.google.com: 4 lookups
• include:servers.mcsv.net: 1 lookup
• include:sendgrid.net: 1 lookup
• include:amazonses.com: 1 lookup
• ip4:198.51.100.25: 0 lookups

Total: 7 lookups. You have three to spare. Add Microsoft 365 (include:spf.protection.outlook.com, 2 lookups) and you are at nine, with one in reserve. Add one more multi-lookup include after that and you break the record. This is exactly where most records fall over.

Step 4: keep the record under 255 characters per string

A single DNS TXT string is limited to 255 characters. A long SPF record must be split into multiple quoted strings inside the same record, which the resolver concatenates:

"v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:servers.mcsv.net "
"include:sendgrid.net include:amazonses.com -all"

This is one record, two strings, fully valid. The 255-character rule is about the wire format of a single string and is separate from the 10-lookup rule. You can hit either one first, so watch both.

What to do when you run out of lookups

Sooner or later a growing business has more than ten lookups' worth of senders. You have three real options.

1. Remove senders you no longer use. The cheapest fix. Old marketing tools and abandoned helpdesks often linger in the record. Cross-check the includes against your DMARC report inventory and delete anything that has not sent in months.
2. Replace heavy includes with direct IPs. For a provider with stable, published IP ranges, you can list those ranges as ip4:/ip6: instead of include:, dropping the lookup cost to zero. The catch is maintenance: if the provider changes IPs and you do not update, mail fails. This is fine for an on-prem server with a static IP, risky for a cloud provider that rotates.
3. Flatten the record automatically. SPF flattening resolves every include to its current IP ranges and publishes those IPs directly, then keeps them fresh as providers change. This collapses many lookups into zero while staying current, so you get an unlimited number of effective senders within the limit, without the staleness risk of hand-pasted IPs.

The third option is what our hosted SPF flattening does: it watches the upstream records, keeps the flattened IP set current, and serves a record that always stays under the limit. If you would rather solve this once and stop thinking about lookup counts, that is the route. If you want to do it by hand, the discipline in steps 1 and 2 above will carry most domains a long way.

Verifying and the common failure signs

After any change, confirm the result rather than trusting the edit:

• Run the SPF checker to confirm there is exactly one record, the lookup count is ten or under, and no string exceeds 255 characters.
• Check that every sender that should be present actually resolves, and that nothing stale remains.
• Confirm alignment, not just authorisation. SPF passing is not the same as SPF aligning under DMARC. Use the DMARC checker and your aggregate reports to confirm the visible From: domain lines up. Several providers above pass SPF but only align via DKIM, so check both.

Three warning signs that mean "fix this now":

• Two v=spf1 records on the same domain. This is an immediate PermError. Merge them into one.
• PermError or "too many DNS lookups" in your DMARC reports or the checker. You are over ten lookups. Apply the section above.
• +all or a missing all at the end. +all allows the entire internet to send as you; an absent all defaults to a neutral result that protects nothing. End every record with ~all while testing and -all once you are confident.

The practical takeaway

Getting SPF right for common providers comes down to three habits. Publish exactly one record. Use the provider's official include rather than hand-pasted IPs (Google _spf.google.com, Microsoft spf.protection.outlook.com, Mailchimp servers.mcsv.net, SendGrid sendgrid.net, SES amazonses.com), and complete each provider's DKIM step so the mail actually aligns under DMARC. And count your lookups every single time you add a sender, because the eleventh one fails silently.

When the lookup count runs out, do not paste raw IP ranges and hope they stay current. Either prune dead senders or flatten the record so it stays under the limit automatically. Start by running your live domain through the free SPF checker to see your current record and lookup count, browse the wider diagnostic tools, and if you would rather hand the whole problem (SPF, DKIM, DMARC and the move to enforcement) to a service that keeps it correct as you add senders, that is what DMARC Engine is built to do.