Last updated: 22 March 2026

SPF record missing: what it means and how to fix it

A missing SPF record means any mail server can send email claiming to be from your domain. This is one of the most common reasons emails go to spam, email authentication fails, and domains become vulnerable to spoofing. Without SPF, providers like Google and Microsoft have no way to verify your legitimate emails, hurting both deliverability and trust.

What is SPF

SPF (Sender Policy Framework) is a DNS TXT record that lists the mail servers authorised to send email on behalf of your domain. When a receiving server gets an email from your domain, it checks the SPF record to verify the sending server is allowed.

Think of SPF as a guest list for your domain's email. Only servers on the list are considered legitimate senders. Anyone not on the list is treated as suspicious.

SPF works alongside DKIM and DMARC to form a three-layer email authentication system. SPF verifies the sending server, DKIM verifies the message integrity, and DMARC ties them together with a policy and reporting. Without SPF, the first layer of that system is missing.

What an SPF record looks like

An SPF record is a TXT entry at your root domain (not a subdomain).

Here is an example record with each part explained:

How to think about SPF (simple explanation)

If you are not familiar with DNS or email infrastructure, here is the simplest way to understand SPF:

That guessing is the problem. Without a whitelist, providers like Google and Microsoft cannot tell the difference between your real emails and a spoofed message from an attacker. The result is that your legitimate emails are more likely to end up in spam, and spoofed emails are more likely to reach inboxes.

Without vs with SPF

The difference is straightforward. SPF acts as a whitelist for your domain's email senders.

Why this matters

Without an SPF record, receiving servers cannot distinguish between legitimate email from your organisation and forged email from an attacker. This creates several problems:

• Email spoofing. Attackers can send phishing emails that appear to come from your domain. Recipients and their email providers have no SPF-based signal to block these.
• Deliverability problems. Many email providers penalise or flag messages from domains without SPF. Your legitimate emails may land in spam folders instead of inboxes.
• Required for DMARC. SPF is one of the two authentication mechanisms that DMARC relies on. Without SPF, your DMARC policy cannot fully protect your domain.
• Compliance requirements. Google and Yahoo now require SPF for bulk senders (5,000+ emails per day). Missing it can result in rejected messages.
• Brand damage. Spoofed emails erode trust in your brand. If recipients receive phishing from your domain, your reputation suffers.

SPF is now a standard requirement for modern email security and is expected by major providers like Google and Microsoft. It is no longer optional for domains that send email.

How to tell if this is your issue

Not sure if a missing SPF record is causing your problem? These are common signs that point to SPF-related email authentication issues:

• Your emails are going to spam. If recipients report that your messages land in junk or spam folders, a missing SPF record is one of the most common causes. Email providers use SPF as a basic trust signal when deciding where to place messages.
• Email authentication is failing. If you see "authentication failed" or "SPF: NONE" in email headers, your domain has no SPF record for receivers to check against.
• Google or Microsoft flagged your domain. Both providers send alerts when they detect authentication gaps. If you received a notification about sender verification, check your SPF record first.
• Your DMARC setup is not working. DMARC depends on SPF (and DKIM) to function. If DMARC reports show SPF failures, the record may be missing or misconfigured.
• You are setting up email on a new domain. Adding an SPF record should be one of the first things you do when configuring email for a new domain, alongside DMARC.
• A domain health scan flagged this issue. Tools like 1Pane check for SPF as part of a broader domain health assessment. If this was flagged, the record is either missing or invalid.

When this becomes a problem

A missing SPF record does not always cause immediate failures, but the risk grows over time. The impact becomes visible when:

• Someone spoofs your domain. Phishing attacks using your domain can happen at any time. Without SPF, there is no server-level check to flag them.
• You send transactional email. Order confirmations, password resets, and invoices from your application need SPF to reach inboxes reliably.
• You scale email volume. Bulk senders are now required to have SPF by major providers. Without it, your deliverability drops. This is also affected by DNS resolution issues that prevent records from being found.
• You add a new email service. If you start using a new tool that sends email on your behalf (marketing platform, CRM, helpdesk) and it is not in your SPF record, those emails will fail authentication.
• A customer reports phishing. At that point you are already dealing with the consequences rather than preventing the problem.

How to fix it properly

