SPF Record for Google Workspace, Microsoft 365 and Multiple Senders (10 Lookup Limit)

Most businesses send email from more than one place. Staff use Google Workspace or Microsoft 365, the website sends order confirmations, a help desk sends replies, a marketing tool sends newsletters and an application sends alerts. SPF lets you authorise all of them, but only in a single record and only within a limit of ten DNS lookups. This guide explains how to write an SPF record for Google Workspace and Microsoft 365, how to combine several senders correctly, how the ten lookup limit works, how to count your lookups, and what to do when you run out, including flattening and moving senders to subdomains.

SPF record for Google Workspace

If your staff mailboxes are on Google Workspace, Google documents the include to use. At the time of writing it is:

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

This one include already causes several nested lookups inside Google's own record, which is why you cannot add unlimited services after it. Always confirm the current value in Google's admin help, because providers can change their records. The same value appears in searches for "google spf record", "gmail spf record" and "spf record for google workspace", and the answer is the same for all of them.

SPF record for Microsoft 365

For Microsoft 365 and Exchange Online, Microsoft's documented include is:

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

Microsoft's own guidance often shows -all. If you also send from other systems, add their includes before the ending, and keep the ending you have chosen. Check Microsoft's current documentation for the exact recommendation for your setup, since tenant types and regions can differ. Our guide to Outlook and Microsoft 365 SMTP settings covers the sending side.

Combining several senders in one record

A domain may have only one SPF record. If you add a second line for each new service, receivers return a permanent error and SPF fails for everything. Instead, merge the mechanisms into one record.

Say a company uses Google Workspace, a sending service called Example Mailer and a help desk. The wrong way is three TXT records. The right way is:

v=spf1 include:_spf.google.com include:spf.examplemailer.test include:helpdesk.example.test ~all

The values above for the second and third services are placeholders. Copy the real ones from each provider. For MigoSMTP, use the include shown in your domain settings.

Order of mechanisms

Receivers evaluate mechanisms from left to right and stop at the first match. For pass results the order does not change the outcome, but putting direct IP ranges first avoids lookups for senders that match them. Always keep the all mechanism last, because anything after it is ignored.

The ten DNS lookup limit

The SPF standard says a receiver should not make more than ten DNS lookups while evaluating a record. Going beyond that ends with a permanent error, which most receivers treat as an SPF failure. This limit protects DNS servers from abuse, and it surprises many administrators because includes bring their own includes along.

What counts

• Each include:, a, mx, ptr and exists: counts as one lookup.
• A redirect= counts as one.
• The mx mechanism can trigger further address lookups for each mail exchanger; the standard limits these separately, but they add complexity.
• Lookups inside an included record count too. One include can cost several.

What does not count

• ip4: and ip6: need no lookup.
• The all mechanism needs no lookup.
• The initial fetch of your own record is not counted.

There is also a separate rule that limits the number of lookups that return nothing, called void lookups, to two. A record that points at many names that no longer exist can fail for this reason.

How to count your lookups

1. Run your domain through the SPF checker, which follows includes and reports the total.
2. Or do it by hand: fetch your record with dig +short TXT yourdomain.com, then fetch each included domain's record in the same way and add up every include, a, mx, exists, ptr and redirect you meet.
3. Write down the total, and note which includes are the most expensive.

If you are at eight or nine, you are one provider change away from a failure. Treat anything above about seven as a reason to clean up.

What to do when you run out of lookups

1. Remove what you no longer use

Old includes for services you have cancelled are the most common cause. Check each one against the tools in use today and delete the rest.

2. Replace a and mx with IP ranges

If your own servers have stable addresses, list them as ip4: and ip6:. This costs no lookups. Only do this for addresses you control and know will not change without notice.

3. Move services to subdomains

This is the cleanest fix for a long list. Send marketing mail from news.example.com, transactional mail from mail.example.com and so on. Each subdomain has its own SPF record with its own ten lookups, and the visible From address uses that subdomain. It also keeps reputations separate, which is good practice anyway; see separating transactional and marketing streams.

4. Use a flattening service with care

Flattening replaces includes with the list of IP addresses they resolve to, which removes the lookups. The danger is that providers change their addresses, so a flattened record that is not refreshed becomes wrong. If you flatten, use a service or script that refreshes automatically, and monitor the result. Do not hand-copy IP lists once and forget them.

5. Consolidate senders

If three tools can send marketing mail, choose one. Fewer senders mean fewer includes, simpler troubleshooting and a more consistent reputation.

Other multi-sender mistakes

• Copying an include you do not understand. Some third-party instructions add a broad include that you never needed.
• Using ptr. It is slow, unreliable and discouraged by the standard.
• Adding +all to make failures stop. It authorises everyone and defeats the purpose.
• Forgetting parked domains. Domains you own but never send from should publish v=spf1 -all.
• Forgetting subdomains. A service that sends as support.example.com needs SPF for that name, or the subdomain should be covered by your overall policy.

A worked example of cleaning up a record

Imagine a company whose record has grown over several years to include its mailbox provider, two newsletter tools it has since stopped using, an old help desk, a CRM and a web server listed with the a mechanism. The checker reports twelve lookups. The cleanup takes four steps. First, confirm with the team which tools are still live and delete the two retired newsletter tools and the old help desk. Second, replace the a mechanism with the web server's fixed IP address. Third, move the CRM's bulk mail to a subdomain with its own record. Fourth, rerun the checker and confirm that the total is comfortably under ten. Write down the date and the reason for each change, so the next administrator understands why the record looks the way it does.

Checking the result

After any change, check three things. First, there is exactly one record. Second, the lookup count is comfortably under ten. Third, mail from each sender passes: send a test message from each system to a mailbox you control, and read the authentication results in the headers. See how to read email headers. If one system shows a failure, compare the connecting IP with your record.

For the underlying syntax, start with SPF record explained. For the broader picture, see authenticating your sending domain and the deliverability overview.

References and further reading

• RFC 7208: Sender Policy Framework (SPF), section 4.6.4 DNS lookup limits
• Google Workspace Admin Help: Set up SPF
• Microsoft Learn: Set up SPF in Microsoft 365