Stop Email Spoofing: Fix SPF Record in 20 Minutes for Marketers

An SPF record is a DNS TXT entry that lists the mail servers authorized to send email for your domain. Its job is to stop strangers from forging your “From” address, since receiving servers check that list before deciding whether a message is legitimate. SPF alone doesn’t cover the visible From address you see in your inbox — that’s where DMARC steps in, tying SPF and DKIM together into one enforceable policy.

---

TL;DR:

• SPF records can authorize up to 10 DNS lookups, making complex configurations prone to exceeding this limit and causing failures.
• Using include: mechanisms for third-party services simplifies updates but increases lookup count, risking SPF errors if mismanaged.
• SPF only authenticates the MAIL FROM address and does not confirm the visible From; DMARC enforces alignment with the displayed sender.
• Maintaining a single, correct SPF TXT record per domain is essential, as duplicate records cause automatic SPF failure.
• Regular auditing of SPF, DKIM, and DMARC ensures ongoing deliverability and prevents misconfigurations from causing emails to land in spam or fail authentication.

---

Table of Contents

• How SPF Works, Step by Step
• SPF Record Format and Common Mechanisms
• How to Check Your Domain’s Current SPF Record
• How to Create or Update an SPF TXT Record
• Limitations and Common Pitfalls to Avoid
• How SPF, DKIM, and DMARC Work Together
• Troubleshooting Common SPF Failures
• Why Deliverability Teams Treat SPF as Routine Maintenance
• An Agency Perspective on the Fixes We See Most
• Let Take-action Handle Your Email Authentication Setup
• Where to Read the Original Standards and Provider Docs
• Sources

How SPF Works, Step by Step

SPF operates on the envelope sender (the MAIL FROM address used during the SMTP handshake), not the “From” header you see displayed in your inbox client. That distinction trips up a lot of people, because the two addresses often look identical but get checked in completely different ways. When a receiving mail server gets a message, it pulls the domain from the envelope address and asks DNS for that domain’s TXT record starting with v=spf1.

Once the receiving server has the record, it reads the mechanisms left to right, checking each one until it finds a match. This ordering matters more than most senders realize. If an include: for a third-party platform sits before a broader a or mx mechanism, the include gets evaluated first, and its result determines the outcome according to RFC 7208.

Each mechanism carries a qualifier that tells the receiver what to do with a match:

• Pass (+): the sending IP is authorized, no qualifier needed since it’s the default.
• Fail (-): reject the message outright if the IP doesn’t match anything earlier in the string.
• Softfail (~): accept but flag or downgrade the message, often into spam.
• Neutral (?): treat the result as if no SPF policy existed at all.

The whole system runs on a first-match-wins rule. As soon as evaluation hits a mechanism that matches the sending IP, that mechanism’s qualifier decides the result, and everything after it in the record gets ignored. That behavior explains why reordering a record, or adding a new include in the wrong spot, can silently change how mail from an existing platform gets treated.

SPF Record Format and Common Mechanisms

Reading a raw SPF string looks intimidating the first time, but it’s really just a sequence of instructions read in order. Every valid record starts with v=spf1 to declare the SPF version, followed by a list of mechanisms and a closing “all” directive.

Here’s what the common pieces mean:

Mechanism	What it authorizes
ip4:	A specific IPv4 address or range
ip4:	An IP address or range
a	The domain’s own A record IP
mx	IPs listed in the domain’s MX records
include:	Another domain’s SPF record, pulled in wholesale
exists:	A DNS lookup used for conditional logic (rare in practice)
redirect=	Hands off evaluation entirely to another domain’s record
all	Catch-all for anything not matched above

A real record might read: v=spf1 ip4:192.0.2.10 include:_spf.google.com include:sendgrid.net ~all. That string says three things: mail from 192.0.2.10 is authorized, anything Google Workspace’s own SPF record authorizes is authorized, anything SendGrid’s SPF record authorizes is authorized, and everything else should be softfailed rather than outright rejected.

On qualifiers for all: Google Workspace’s own guidance recommends starting with ~all (softfail) while you confirm every legitimate sender is accounted for, then tightening to -all (hard fail) once you’re confident nothing gets missed.

One housekeeping note worth knowing: TXT records aren’t exclusive to SPF. A domain can have TXT entries for site verification, DKIM keys, and other services, so when you’re editing DNS, make sure you’re modifying the SPF string and not accidentally overwriting an unrelated TXT value.

How to Check Your Domain’s Current SPF Record

Before changing anything, look at what’s actually published. A handful of quick checks tell you most of what you need.

1. Run a DNS lookup from the command line. On macOS or Linux, dig TXT yourdomain.com returns every TXT record for the domain; on Windows, nslookup -type=TXT yourdomain.com does the same. Scan the output for the string starting with v=spf1.
2. Use an online SPF checker. Tools built for this purpose parse the record, count DNS lookups, and flag syntax errors that are easy to miss by eye.
3. Read the output carefully. “No SPF record found” means nothing is published yet. Multiple SPF strings under one domain is itself an error. RFC 7208 requires exactly one SPF TXT record per domain; having two makes the domain fail SPF entirely, regardless of what either record says.
4. Recheck after adding any new sending platform. New email service providers, CRM tools, or transactional senders need their own include: line, or their mail will fail authentication no matter how well-configured the rest of your record is.

How to Create or Update an SPF TXT Record

Publishing or editing an SPF record is low-risk if you follow the sequence in order. Rushing the last step is where most delivery problems start.

1. Inventory every sender first. List your marketing platform, CRM, transactional email engine, help desk tool, and anything else that sends mail using your domain. Missing one is the single most common cause of legitimate email landing in spam, since anything not listed simply fails SPF.
2. Locate the DNS records panel at your host. Most registrars and DNS providers call this “DNS management” or “Zone editor.” You’re looking for a place to add or edit a TXT record type, not an SPF-specific field, since SPF policies are published as TXT records.
3. Add an include: for each third-party service rather than listing raw IP addresses when possible. Providers publish their own SPF records and update them as their infrastructure changes, so an include stays accurate without you touching it again.
4. Publish with ~all first. This softfail setting lets you catch missed senders without bouncing real mail while you confirm the record is complete, a practice Google’s documentation explicitly recommends.
5. Monitor for a stretch before switching to -all. Once you’ve watched delivery for your major sending platforms without unexpected failures, move to a hard fail for stronger protection against spoofing.

If you’re managing multiple platforms sending on behalf of one ecommerce domain, a review of your email automation tools helps you confirm you’ve accounted for every service before you touch DNS.

Pro Tip: Keep a plain text file listing every platform included in your SPF record and the date each was added. It turns a two-minute audit into a thirty-second one the next time you onboard a new tool.

Limitations and Common Pitfalls to Avoid

SPF is genuinely useful, but it breaks in predictable ways if you don’t know its ceiling. The biggest one: SPF permits a maximum of 10 DNS lookups per evaluation. Every include:, a, mx, exists, or redirect mechanism counts toward that ceiling, and nested includes (a platform’s SPF record that itself includes another platform’s record) add up fast.

The 10-lookup limit is the most common technical cause of “permanent” SPF failures in setups that chain multiple third-party includes, according to Dmarc. Consolidating providers under fewer includes, or using a redirect= for subdomains, is the standard fix.

A few other traps show up repeatedly:

• Envelope versus visible From. SPF only authenticates the MAIL FROM address, not the header From your recipients see. A message can pass SPF while displaying a spoofed sender name, which is exactly why DMARC alignment exists.
• The deprecated SPF resource record type. An experimental DNS record type built specifically for SPF once existed but was later deprecated; today, SPF policies must be published as standard TXT records or receivers won’t find them.
• Duplicate SPF TXT records. Two separate strings starting with v=spf1 under one domain cause an automatic SPF failure, even if each one individually is written correctly.
• Void lookups. DNS queries that return no data still count against evaluation limits under RFC 7208, so stale or broken includes quietly eat into your lookup budget.

How SPF, DKIM, and DMARC Work Together

SPF answers one narrow question: is this sending IP authorized to use this domain? That’s valuable, but it’s only a third of the authentication picture. DKIM adds a cryptographic signature to the message itself, verifying the content wasn’t altered in transit and confirming it actually originated from a server holding the domain’s private key. DMARC then sits above both, setting the policy for what happens when a message fails, and critically, checking whether the domain in SPF or DKIM actually matches the visible From address.

That alignment check is what closes the gap SPF leaves open on its own. A phishing email can sometimes pass SPF using a lookalike sending domain while still displaying your brand name in the From field. DMARC is the layer that catches that mismatch and enforces a policy (quarantine or reject) instead of letting the receiving server guess.

The recommended sequence for most domains:

