SPF explained

What SPF is, how to publish a record correctly, what it does not protect against, and the mistakes that silently break it.

What SPF is

SPF, the Sender Policy Framework (RFC 7208), is a DNS record that answers one question: which servers are allowed to send email for this domain?

You publish a list of authorized senders in your DNS. A receiving server compares the IP address that connected to it against your list. If the IP is not in the list, the receiver knows the message did not come from an authorized source and can reject it or mark it as suspicious.

That is all SPF does. It is a sender authorization list, not encryption, not a spam filter, and not a guarantee of delivery. It is one of the three records that together make your mail trustworthy, alongside DKIM and DMARC.

How it works

An SPF record is a TXT record published at your domain’s root. It looks like this:

v=spf1 include:spf.mailverick.com -all

Read left to right, that says: this is an SPF record, treat anything authorized by spf.mailverick.com as authorized for us, and reject everything else.

The pieces you will encounter:

Use -all. Soft fail exists for a migration period when you are not yet sure you have listed every legitimate sender. Once you are sure, -all is what actually protects the domain, and ?all protects nothing.

The part most people get wrong

SPF validates the envelope sender (the MAIL FROM address, also called the return-path), not the From: header that your recipient sees in their inbox.

Those two are frequently different addresses. A spammer can pass SPF perfectly by using a domain they control in the envelope, while putting your brand in the visible From: header. SPF sees nothing wrong.

This is not a flaw to work around. It is the reason DMARC exists. DMARC adds the missing requirement: the domain that passed SPF must align with the domain in the visible From: header. SPF without DMARC does not protect your brand from being impersonated.

How to set it up

1. Check what you already have. Look up the TXT records on your root domain and find any value starting with v=spf1. Most domains that have ever sent mail already have one.
2. If you have no SPF record, publish the value your provider gives you as a TXT record on the root of your domain. Providers differ on the host field: some want @, some want the domain name itself.
3. If you already have one, merge into it. Add the new include: to the existing record. Never publish a second record.
4. Wait for DNS propagation, then verify. Most providers have a check button, and command line works too: dig +short TXT yourdomain.com.

In Mailverick

Add your domain in the Domains section of the portal and Mailverick generates the exact records to publish, step by step in Getting Started. The SPF value is:

v=spf1 include:spf.mailverick.com -all

Click Check DNS and the portal reports a per-record status (valid, warning, invalid, absent) showing exactly what it found versus what it expected. SPF and DKIM must both be valid before you can send. A record ending in ~all instead of -all is accepted and reported as a warning, not an error.

If your domain already has an SPF record for another service, add include:spf.mailverick.com to that record rather than creating a new one.

Common mistakes

Two SPF records. The single most common failure. Publishing two v=spf1 records on the same domain is a permanent error, and receivers treat it as no valid SPF at all, so mail that would otherwise have passed now fails. If you add a service, extend the record you have.

Exceeding 10 DNS lookups. Every include, a, mx, exists, and redirect costs a DNS lookup, and nested includes count too. Past 10, evaluation fails with a permanent error, and the failure is invisible until deliverability drops. Providers with long chains of nested includes use up that budget fast, so drop includes for services you no longer use. ip4, ip6, and all are free.

Assuming subdomains inherit. They do not. SPF is looked up on the exact domain in the envelope sender, so mail.yourdomain.com needs its own record. A root domain record does not cover it.

Expecting SPF to survive forwarding. When a recipient auto-forwards your message, the forwarding server relays it from its own IP, which is not in your SPF record, so SPF fails at the final destination. Nothing is wrong with your setup. This is a structural limit of SPF, and it is why DKIM matters: a DKIM signature survives forwarding, so a forwarded message can still authenticate.

Using the ptr mechanism. Deprecated by RFC 7208 and ignored or penalized by receivers. Remove it.

Publishing over 255 characters in one string. A single TXT string cannot exceed 255 characters. Long records must be split into multiple quoted strings within the same record, which most DNS providers handle automatically. If yours does not, shorten the record.

FAQ

Do I need SPF if I already have DKIM?

Yes. Gmail, Yahoo, and Microsoft expect both, and DMARC needs at least one of them to pass with alignment. Publishing both is the baseline, not an extra precaution.

Will publishing -all block my own mail?

Only if something legitimate is missing from the record. Before switching to -all, list every system that sends as your domain: your email provider, your CRM, your invoicing tool, your helpdesk, your monitoring alerts. That inventory is the real work. The record itself is easy.

Does SPF affect whether I land in spam?

Indirectly, and strongly. SPF alone will not get you into the inbox, but a missing or broken record is a reliable way to lose it. At scale, the major providers treat unauthenticated mail as ineligible for delivery rather than merely suspicious.

How long do changes take?

DNS changes take effect as caches expire, controlled by the record’s TTL, so typically minutes to a few hours. Lower the TTL before a planned change if you want a faster switch.

Can I have one SPF record covering several domains?

No, each sending domain publishes its own. You can point them at a shared include: to keep the list in one place, which is exactly what include: is for.

Last updated: July 2026