What is the best free SPF record generator?

SPF generators are helpful when you are setting up a mail-sending domain from scratch, migrating between ESPs, or troubleshooting an SPF record that has grown too complex. The useful output of a generator is not just a valid-looking string — it is a syntactically correct record that stays under 10 DNS lookups, matches the exact senders your domain actually uses, and uses the right fail policy for your risk tolerance. Most online generators do the easy part and skip the hard part. This guide covers how to generate and validate an SPF record correctly in 2026.

What a good SPF generator actually needs to do

A useful SPF generator handles more than string concatenation:

1. Sender picker — a catalogue of the common ESPs, CRMs, and mail platforms with their correct include: or IP directive. Copy-pasting from vendor docs is error-prone.
2. DNS lookup counter — every include: chain is resolved to count the real total, not just the visible include: count.
3. Alignment hint — flags include: targets whose default envelope sender breaks DMARC alignment, so you know DKIM signing is required for DMARC pass.
4. Fail policy selector — chooses between ~all (softfail, safe default) and -all (hardfail, strict).
5. Multiple SPF record detection — warns if the domain already has an SPF record.
6. Length check — keeps the record under 450 characters for best resolver compatibility.
7. Propagation and verification — runs a live DNS check after publishing.

IntoDNS.ai performs steps 2-7 as part of its scan, which is why we recommend using a generator to build the record and then validating with IntoDNS.ai before relying on it in production.

Building an SPF record manually (recommended)

Most domains do not need a generator. The SPF syntax is simple enough to write by hand, and doing so forces you to inventory your senders properly. Here is a template with the most common sender directives:

v=spf1
  ip4:YOUR.STATIC.IP.HERE
  include:_spf.google.com            (Google Workspace)
  include:spf.protection.outlook.com (Microsoft 365)
  include:mailgun.org                (Mailgun)
  include:sendgrid.net               (SendGrid)
  include:amazonses.com              (Amazon SES)
  include:servers.mcsv.net           (Mailchimp)
  include:spf.mtasv.net              (Postmark)
  include:_spf.hubspotemail.net      (HubSpot)
  include:mail.zendesk.com           (Zendesk)
  ~all

You will not use all of these — strip to the ones you actually use. Stacking more than 6-7 include: directives typically pushes you past the 10 DNS lookup limit.

A realistic record for a small domain:

v=spf1 ip4:185.71.60.245 include:_spf.google.com include:mailgun.org ~all

For a domain that does not send any mail at all (including a parked or subdomain-only sending domain), publish:

v=spf1 -all

This actively protects the domain from spoofing by declaring that no IP is authorised.

The 10 DNS lookup trap

SPF permits 10 DNS lookups total during evaluation. Each include: chain counts through its entire nested tree. Many popular ESPs already use 2-4 lookups internally:

_spf.google.com                       ~4 lookups
spf.protection.outlook.com            ~3 lookups
amazonses.com                         ~3 lookups
sendgrid.net                          ~3 lookups
spf.mandrillapp.com                   ~2 lookups
servers.mcsv.net                      ~1 lookup

Combining four of these puts you over 10. A generator that only counts the top-level include: directives will report 4 and let you publish a record that returns permerror on every evaluation.

The workarounds, in order of preference:

1. Remove unused senders. Audit your inventory. Most domains have 2-3 "zombie" ESP integrations from trials that were never disconnected.

2. Use ip4: instead of include:. For your own static IPs, never use a or mx unless you must. ip4: and ip6: do not count toward the 10-lookup limit.

3. Subdomain segmentation. Send transactional mail from mg.yourdomain with a short SPF record (one or two includes). Send marketing from mail.yourdomain with its own SPF. The apex domain then has a short v=spf1 -all or one include.

4. SPF flattening. Replace each include: with the IPs it resolves to. Requires automation because vendor IP ranges change. Several commercial and open-source tools do this; just re-flatten weekly.

Validating your generated record

After publishing, always validate. Use IntoDNS.ai to confirm:

