SPF.Guru

When one vendor uses up all your SPF lookups

Some platforms publish SPF records that cost five or six DNS lookups on their own. Add two of those to Microsoft 365 or Google Workspace and you are over the ten lookup limit without having done anything unreasonable.

Why a single vendor can be so expensive

Large senders operate a lot of infrastructure, often across several regions and acquisitions. Their SPF record is rarely a flat list of addresses; it is usually a set of nested include: statements, and every one of those counts against your limit, not theirs.

Mailgun's include:mailgun.org and Freshdesk's include:email.freshdesk.com are the two most commonly cited, and each can consume five or more by itself. Others worth checking before you blame your own record:

There is a targeted fix for exactly this: SPF Guru can take over one vendor's lookups and leave the rest of your record alone. That is option three below. First, work out which vendor is actually costing you.

A record this short can already be over the limit:

v=spf1 include:mailgun.org include:email.freshdesk.com
       include:_spf.google.com ~all

Find out which vendor is responsible

Guessing is a waste of an afternoon. The include tree expands your record and shows what each branch costs, so you can see at a glance whether one vendor is responsible or the cost is spread evenly.

What to do about it

In order of preference:

1. Remove what you no longer send from

The cheapest fix is deleting an include for a platform you stopped using two years ago. This is more often the answer than people expect.

2. Move that vendor to a subdomain

If the vendor will send as support.example.com or marketing.example.com, give it its own record on that subdomain. Its lookups then come out of that subdomain's budget instead of your root domain's, and the problem is permanently solved with no dependency on anyone else.

This is the right answer whenever the vendor allows it, and many do.

3. Offload just that vendor to SPF Guru

If one vendor is responsible for most of the cost, you can hand SPF Guru that vendor alone and leave the rest of your record untouched. Append ._i.%{ir}.my.spf.guru to the vendor's domain inside the existing include:.

So instead of:

include:email.freshdesk.com

publish:

include:email.freshdesk.com._i.%{ir}.my.spf.guru

SPF Guru resolves that vendor's record, nested includes and all, and answers with a single result. Whatever it cost you before, it now costs one lookup.

The same pattern works for any vendor that publishes an SPF record:

include:mailgun.org._i.%{ir}.my.spf.guru
include:mail.zendesk.com._i.%{ir}.my.spf.guru
include:spf.hubspotemail.net._i.%{ir}.my.spf.guru

Applied to the record above, offloading Freshdesk alone is enough:

v=spf1 include:mailgun.org
       include:email.freshdesk.com._i.%{ir}.my.spf.guru
       include:_spf.google.com ~all

Why this one is safe to drop in

An include: only matches when it passes. If the sending IP is not in that vendor's record, this include simply does not match and evaluation carries on to your next mechanism exactly as it did before. Nothing else in your record changes behaviour, and there is no second arm to add.

That is the opposite of the whole-record option below, which deliberately moves your all up behind the guru include so that evaluation always terminates on one of them.

4. Hand the whole record to SPF Guru

If several vendors are expensive, or you would rather not think about the limit again, a single guru include at the front of your record brings a receiving server down to one lookup regardless of how much sits behind it. Check your domain to generate the exact record, and see how it works for the mechanics.

Do not delete mechanisms in either case. With the per-vendor form you are rewriting one include, not removing it. With the whole-record form the trailing mechanisms are exactly what SPF Guru evaluates on your behalf. Either way, a shorter record authorises less, not more.

What this does not fix

None of this makes a vendor's record cheaper for anyone else, and none of it helps if the vendor's record is simply broken. If a vendor include is causing void lookups, that is a fault at their end worth raising with them.

Check where you stand

Enter your domain to see the real lookup count, or use the SPF checker to confirm whether a specific sending server passes today.