SPF record generator

Build a valid SPF record from the senders you actually use, and see the DNS-lookup cost before you publish it.

Comma-separated. Only for servers you run yourself, not a provider ticked above.

Comma-separated.

A domain name only, without "include:" — for a sender not in the list above.

Result

0 of 10 DNS lookups

Copy the record below into a TXT record at the root of the domain.

  • Passed

    0 of 10 DNS lookups used

    There is room to add more senders later without approaching the 10-lookup ceiling RFC 7208 §4.6.4 sets.

SPF record to publish

v=spf1 ~all

At @ (TXT)

Publish this as a TXT record at the domain itself, not a subdomain.

  • The lookup cost for each sender ticked above is the chain depth published in that provider’s own SPF documentation at the time this was written — a provider can change its own record, which changes the cost without anything changing here.
  • A domain you typed into "Any other provider’s include" is counted as one lookup, which is a floor: if that domain itself includes others, the true cost is higher. Check its own SPF record with the SPF checker before publishing.

What this is

This SPF record generator turns a checklist of senders into a valid SPF record, and does the one calculation that is otherwise invisible until a record breaks: how many of the ten DNS lookups RFC 7208 §4.6.4 allows the chosen senders will actually spend.

Every mailbox provider, marketing platform and helpdesk that sends mail "from" your domain needs to be named in its SPF record, as an "include" that points at that provider's own list of servers. Leaving one out does not stop its mail sending — it stops that mail from passing SPF, which many receivers treat as a reason to doubt the whole message.

What a checklist cannot show by itself is cost: each provider's include is its own DNS lookup, and some providers' own records include others again. Google Workspace, for instance, spends four lookups once its own chain is followed, not the one line this tool writes for it.

How to read the result

The counter at the top says how many of the ten allowed lookups the ticked senders spend. Below eight it is undramatic; from eight it is worth noticing before adding anything else, and past ten the record is invalid before it is even published — RFC 7208 §4.6.4 makes every mechanism in it meaningless once that happens.

The record itself goes in a TXT record at the domain’s own name, never a subdomain, and a domain publishes exactly one of them — adding a second SPF record rather than editing this one is itself a fault the SPF checker next door will flag.

Common mistakes

  • Listing a provider’s servers as ip4 ranges instead of its include — A provider's sending ranges change without telling every customer first. Its "include" mechanism always points at its current list; copying today's ranges into your own record freezes them at today, and they go stale the next time the provider adds a server.
  • Not knowing an include’s own cost before adding it — A provider's own SPF record can include others of its own, so one line here can spend more than one of the ten lookups the record is allowed. Four well-known providers can add up to the limit faster than four lines suggests.
  • Choosing +all to avoid troubleshooting a failure — This passes every sender, listed or not, which erases the point of listing any of them. A failure is almost always one real sender missing from the list above, not a reason to let every sender through.
  • Publishing the record on a subdomain instead of the domain itself — SPF is checked against the domain in the return-path address, which for most mail is the domain itself. A record published on "mail.example.com" instead of "example.com" is never read for ordinary mail from that domain.

Questions

How do I write an SPF record for Google Workspace and another sender together?

Tick both in the checklist above: each gets its own "include" mechanism in the same record, in any order, ending with one "all" mechanism that covers everyone not explicitly listed.

Why does adding one sender sometimes cost more than one DNS lookup?

A provider's "include" mechanism points at that provider's own SPF record, and that record can include others of its own. Google Workspace's chain, for example, spends four lookups once followed all the way down, not one.

Can I publish more than one SPF record if I run out of room in one?

No — a domain is only allowed one "v=spf1" TXT record, and RFC 7208 §4.5 treats a second one as a permanent error that breaks checking entirely. Reduce the lookup cost instead, by removing a sender or flattening an include.

Should I use -all or ~all when I publish this?

"~all" is the safer starting point: it flags an unlisted sender without rejecting its mail outright, which matters while you are still confirming nothing real was left off the list. Move to "-all" once you are confident the list is complete.

Resell mailbox licences for the domains you just checked, under your own brand.

Get started

API example

Example request
curl -X POST https://163-123-236-68.sslip.io/api/tools/spf-generator \
  -H "Content-Type: application/json" \
  -d '{"senders":["google","m365"],"ip4":"","ip6":"","includes":"","all":"~all"}'
Example response
{
  "tool": "spf-generator",
  "input": {
    "senders": [
      "google",
      "m365"
    ],
    "ip4": "",
    "ip6": "",
    "includes": "",
    "all": "~all"
  },
  "result": {
    "verdict": {
      "tone": "success",
      "headline": "5 of 10 DNS lookups",
      "summary": "Copy the record below into a TXT record at the root of the domain."
    },
    "findings": [
      {
        "id": "within-lookup-limit",
        "severity": "pass",
        "title": "5 of 10 DNS lookups used",
        "detail": "There is room to add more senders later without approaching the 10-lookup ceiling RFC 7208 §4.6.4 sets."
      }
    ],
    "parts": [
      {
        "kind": "record",
        "title": "SPF record to publish",
        "value": "v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all",
        "note": "Publish this as a TXT record at the domain itself, not a subdomain.",
        "at": {
          "name": "@",
          "type": "TXT"
        }
      }
    ],
    "limits": [
      "The lookup cost for each sender ticked above is the chain depth published in that provider’s own SPF documentation at the time this was written — a provider can change its own record, which changes the cost without anything changing here.",
      "A domain you typed into \"Any other provider’s include\" is counted as one lookup, which is a floor: if that domain itself includes others, the true cost is higher. Check its own SPF record with the SPF checker before publishing."
    ]
  }
}

Related tools

Email authentication

SPF checker

Check an SPF record for the faults that silently break it, and count every DNS lookup it costs.

Email authentication

DMARC record generator

Build a DMARC record step by step, from monitoring through to full enforcement.

Email authentication

DKIM checker

Find a domain’s DKIM key, read its tags in plain words, and flag a weak, revoked or malformed one.