• The record is syntactically valid.
• The record count is exactly one (multiple SPF records is an error).
• The total DNS lookup count is under 10.
• All include: targets resolve.
• The fail policy is ~all or -all, not ?all or +all.
• The record length is under 450 characters.

If your generator output fails any of these, fix before relying on it.

Common generator mistakes to avoid

Including senders you don't use. Starting with a "kitchen sink" SPF from a generator template and never trimming it. Adds DNS lookups for no benefit.

Using a and mx carelessly. mx counts as one lookup plus one per MX record returned, so a domain with four MX records uses five lookups just for that. Use ip4: instead.

+all or ?all fail policy. +all authorises the whole internet. ?all is equivalent to no record. Neither is ever correct in production.

Publishing without testing. Breaking SPF breaks mail delivery. Always scan after publishing and before leaving the office.

Mixing SPF versions. There is only SPF v1 (v=spf1). Records starting with v=spf2 or anything else are invalid.

Generator checklist for 2026

A minimum-viable SPF generator should let you:

1. Pick from a list of 20+ common ESPs.
2. Add custom ip4: and ip6: entries.
3. Choose ~all or -all.
4. See a real-time lookup count that resolves nested includes.
5. See character count.
6. Copy the exact DNS record syntax for major providers.

If a free tool does not do at least the first four, it is generating text, not SPF records.

Troubleshooting generator output

Record looks right but mail still fails SPF. Check with IntoDNS.ai whether the actual sending IP is covered. ESPs sometimes send from IPs not covered by their published include: — specifically when you use a "sender domain" feature that bypasses the main include.

Over 10 lookups despite being "conservative". Check the nested lookup count, not the top-level include: count. Use IntoDNS.ai's SPF explainer.

Two SPF records accidentally published. Common when a DNS provider appends a new TXT record instead of replacing the existing one. Delete the duplicate; SPF evaluates to permerror with multiple records.

SPF passes but DMARC fails. SPF alignment requires the envelope MAIL FROM domain to align with From:. Many generators do not warn that this is a per-ESP configuration, not an SPF record setting. Check your ESP's "sending domain" or "return-path" setting.

When to use IntoDNS.ai

IntoDNS.ai is not a generator but it is the validation step that turns generator output into a working record. After publishing, scan the domain, review the parsed SPF, confirm lookup count and alignment, and iterate if needed. This is the step most generators leave out and the one that actually catches problems before they reach production.

When a generator is the wrong tool

Some situations are too specific for a general generator:

Multi-region ESPs. Mailgun and Amazon SES publish region-specific SPF records. If you send from multiple regions, the generic include:mailgun.org covers both, but some vendors require region-specific includes. Read their SPF documentation before trusting a generator's template.

Vendor-managed sending domains. If an ESP manages a dedicated sending domain for you (e.g. em.yourdomain), the ESP typically provides exact DNS records to publish. These records may include CNAMEs for SPF, DKIM, and tracking — not just a TXT. A generator does not know about this structure.

Subdomain delegation. Some setups delegate an entire subdomain's SPF/DKIM/DMARC to the ESP via CNAMEs pointing at ESP-managed hostnames. Generators do not handle this pattern; follow the ESP's docs.

High-volume bulk senders. Past a few hundred thousand messages per day, SPF and DMARC strategy gets specific to the business (which mail from which tenant, subdomain-per-product, per-brand DKIM). A generator is a starting point; the real record is hand-designed.

After the generator: a short post-publish checklist

1. TTL set to 300 during first 48 hours so mistakes propagate fast.
2. Single SPF record only (scan confirms).
3. Lookup count under 9 (leave headroom for ESP growth).
4. All include: resolve without NXDOMAIN.
5. Fail policy is ~all or -all, not ?all or +all.
6. DMARC aggregate reports show your SPF aligning (or confirm DKIM picks up the slack).
7. Raise TTL to 3600 after 48 hours of clean operation.

This checklist takes 10 minutes and is the difference between a published record and a working authentication setup.