How to Set Up an SPF Record

Setting up an SPF record is a short DNS edit, but doing it safely takes a little discipline. The goal is a single TXT record that authorizes every server that legitimately sends mail as your domain — no more, no less. This guide walks through the process from inventory to a strict policy. If you need a refresher on the underlying concepts, start with what an SPF record is.

Step 1: Identify Your Legitimate Senders

Before touching DNS, make a list of every system that sends email as your domain. This is the step people skip, and it is the one that prevents bounced mail later. Typical sources include:

• Your own mail servers or office IP ranges.
• A hosted mailbox provider (the platform your staff use for day-to-day mail).
• Transactional senders — billing, password resets, receipts.
• Marketing or campaign platforms.
• The CRM, the helpdesk, and any other application that emails customers.

For each one, find out how it wants to be authorized. Most vendors publish an include mechanism (something like include:_spf.provider.com); some give you a fixed IP range you can add with ip4 or ip6.

Step 2: Build the TXT Record

An SPF record is one TXT record that begins with v=spf1 and ends with an all mechanism. List your senders in between, ordered with your highest-volume mail first — evaluation stops at the first match, so this keeps things fast. Here is a realistic record for a company that sends from its own servers, a hosted mailbox provider, and a marketing platform:

v=spf1 ip4:203.0.113.0/24 a:mail.example.com include:_spf.mailbox-provider.com include:spf.campaigns.example ~all

Reading it left to right:

• v=spf1 identifies the record version and must come first.
• ip4:203.0.113.0/24 authorizes every address in that range — typically an office or data-center block.
• a:mail.example.com authorizes whatever IPs that hostname currently resolves to.
• The two include mechanisms delegate to the published records of the mailbox provider and the campaign tool, so those vendors can update their own IP lists without you touching your DNS.
• ~all says anything not matched so far should softfail — the right setting while you confirm your list is complete.

Two rules keep this record valid. First, publish exactly one SPF record — if you add a new vendor, merge its mechanisms into the existing record rather than creating a second v=spf1 record, which would cause a permerror. Second, watch the ten-lookup limit: each include, a, and mx costs a DNS lookup, and a large provider's include can consume several more internally. The example above could already be at five or six lookups with only two visible vendors. The ip4 mechanism is free.

Step 3: Publish at the Root

Add the record to your DNS as a TXT record on the root of the domain (the bare example.com, often shown as @ in DNS panels). Use the TXT type, not the deprecated SPF record type — RFC 7208 retired the dedicated SPF type and modern receivers ignore it.

If your record grows past 255 characters, it must be split into multiple quoted strings within the same TXT record. Do not split it into two separate TXT records — that breaks everything.

Step 4: Test It

Once DNS caches expire — governed by your record's TTL, usually minutes to a few hours — verify the record before relying on it. Run your domain through our SPF record checker to confirm it parses, contains only one v=spf1 record, stays under the ten DNS lookups, and has no void lookups from stale includes. Then send test messages through each sending system and confirm they pass.

Step 5: Move from ~all to -all

A strict -all is the destination, but flipping it on blindly is how legitimate mail gets bounced. Start by making the record accurate rather than strict: keep ~all while you confirm every sender is represented, and publish a DMARC record with a monitoring policy. DMARC aggregate reports will show you who is sending on your behalf and whether they pass.

After a few reporting cycles with no legitimate source failing, tighten the final mechanism to -all:

v=spf1 ip4:203.0.113.0/24 a:mail.example.com include:_spf.mailbox-provider.com include:spf.campaigns.example -all

The change is a one-character edit, but the confidence behind it comes from the data.

Keep It Current

Migration is not a one-time event. New tools get adopted and old servers get decommissioned, and each change is a chance for the record to drift out of date. Re-check the record whenever a sending service is added or removed. And remember that ordinary forwarding rewrites nothing — forwarded mail fails SPF no matter how perfect the record is, which is precisely why DKIM and DMARC should accompany it.