Follow these steps to add SPF to your domain and prevent email spoofing at the server level.

Step 1: Identify all services that send email for your domain

Before writing your SPF record, list every service that sends email using your domain name. Common sources include:

• Your email hosting provider (Google Workspace, Microsoft 365, Zoho)
• Marketing platforms (Mailchimp, HubSpot, ActiveCampaign)
• Transactional email services (SendGrid, Postmark, Amazon SES)
• Helpdesk or CRM tools (Zendesk, Freshdesk, Salesforce)
• Your own application servers (if they send email directly)

Each of these needs to be included in your SPF record. Check the common includes table above for the correct values.

Step 2: Create your SPF record

Combine all your senders into a single TXT record. For example, a domain using Google Workspace and SendGrid:

The ~all at the end means "soft fail" for any server not on the list. This flags unauthorised senders without outright rejecting them, which is safer while you are still verifying your setup.

Step 3: Add the record to your DNS

Log in to your DNS provider and add a TXT record at the root domain (@) with your SPF value. If your domain has DNS resolution issues, resolve those first, as the SPF record will not be reachable.

Step 4: Verify the record

After adding the record, verify it is live. DNS propagation usually takes a few minutes to a few hours. You can check by running:

Look for a record starting with v=spf1 in the output. Or use a 1Pane domain health scan to verify.

Step 5: Tighten your policy

Once you have confirmed that all legitimate senders are included and email is flowing correctly, consider changing ~all (soft fail) to -all (hard fail) for stricter enforcement:

Step 6: Set up DMARC

SPF on its own verifies the sending server, but it does not tell email providers what to do when checks fail. Add a DMARC record to define a policy and start receiving reports about your email authentication.

Common mistakes

• Multiple SPF records. Your domain must have exactly one SPF TXT record. If you need multiple includes, combine them into a single record. Having two SPF records causes both to be ignored.
• Using +all. Setting +all allows any server to send email as your domain. This defeats the purpose of SPF entirely. Use ~all or -all instead.
• Missing senders. If you add SPF but forget to include a service that sends email for you (such as a CRM, helpdesk, or marketing tool), those emails will start failing delivery. Audit all your sending services before publishing.
• Exceeding the 10-lookup limit. Each include: and redirect= adds to the lookup count. Nested includes within those also count. If you hit the limit, SPF validation fails entirely. Use ip4: or ip6: for known static IPs to reduce lookups.
• Adding SPF to a subdomain. SPF records must be at the root domain, not at a subdomain (unless you send email from that subdomain specifically). A record at mail.yourdomain.com does not protect yourdomain.com.
• DNS propagation delay. After adding the record, allow up to 48 hours for full propagation. Most changes take effect within a few hours. If the record is not appearing, check for DNS resolution issues.

How 1Pane detects this

During a domain health scan, 1Pane queries the TXT records at your root domain and looks for a record starting with v=spf1. If none is found, the scan flags SPF as missing. 1Pane also checks for common misconfigurations like +all policies, the 10-lookup limit, and duplicate records.

1Pane checks SPF alongside related issues including missing DMARC records and DNS resolution failures. Changes between scans are tracked, so you can verify that your fix has taken effect.

Frequently asked questions

Do I need SPF if I already have DMARC?

Yes. DMARC does not replace SPF. DMARC defines what happens when authentication fails, but it relies on SPF (and DKIM) to perform the actual checks. Without SPF, DMARC has nothing to enforce on the server verification side. You need both.

Can I have more than one SPF record?

No. Your domain must have exactly one SPF TXT record. If you need to authorise multiple email services, combine them into a single record using multiple include: entries. Having two separate SPF records causes email providers to treat both as invalid.

How long does SPF take to work?

Most DNS changes propagate within a few minutes to a few hours. In rare cases, full global propagation can take up to 48 hours. Once the record is live, email providers will start checking it immediately. If the record is not appearing after several hours, check for DNS resolution issues.

Will adding SPF stop all spam from my domain?

SPF stops unauthorised servers from passing sender verification, but it does not block all types of spoofing on its own. For full protection, combine SPF with DKIM and DMARC. Together, these three protocols cover server verification, message integrity, and policy enforcement.

Related issues

These domain health issues are closely related to SPF and email authentication: