SPF with multiple includes: how many one record can hold

You've got Google Workspace for staff mail, a marketing platform, a helpdesk and an invoicing tool, and each one has handed you an include: to add. You can add as many as you like, because SPF's limit is on DNS lookups. The whole evaluation gets ten, and each include: uses at least one. The provider that published it decides how many more.

How many includes can one record have? As many as fit inside ten DNS lookups. Four is often fine and sometimes too many, because somebody else sets the cost of each.

What an include costs

An include: costs one lookup to fetch the target's record, plus whatever the provider puts inside it. Providers nest their own includes in there, and they change them without telling you. Two records that look the same in your DNS panel can cost very different amounts:

That's how a record that passed on Monday returns permerror on Friday with nobody having touched it. A provider added an include to their own record, your total crossed ten, and every sender in your record lost its pass at once.

The SPF checker resolves the whole chain of a published record and gives you the real count. The pre-flight does the same for a record you haven't published yet, which is the one you want when you're about to add the fourth include.

Adding an include

The new term goes inside the existing record. A second v=spf1 record breaks both, and the multiple SPF records guide covers why.

Before:

After:

Keep all at the end. Receivers stop at the first match and all matches everything, so the receiver never reads an include placed after it. The record is still valid and every other sender still passes, so you'd only find out from that one sender's reports.

Ways to get under the limit

Work through these in order, starting with the one that leaves you the least upkeep.

Remove what isn't sending. Records collect includes for platforms that were trialed once and canceled, and each one still costs a lookup. Your DMARC aggregate reports show which includes covered real mail last month and which covered none.

Replace an include with the addresses behind it. A provider that sends from a small fixed range usually documents it, and ip4: terms cost nothing. The ranges are now yours to maintain, though. When the provider renumbers, your record is wrong and you'll find out from a bounce.

Move a bulk sender to its own subdomain. Send marketing from mail.example.com with its own SPF record and its own ten lookups. Your main domain keeps staff mail and gets its budget back. Mail from the subdomain aligns to the subdomain, which DMARC accepts under relaxed alignment.

Flatten the record. Resolve every include down to addresses and publish those. You'll be well under the limit, and every future change is now somebody's job, because a flattened record goes stale the day a provider renumbers. The 10-lookup limit guide compares these in more detail.

Counting your lookups

Every option above changes the record, and a record over the limit fails every sender in it, the ones you didn't touch included. Paste the new record into the pre-flight. It resolves the whole chain against live DNS, gives you the lookup count, and lists any sender that would stop passing.

The count only holds for the day you check it. Your includes belong to other people, and they change them on their own schedule. We read your DMARC reports and send you a weekly digest that lists the sources that failed. On a paid plan, we also email you the day a sender that was passing starts failing. That's how you hear about somebody else's edit before your customers do.