SPF Record Setup Guide: From Zero to Protected

Before we talk about how to set up an SPF record, you need a clear picture of the problem SPF was invented to solve. Email is older than the web — the original specification dates back to 1982 — and it was designed in a much more trusting era. Here is the uncomfortable truth: the original email standard lets anyone type anything in the "From:" line of a message. There is no automatic check, anywhere in the protocol, that the sender is who they claim to be. If you have a mail server, a script, or even a free trial of a marketing tool, you can send a message that says "From: ceo@yourbank.com" and it will arrive in someone's inbox looking exactly like a real one.

This is called email spoofing, and it is the foundation of every phishing attack you have ever seen. The fake invoice from your CFO. The urgent gift-card request from your boss. The password-reset link that does not actually go to your bank. The wire-transfer instructions that look like they came from a partner. They all start with someone forging the From: address of a brand or a person the victim already trusts. Until the mid-2000s, there was almost nothing receivers could do to tell the difference between a real email and a forged one.

The internet community came up with three rulebooks to fix this, all stored as text records in your DNS (Domain Name System):

• SPF (Sender Policy Framework) — a guest list of which servers are allowed to send email on behalf of your domain. Invented in 2003, standardized in 2014. This guide is about SPF.

• DKIM (DomainKeys Identified Mail) — a digital signature on every message that proves it really came from you and was not modified in transit.

• DMARC (Domain-based Message Authentication, Reporting and Conformance) — the policy on top of SPF and DKIM that tells receiving mail servers what to do when one of those checks fails. Reject the message? Send it to spam? Just record it for later analysis?

All three work together. Think of SPF as the bouncer with the guest list at the front door, DKIM as the wax-seal signature on the envelope, and DMARC as the rulebook that tells the receiving mail server what to do when one of those checks fails. SPF alone is a meaningful first step, but you really want all three. This guide focuses on SPF because it is the easiest one to set up first, and because most people accidentally break it the first time they touch it.

One more piece of context: in February 2024, Gmail and Yahoo started requiring SPF on any domain sending more than 5,000 emails per day. Microsoft Outlook followed a few months later. SPF has officially crossed the line from "good practice" to "mailbox providers will refuse your bulk mail without it." If you send any meaningful volume of email — newsletters, transactional receipts, marketing campaigns, customer support replies — SPF is no longer optional. The rest of this guide is the practical how-to.

SPF (Sender Policy Framework) is a list — published as a DNS (Domain Name System) record — that says "these are the only servers allowed to send email pretending to be me."

Think of it like a guest list at a private party. When a receiving mail server gets an email claiming to be from `you@yourdomain.com`, it goes look up your SPF record and asks, "is the server that delivered this email on the guest list?" If yes, the message keeps moving. If no, the receiver knows something is fishy and can act accordingly.

SPF is one of the three main pillars of email authentication. The other two are DKIM (DomainKeys Identified Mail), which verifies the message wasn't tampered with in transit, and DMARC (Domain-based Message Authentication, Reporting and Conformance), which ties SPF and DKIM together with a policy about what to do when checks fail. All three work together. SPF alone is helpful but not sufficient — you really want DKIM and DMARC too.

Let's skip the marketing fluff and answer the only question that actually matters: why should you, a real human with a real to-do list, care about SPF? Here's the plain-English version, written the way you'd hear it from a friend who happens to do this for a living.

The first reason is selfish: your real email is more likely to reach the inbox. Mail providers like Gmail, Microsoft 365, and Yahoo treat SPF as a baseline trust signal. Without it, your messages look more suspicious to spam filters and to the AI-driven inbox classifiers that decide whether your newsletter goes to the inbox, the Promotions tab, or the spam folder. With SPF set up correctly you are playing by the rules everyone in the room expects, and your inbox-placement rate climbs accordingly.

The second reason is protective: scammers cannot impersonate you as easily. Without SPF, anyone can send an email saying "From: ceo@yourcompany.com" and there is nothing technically stopping it. With SPF (especially when paired with DMARC at `p=reject`), receiving mail servers will refuse the impostor. Your customers, employees, partners, and investors are protected from being phished by someone wearing your brand.

Picture this in real life. A founder of a small e-commerce store gets a panicked call from her bookkeeper saying that an invoice for $4,200 was just paid to a bank account the bookkeeper had never seen before. The invoice email looked exactly like one of her supplier's normal monthly bills, complete with the right logo and the right language. The supplier had not, in fact, sent it. A scammer had spoofed the supplier's domain — a domain with no SPF record — and the bookkeeper had no way to tell the difference. After the incident, the founder spends an hour setting up SPF on her own domain and asks her supplier to do the same. The fix took less time than the panicked phone call.

Three questions this tool answers in plain English. If any of these have ever crossed your mind, SPF is built for you:

• Will the emails I send actually reach the inbox, or are they going to spam?

• Can someone else send phishing emails pretending to be my domain?

• Have I set up the rulebook that mailbox providers like Gmail and Yahoo now require?