• Publish SPF and set up DKIM signing first.
• Add a DMARC record in monitoring mode (p=none) and review the aggregate reports it generates.
• Once reports confirm all legitimate senders pass, move DMARC enforcement to quarantine, then reject.

Skipping straight to enforcement without monitoring is how legitimate mail gets blocked. Building the role email plays in ecommerce revenue into your authentication planning makes the stakes of getting this sequence right a lot more concrete.

Troubleshooting Common SPF Failures

When a message fails SPF, the fix starts with identifying exactly which domain the receiving server actually checked, since that’s not always the domain you’d assume.

1. Confirm the MAIL FROM domain, not the visible From address, since that’s the one SPF actually evaluates. Many platforms use a subdomain (like bounce.yourdomain.com) for this purpose.
2. Pull that domain’s TXT record using dig or an SPF checker and confirm the sending platform’s IP or include is actually present.
3. Count total DNS lookups. If you’re at or near 10, that’s likely your problem, not a missing entry.
4. Consolidate nested includes or move subdomain-specific senders to a redirect= mechanism if the lookup count is the bottleneck.
5. Contact your DNS host or email provider if the record looks correct but failures persist. Bring the exact failing message’s headers and your current SPF string. Support teams move faster with specifics than with “my email isn’t working.”

Pro Tip: Save the full header of any bounced or misdelivered message before you start troubleshooting. The Received-SPF line in those headers usually names the exact domain and IP the receiver checked, which saves you a guessing game.

Why Deliverability Teams Treat SPF as Routine Maintenance

Agencies that manage email at scale for ecommerce brands don’t treat SPF as a one-time setup task. It’s an operational checklist: inventory every sender, stage changes with a softfail before enforcing, and watch bounce and open metrics for anything unusual after a change.

The misconfigurations that show up most often are mundane: a new platform for Klaviyo-driven flows gets added without an updated include, two SPF records exist because someone didn’t check before publishing, or a record inherited from an old provider still eats up lookup capacity years after that provider stopped being used. None of these are exotic problems, and none require deep engineering to fix. What they require is someone actually looking.

The payoff for catching them is concrete: fewer transactional emails bouncing, fewer campaign sends landing in spam instead of the inbox, and a more predictable relationship between what you send and what customers actually see.

An Agency Perspective on the Fixes We See Most

Most SPF problems Take-action encounters aren’t dramatic. They’re a marketing platform added six months ago that never got its include: line, or a legacy record from a provider nobody uses anymore quietly burning through the lookup limit. The fix is almost always smaller than the deliverability damage it was causing.

That gap between cause and effect is what surprises people. A single missing include can push a meaningful share of campaign volume into spam folders for months before anyone traces it back to DNS. The fix itself takes minutes once it’s identified.

If there’s one thing worth taking from this: a correct SPF record is a small configuration detail with an outsized effect on whether your emails get read at all. It’s worth the twenty minutes to check.

— Take

Let Take-action Handle Your Email Authentication Setup

Auditing SPF, DKIM, and DMARC across every sending platform you use, then keeping that setup current as you add tools, is exactly the kind of unglamorous work that determines whether your campaigns actually reach the inbox. Take-action builds this into every retention program: a full authentication audit, correct SPF and DKIM configuration, DMARC monitoring, and ongoing checks whenever a new sending platform gets added to your stack.

That ongoing piece matters more than a one-time fix. Sending tools get added and dropped as brands grow, and each change is a chance for authentication to quietly break without anyone noticing until open rates start slipping. If you’re not sure whether your current SPF record still matches every platform sending on your behalf, request a deliverability audit from Take-action and get a clear picture of where your authentication actually stands before it costs you revenue.

Where to Read the Original Standards and Provider Docs

For the full technical specification, RFC 7208 is the authoritative source on SPF syntax, mechanism evaluation, and the lookup limits discussed throughout this piece. Google Workspace Help covers practical setup and the softfail-to-hardfail testing approach. Microsoft’s documentation walks through setup scenarios for custom cloud domains. For a deeper look at how SPF, DKIM, and DMARC interact operationally, DMARC.com’s reference guide is worth bookmarking alongside a broader look at email marketing tools for small business if you’re still choosing a sending platform.

Sources

• About SPF records | Google Workspace Help
• Dmarc
• Set up SPF to identify valid email sources for your custom cloud domains | Microsoft

Recommended

• Improve Email Open Rates: A Practical Guide for Marketers
• What Is a Promotional Email? A Guide for Marketers