Build one SPF record from the mail sources your domain actually uses.

SPF tells receivers which mail servers are allowed to send for a domain. This generator helps avoid duplicate records and overly loose defaults.

Sending sources

Select at least one sending source.

How it works

  • Choose the services or include mechanisms that send mail for the domain.
  • Pick a fail policy, then copy the generated TXT record into your DNS provider.
  • Check the result with the DNS checker after propagation.

When to use it

  • When setting up a new sending domain or client workspace.
  • When consolidating records after adding a new ESP, CRM, or SMTP service.
  • When SPF fails because a domain has multiple TXT records beginning with `v=spf1`.

Common failure cases

  • Adding a second SPF record instead of merging mechanisms into the existing one.
  • Using `+all` or `?all` when the domain should restrict senders.
  • Letting nested includes push SPF over the 10-DNS-lookup limit.

Examples

What good and bad signals look like

Good record

v=spf1 include:_spf.google.com include:sendgrid.net ~all

One SPF record lists known senders and uses a cautious softfail while monitoring.

Risky record

v=spf1 +all

This authorizes every sender and removes SPF's value as an authentication signal.

What to do next

  • Publish the TXT record at the root of the sending domain.
  • Verify the final record with the DNS checker before export or launch approval.
  • Pair SPF with DKIM and DMARC; SPF alone is not enough for domain alignment.
Plan domains and inboxes together

Use the capacity calculator before provisioning many sending domains.

FAQ

Can a domain have more than one SPF record?

No. Publish one TXT record that starts with `v=spf1`. Multiple SPF records commonly cause SPF permerror.

Should cold email domains use `-all` immediately?

Not by default. Many teams start with softfail while verifying every legitimate sender, then tighten policy when evidence supports it.