Mailgun SPF: setting up include:mailgun.org without breaking the lookup limit

Mailgun is one of the providers whose current documentation still asks for an SPF include. Its domain verification guide lists v=spf1 include:mailgun.org ~all as a required TXT record. Where that record goes, and how many DNS lookups it costs, both matter more than the guide makes obvious.

What Mailgun's verification guide asks for

Mailgun's user manual lists four records for a custom sending domain:

The exact host names for each record appear in the Mailgun control panel for the domain. Mailgun says verified domains aren't subject to the 300-messages-a-day limit that applies otherwise. Verification also drops the "sent via Mailgun.org" notice and builds reputation on the client's own domain.

Mailgun also notes that the control panel can show several DKIM keys, some marked Unverified, after key rotation or after automatic sender security is turned on. Not every key needs to verify. Only the one the domain is actually configured to sign with has to.

The domain you add to Mailgun decides where the SPF record goes

Mailgun's records go on whatever domain you add in Mailgun. That choice matters for MSPs:

• If you add the apex (client.com), the SPF TXT record goes on the apex, which already holds the client's main SPF record. You merge include:mailgun.org into that one record. You don't add a second one. The MX records would also replace the apex's inbound mail routing, so for a domain whose mail is hosted on Microsoft 365 or Google Workspace, adding the apex is usually the wrong choice.
• If you add a subdomain (mg.client.com), all four records live on that subdomain. Its SPF record is separate from the apex's, the MX records only affect that subdomain, and the apex lookup count doesn't change.

For a client whose mailboxes are on Microsoft 365 or Google, a dedicated subdomain is the cleaner pattern. Mailgun's verification guide doesn't prescribe it, so confirm with the client's developer which domain the application actually sends from before you publish anything.

Lookup cost: more than one

On Oct 13, 2026, a live DNS check showed this include tree:

• mailgun.org → include:_spf.mailgun.org include:_spf.eu.mailgun.org -all
• _spf.mailgun.org → include:_spf1.mailgun.org include:_spf2.mailgun.org ~all
• _spf1, _spf2 and _spf.eu → ip4 ranges only

So include:mailgun.org costs five of the ten lookups RFC 7208 §4.6.4 allows: the include itself plus four nested ones. On a dedicated subdomain that's fine. Merged into an apex record that already has Microsoft 365, a CRM and a marketing tool, it can push the record past ten, and every sender on the domain then gets a permerror. This is a DNS observation, not something Mailgun documents. Re-check it, because the provider can change its records.

Merging into an existing record

If Mailgun has to go on a domain that already sends through Microsoft 365, keep one record and add the include before the all term:

```

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

```

Keep the client's existing -all or ~all ending. Mailgun's ~all only applies when Mailgun's record is the whole record. The same live check showed that include:mailgun.org already pulls in _spf.eu.mailgun.org, so one include covers mail sent from either Mailgun region. Don't add the regional hosts separately. If you do, they'll be counted twice.

How Mailgun mail aligns for DMARC

Under RFC 9989, DMARC passes when SPF or DKIM passes and the authenticated domain aligns with the From: domain.

• DKIM: Mailgun signs with the key you published for the sending domain. If the From: address is billing@client.com and the sending domain is mg.client.com, the signing domain shares the Organizational Domain client.com, so it aligns under relaxed alignment (the default).
• SPF: SPF evaluates the envelope sender. If that's on the Mailgun sending domain, a subdomain like mg.client.com aligns with client.com under relaxed alignment, but not if the DMARC record sets aspf=s. Mailgun's verification page doesn't state the envelope domain format, so confirm it from a test message's Return-Path header.

Aligned DKIM is the one to rely on. RFC 9989 says a domain at p=reject must not rely solely on SPF for a DMARC pass, and must apply valid DKIM signatures.

A client checklist

• Find out which domain is configured in Mailgun: the apex or a subdomain.
• Publish all four records on that domain, using the host names from the control panel.
• If it's the apex, merge the include into the existing SPF record and recount the lookups.
• Send a test message and check the Authentication-Results header for dkim=pass with the client's domain, plus the Return-Path domain.
• Make sure the client's DMARC record isn't strict (aspf=s or adkim=s) unless the domains are identical.
• Wait for DNS to propagate. Mailgun's guide says it can take 24 to 48 hours. Then click Verify DNS settings or let Mailgun check automatically.

Check the client's SPF now

Run the free SPF checker →

It walks the full include tree, counts every nested lookup against the RFC 7208 limit of 10, names common senders such as Mailgun, and flags duplicate records and +all or ?all endings.

Founding Partner: $1,999, one time. Spot the client domains where one more vendor include tips SPF into permerror, before mail starts bouncing. Founding Partner covers 50 client domains with full branding (logo and colors), weekly rescans and change alerts, unlimited Security Briefs (150 prospect scans a month), the Grow toolkit, the Policy library, a branded service menu, webhooks, the API, and MCP access (except quote drafts). If you later subscribe to Pro, you pay $299/mo instead of $399 for as long as that Pro subscription stays active. The offer is capped at 50 seats and closes on Dec 15, 2026, or when all 50 seats are claimed, whichever comes first. Proposals and the Service Library require Pro. Founding Partner is non-refundable, except that you're refunded if the seats run out before your payment can be fulfilled.

See Founding Partner details →