You can either run the check yourself with the free EdgeDNS SPF lookup tool, or ask your AI assistant — connected through MCP (Model Context Protocol) — to ask the question for you and translate the answer into something you can act on.

Who gets the most out of this guide. Small-business owners worried about deliverability, marketing managers onboarding a new email service, IT admins prepping for a security audit, and brand teams protecting against phishing. If you see yourself in that list, this is one of the standards you should fully understand and have in place by the end of the week.

What happens if you skip this entirely. Your real emails risk landing in the spam folder while scammers find it easier to impersonate your brand. Your security audit will flag a missing control. And — if you send more than 5,000 emails per day — Gmail and Yahoo will start refusing your bulk mail outright. That is why running this check, even once a month, is one of the cheapest forms of insurance you can give your domain.

If you're still on the fence about whether SPF belongs in your toolbox, this section is for you. Below you'll meet three real people facing three real situations where setting up or checking SPF turns a stressful afternoon into a five-minute task. Read whichever story sounds closest to your week.

Story 1: The marketer signing up for a new email service

Imagine you're a marketing manager at a 50-person SaaS company. The team just bought SendGrid for transactional email and Mailchimp for marketing newsletters. Both onboarding flows include a step that says "add the following to your SPF record" and shows you a string like `include:sendgrid.net` or `include:servers.mcsv.net`. You log into your DNS provider, find the existing SPF record (which currently has just Google Workspace in it), and start adding includes. You add SendGrid. You add Mailchimp. You add a third include for the new live-chat tool you forgot was using your domain. And you have just silently broken your SPF record by exceeding the 10-DNS-lookup limit, which causes the entire SPF check to return a permanent error and pretend the record doesn't exist. Running the EdgeDNS SPF lookup tool would have told you the lookup count in seconds. Without it, you would have discovered the problem days later when your newsletter open rate suddenly cratered.

Why it matters: Adding services to SPF is one of the most common things a marketer ever has to do, and it is the single most common way SPF gets broken. A 10-second check before saving the record prevents days of debugging.

Story 2: The IT admin troubleshooting "your email is going to spam"

Imagine you're the one IT person at a 30-person professional services firm. A senior partner forwards you an email from a client that reads: "I never see your invoices anymore, did something change?" You check the partner's outbox and confirm the invoice was sent. You check your email service's delivery log and it says the message was accepted by the client's mail server. Everything looks fine on your end. The actual problem is that two months ago someone added a new e-signature service to the SPF record and pushed the lookup count to 11, silently breaking the record. Every email from your domain is now failing SPF authentication, which Gmail and Microsoft are treating as a trust signal in the wrong direction. The fix is one line in the SPF record and one minute of work — but you would never have looked there without first running an SPF check that flagged the lookup-count problem.

Why it matters: "Your email is going to spam" is one of the highest-blame, lowest-visibility problems in IT. SPF is almost always involved in the diagnosis.

Story 3: The compliance officer prepping for SOC 2

Imagine you're the compliance officer at a fintech going through its first SOC 2 audit. The auditor's questionnaire asks for documented proof that all customer-facing email is authenticated. You have eight production domains and you're not sure which ones have SPF, which ones have DKIM, which ones have DMARC, and which ones have all three correctly. Manually checking eight domains in eight different DNS providers would take a couple of hours of clicking around. Asking your AI assistant — connected through the EdgeDNS MCP server — to "run a complete email security audit on these eight domains and give me the results in a table I can paste into the audit response" gives you a clean, time-stamped, audit-ready report in five minutes.

Why it matters: Audits are where the time you saved by automating routine checks pays off in calendar hours.

Common situations across teams. Beyond the three stories above, here are the everyday workplace moments when people across the company reach for an SPF check. If any of these are on your calendar this month, that's your sign:

• When setting up email on a brand-new domain.

• After signing up for a new email-sending service (Mailchimp, SendGrid, HubSpot, Klaviyo, etc.).

• When a customer reports that your emails are landing in their spam folder.

• Before a security audit, a SOC 2 review, or a major marketing campaign.

Still not sure? Open Claude, ChatGPT, Gemini, or any other AI assistant connected to the EdgeDNS MCP server and ask, in your own words: "Is my SPF record set up correctly for example.com?" The assistant will run the check, count the DNS lookups, and tell you in plain English whether you're in good shape.

An SPF record is a single TXT record published at the root of your domain (so at `yourdomain.com`, not at a subdomain). Its structure is always:

`v=spf1 [list of allowed senders] [what to do with everyone else]`

That last part — "what to do with everyone else" — is called the all qualifier, and it always comes at the end. Your three options: - `-all` (hard fail) — "reject any sender not on this list." This is the strictest and what you almost always want eventually. - `~all` (soft fail) — "treat any sender not on this list as suspicious but don't reject." Useful while you're still building the list. - `+all` (allow all) — never use this. It tells receivers "any server in the world can send email as me." It defeats the entire point of SPF.

Here are some example records, from simplest to most complex:

Most email services give you a special include domain to add to your SPF record. The `include:` mechanism is their way of saying "all our authorized servers are listed in this other DNS record we maintain — point at it and we'll keep it up to date."

