Skip to content
Start with 100 free verification credits
Qualisend
Free tool

SPF record generator.

Build a valid SPF TXT record without hand-editing DNS syntax. Tick the platforms you send through, add any extra IPs or includes, choose how strict the policy should be, and copy the finished record. It assembles live in your browser - no account, no card.

1

Sending sources

Search for each platform you send email through and tick it.

Search for your email platform above, or .

2

This domain's own servers

Authorize the domain itself, if it sends mail directly (not through a platform above).

3

Other senders & IPs

Anything not in the list: another provider's SPF host, or specific IP addresses.

We add the include: prefix. Enter the hostname your provider documents.

4

Policy for everyone else

What receivers should do with mail from any server not listed above (the all mechanism).

Your SPF record0/10 DNS lookups
v=spf1 ~all

No senders yet, so every message would hit the ~all policy. Add the platforms you send through in step 1.

  • Publish it as a TXT record at your root domain: host @ (the bare domain), value the full string above.
  • Keep only one SPF record per domain. Merge every sending source into this single line. A second TXT record starting v=spf1 makes both invalid.
  • Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself - ip4: and ip6: are free.

Authentication published? The next step is sending to a clean, verified list.

Verify a list

What goes into an SPF record

SPF is one of the three DNS records behind email authentication. It answers a single question for receivers: is this server allowed to send for this domain? The SPF, DKIM and DMARC explainer covers how the three fit together, but the record itself is just a list of mechanisms:

include: - a provider's own senders
Delegates authorisation to a platform like Google Workspace or SendGrid. Each provider publishes the exact hostname to use, and each include counts toward the 10-lookup budget.
ip4: / ip6: - your own servers
Authorise a specific address or CIDR range directly. These cost no DNS lookups, so they're the way to stay under the limit when you send from your own infrastructure.
the all mechanism - everyone else
The final word: ~all softfails unlisted senders, -all rejects them. It only means something once every legitimate source above it is listed.

SPF is one record of three

Publishing SPF is the first move, but on its own it doesn't stop spoofing - receivers need a policy telling them what to do when SPF and DKIM fail. That policy is DMARC, and it's what Gmail and Yahoo now require from bulk senders. Once your SPF record is live, follow the step-by-step DMARC setup to add the enforcing layer on top. Authentication proves who you are; it doesn't clean your list - sending to dead addresses still drives bounces and hurts the reputation SPF is meant to protect.

Provider setup guides

The SPF record is one part of the setup. Each guide covers the full SPF, DKIM and DMARC setup for one provider.

All SPF guides

SPF record generator FAQ

SPF (Sender Policy Framework) is a single TXT record you publish in DNS that lists which servers are allowed to send email for your domain. When a receiver gets a message claiming to be from you, it looks up your SPF record and checks whether the sending server is authorised. A record always starts with v=spf1, lists mechanisms like include:, a, mx, ip4: and ip6:, and ends with an all mechanism that says what to do with everyone else.

~all is a softfail: receivers accept mail from servers you didn't list but mark it as suspicious. -all is a hard fail: they should reject it outright. -all is stronger, but only switch to it once you're certain every legitimate sending source is in the record - otherwise real mail from a forgotten service can be rejected. Most senders start on ~all, confirm nothing legitimate is failing (DMARC reports help), then move to -all. ?all is neutral and offers almost no protection.

SPF evaluation is capped at 10 DNS lookups per check. Every include:, a, mx, ptr and exists mechanism costs one lookup, and an include can trigger further lookups inside the record it points to. Go over 10 and SPF returns a permerror, which most receivers treat as a fail - so a bloated record can break authentication for mail that should pass. ip4: and ip6: mechanisms cost nothing, so flattening includes into IP ranges is the usual fix when you're near the limit.

No. A domain must have exactly one TXT record that begins with v=spf1. If two SPF records exist, receivers see it as a permerror and your authentication fails. To authorise several providers you merge them into one record by adding each provider's include: mechanism to the same line - which is exactly what this generator produces.

Authentication is only half the job

SPF proves who sends your mail; verifying your list removes the dead addresses that bounce and hurt reputation. Start free with 100 credits, no card required.

Start verifying