Skip to content
SEO Optimizer is live, Audit on page SEO and AI-search readiness. Try it free

How to Fix a Missing or Broken SPF Record

An SPF record is a DNS TXT record that lists the servers allowed to send email for your domain. Without one, anyone can send mail that claims to be from you and receiving servers have no way to tell. With a broken one, your own invoices and newsletters can land in spam. This guide covers how to fix the two common problems: no SPF record at all, and a record that is invalid or incomplete.

How an SPF Record Works

When a mail server receives a message, it looks up the SPF record of the sending domain and checks whether the sending server's IP address is on the list. A typical record looks like this:

example.com TXTAn SPF record for Google Workspace plus a newsletter service
v=spf1 include:_spf.google.com include:servers.mcsv.net ~all
PartMeaning
v=spf1Marks the record as SPF. Must come first.
include:Also allow the servers listed in another domain's SPF record, usually your email provider's.
ip4: / ip6:Allow a specific IP address or range, such as your own mail server.
a / mxAllow the IPs in your domain's A or MX records.
~allSoftfail: mail from other servers is suspicious. Usually delivered but marked.
-allFail: mail from other servers is not authorized.

SPF on its own does not tell receivers to reject anything, and it checks the hidden envelope sender rather than the From address people see. That is why it works together with DKIM and DMARC. The DMARC guide explains how the three fit together.

Fix 1: No SPF Record Found

If a security scan reports "No SPF record found", your domain has no TXT record starting with v=spf1. The scan checks the main domain even if you entered a www address, because email records live on the apex domain.

  1. List every service that sends email as your domain. Your mailbox provider (Google Workspace, Microsoft 365, Zoho), newsletter and marketing tools, your CRM, help desk, billing and invoicing system, and your website or store if it sends order emails.
  2. Find each service's SPF value. Every provider documents the include: to add, usually under "authenticate your domain" or "custom domain".
  3. Write one record with all of them, ending in ~all while you test.
  4. Add it as a TXT record on the apex domain (the host is often shown as @) at your DNS provider.

If the domain never sends email, publish v=spf1 -all. That tells receivers that no server is allowed to send for it, which is the right setup for parked and unused domains.

Fix 2: More Than One SPF Record

A domain must have exactly one. Two TXT records that both start with v=spf1 cause a permerror, and receivers treat SPF as failed. This often happens when a new tool's setup guide says "add this SPF record" and someone adds a second one instead of merging. Merge them into one record with all the include: values, then delete the extra.

Fix 3: Too Many DNS Lookups

SPF allows at most 10 DNS lookups while checking a record. Each include, a, mx, exists and redirect counts, and so do the includes inside the records you include. Go over the limit and SPF returns a permerror, so the whole check fails.

  • Remove services you no longer use. Old tools are the most common cause.
  • Replace a and mx with the actual ip4: ranges if they are stable. IP mechanisms do not count as lookups.
  • Move bulk senders to a subdomain such as news.example.com with its own record. Many newsletter tools support this.
  • Be careful with "SPF flattening" services. They replace includes with IP lists, but those lists go stale when providers change their IPs.

Scanverra's scan checks whether the record exists, not how many lookups it uses. To count lookups, use an SPF validator or the command line tools below and follow each include.

Fix 4: Syntax Errors

  • The record must start with exactly v=spf1 followed by a space.
  • Use include: with a colon, not include=.
  • Put the all mechanism last. Anything after it is ignored.
  • Do not use +all. It allows every server on the internet to send as you.
  • The deprecated SPF DNS record type (type 99) is no longer used. Publish SPF as TXT only.

~all or -all?

Both work once DMARC is in place, because DMARC decides what happens to failing mail. Start with ~all while you confirm every sender is listed, so a forgotten service does not lose mail. Move to -all once your DMARC reports show all legitimate mail passing. For domains that never send mail, use -all from the start.

Test the Record

Check that the record is published and that there is only one:

terminalLook up the SPF record
dig +short TXT example.com | grep spf1
# or on Windows
nslookup -type=TXT example.com

Then send a test email to a Gmail address, open it, choose "Show original" and confirm SPF shows PASS. Run a security scan again to clear the "No SPF record found" finding, and check that DKIM and DMARC are reported as present too. A missing SPF record rarely comes alone.

الأسئلة الشائعة

الأسئلة الشائعة

Your domain has no DNS TXT record starting with v=spf1, so receiving mail servers cannot check whether a sending server is allowed to send for you. Anyone can send mail that appears to come from your domain.

No. A domain must have exactly one SPF record. Two records cause a permerror and SPF fails. Merge all the include values into one record.

Use ~all while you confirm every legitimate sender is listed, then switch to -all. With DMARC in place, DMARC decides what happens to failing mail either way.

SPF allows at most 10 DNS lookups when a record is checked, including lookups inside included records. Going over makes SPF fail with a permerror. Remove unused includes or use IP ranges to stay under it.

Yes. Publish v=spf1 -all so receivers know no server may send for the domain. Pair it with a DMARC record of p=reject to stop spoofing.

مجاني - بدون تسجيل

Check this on your own site

Run a free scan and see exactly where you stand - no sign-up required.

تشغيل الفحص المجاني