Here are the include domains for popular services:

• Google Workspace: `include:_spf.google.com`

• Microsoft 365: `include:spf.protection.outlook.com`

• Amazon SES: `include:amazonses.com`

• SendGrid: `include:sendgrid.net`

• Mailchimp: `include:servers.mcsv.net`

• Postmark: `include:spf.mtasv.net`

• Zendesk: `include:mail.zendesk.com`

• Salesforce: `include:_spf.salesforce.com`

• HubSpot: `include:spf.hubspot.com`

To add a service, you append its include to your existing record. For example, if you currently use Google Workspace and want to add SendGrid:

Before: `v=spf1 include:_spf.google.com -all` After: `v=spf1 include:_spf.google.com include:sendgrid.net -all`

Each `include:` counts as one DNS lookup toward a hard limit you need to know about — which is the topic of the next section.

Here's the rule that catches almost everyone: SPF allows a maximum of 10 DNS lookups per evaluation. Go over 10, and the entire SPF check fails — not just the over-limit ones. This is called a `permerror`, and it makes your SPF record completely useless.

What counts toward the 10: - Each `include:` mechanism — 1 lookup each - The `a` and `mx` mechanisms — 1 lookup each (plus extras for resolving the actual MX records) - A `redirect=` directive — 1 lookup - An `exists:` check — 1 lookup

What does not count: - `ip4:` and `ip6:` mechanisms — these are listed directly, no lookup needed - The `all` qualifier at the end

The sneaky part: nested includes also count. If you `include:_spf.google.com` and Google's own SPF record contains 3 more includes inside it, you've used 4 lookups, not 1. So a record that looks like it has 5 mechanisms can secretly be using 12 lookups by the time everything is resolved.

Strategies to stay under the limit:

1. Replace `include:` with `ip4:` where possible. If a service has stable IP addresses, you can list them directly. Trade-off: you have to update the record yourself when their IPs change.

2. Use subdomains for different sender types. `marketing.example.com` can have its own SPF record with its own 10-lookup budget. Your transactional mail can come from `txn.example.com`, and so on.

3. Quarterly cleanup. Audit your SPF record every few months. You almost certainly have includes for services you stopped using a year ago.

4. SPF flattening services. These tools resolve all your includes into a flat list of IP addresses, but you have to subscribe and let them keep the list updated when the underlying services change. Use carefully.

After creating or changing your SPF record, you should validate it three ways:

1. Check the syntax and lookup count. The free EdgeDNS SPF lookup tool will parse your record, count every nested DNS lookup, and tell you if anything is broken. Or ask your AI assistant: "Validate the SPF record for example.com and tell me if there are any problems."

2. Verify it's published correctly. Check that DNS actually returns your record:

These are for people running more complex email setups. Skip them if you're just starting out.

`redirect=` instead of duplicating records. If you have a hundred domains that should all use the same SPF record, you can publish the full record once and just point the others at it: `v=spf1 redirect=_spf.example.com`. Unlike `include:`, `redirect=` replaces the entire evaluation rather than adding to it.

`exists:` with macros for dynamic authorization. You can use macros that substitute the sender's IP into a DNS query, like `v=spf1 exists:%{i}._spf.example.com -all`. This lets you authorize senders dynamically without using up lookup slots. Powerful, but complicated — only use this if you have a specific reason.

Per-service subdomains for organizations with many senders. A common setup: - Transactional email at `txn.example.com` — `v=spf1 include:amazonses.com -all` - Marketing email at `mktg.example.com` — `v=spf1 include:sendgrid.net -all` - Corporate email at `example.com` — `v=spf1 include:_spf.google.com -all`

Each subdomain gets its own 10-lookup budget, and troubleshooting is easier because you can see exactly which sender type a problem belongs to.

Null SPF for non-sending domains. If you own a domain that should never send email (like a parked domain or a redirect-only domain), publish: `v=spf1 -all`. This explicitly tells the world to reject any email claiming to come from it. It's a free anti-impersonation protection.

SPF (Sender Policy Framework) — the email guest list this whole guide is about.

DKIM (DomainKeys Identified Mail) — a digital signature added to every email to prove it really came from you and wasn't changed in transit.

DMARC (Domain-based Message Authentication, Reporting and Conformance) — the rulebook that ties SPF and DKIM together with a policy about what to do when they fail.

DNS (Domain Name System) — the internet's address book. SPF is published as a DNS record.

TXT record — a type of DNS entry that holds plain text. SPF, DKIM, and DMARC are all TXT records.

MX record (Mail eXchanger record) — a DNS entry that lists the mail servers handling email for your domain.

`include:` mechanism — a way to import another organization's SPF rules into yours. Most email services give you one of these.

`-all` qualifier — the strict end-of-record marker that says "reject anyone not on the list."

permerror — a permanent error in your SPF record (usually from going over the 10-lookup limit) that makes the entire SPF check fail.

MCP (Model Context Protocol) — the standard that lets you ask Claude, ChatGPT, or Gemini to validate your SPF record for you.