SPF Records Explained: How to Set Up and Verify Yours

SPF is one of three pieces of the email authentication puzzle — alongside DKIM and DMARC — that determine whether your emails reach the inbox or get flagged as suspicious. For the full picture of how all three work together, see our guide to Email Authentication: SPF, DKIM, DMARC, and How to Reach the Inbox. Here, we're focused specifically on SPF: what it does, how to read and write one correctly, and how to verify it's actually working.

SPF (Sender Policy Framework) is a DNS TXT record that lists which mail servers are authorized to send email on behalf of your domain. When someone else's mail server receives a message claiming to be from yourcompany.com, it checks the sending server's IP address against your domain's SPF record. If the IP is listed as authorized, SPF passes. If it isn't, SPF fails — and depending on your configuration, that message might be flagged, quarantined, or rejected outright.

Without an SPF record, anyone could send email that appears to come from your domain, and receiving servers would have no way to check whether that's legitimate. That's the core problem SPF solves.

Here's a real-looking SPF record:

Every SPF record follows the same basic shape: a version tag, one or more mechanisms, and a qualifier on the final catch-all.

The mechanisms: include, a, mx, ip4/ip6

• v=spf1 — always the first element; declares this as an SPF version 1 record
• include:domain.com — authorizes any servers listed in another domain's SPF record (commonly used when a third-party service, like a marketing platform, sends mail on your behalf)
• a — authorizes the server matching your domain's own A record
• mx — authorizes any server listed in your domain's MX record
• ip4:x.x.x.x / ip6:x:x:x:x — authorizes a specific IP address directly

SPF mechanisms are evaluated left to right, and evaluation stops at the first match. This matters for troubleshooting: if a mechanism earlier in the record matches (even incorrectly), later mechanisms are never checked.

The qualifiers: +, ~, -, ?

The qualifier — usually attached to the final all mechanism — tells receiving servers what to do if nothing in the record matches:

Most businesses should use ~all while testing a new record, then move to -all once confident it's complete and accurate.

Finding what to include

Before writing anything, list every service that sends email on your domain's behalf — your primary email host, plus anything like a CRM, marketing platform, or invoicing tool that sends as [email protected]. Each of these typically publishes their own include: value in their setup documentation.

Writing and publishing the TXT record

1. Combine your primary mail host and any third-party senders into one record — you can only have one SPF record per domain
2. Format it as v=spf1 [mechanisms] ~all (or -all once confirmed)
3. Log into your domain's DNS settings and add a new TXT record
4. Set the host/name field to @ (or your root domain, depending on your DNS provider's convention)
5. Paste your SPF string as the record value
6. Save, and allow time for DNS propagation — this can take anywhere from a few minutes to 48 hours

Once published, verification confirms the record is both correctly formatted and actually resolving:

1. Use a DNS lookup tool to query the TXT record for your domain and confirm it returns your SPF string exactly as written
2. Send a test email to a personal account at a major provider (Gmail, Outlook) and check the message's original headers for an "spf=pass" result
3. Use a dedicated SPF checking tool to validate syntax and confirm no errors like exceeding the lookup limit

If SPF shows as failing on a message you know is legitimate, the most common culprits are a missing include: for a sending service, a typo in the record, or having more than one SPF TXT record published (which is invalid and causes a permanent error).

SPF enforces a hard limit of 10 DNS lookups per check — every include, a, mx, exists, and redirect mechanism counts toward that limit, including nested lookups inside include mechanisms you didn't write yourself. Exceed it, and SPF returns a permanent error (PermError), which many receiving servers treat as an outright fail — silently breaking deliverability even though the record looks fine at a glance.

Other common mistakes: publishing multiple SPF TXT records instead of merging them into one, using +all (which defeats the purpose entirely), and forgetting to update the record after switching or adding a sending service.

SPF checks where a message came from, but it doesn't verify the message's content wasn't altered, and it can break entirely when email is forwarded. That's what DKIM and DMARC are for — DKIM cryptographically signs your outgoing messages, and DMARC ties SPF and DKIM together into one enforceable policy. Our full Email Authentication: SPF, DKIM, DMARC guide covers how all three work together as a complete authentication setup — SPF is necessary, but it's step one, not the whole picture.

UCN Mail walks you through SPF setup as part of its guided domain configuration — rather than handing you a raw record to assemble and debug on your own, the setup flow identifies your sending services and generates a correctly merged record for you, including DKIM and DMARC alongside it. Combined with built-in spam and threat filtering, this means your domain's authentication is set up correctly the first time, with mailboxes available across the Lite, Basic, Pro, and Business tiers.

• Email Authentication Explained: SPF, DKIM, DMARC, and How to Reach the Inbox