Fix Missing SPF Record on Your Sending Domain

What's happening

Sender Policy Framework (SPF), defined in RFC 7208, is a TXT record at the apex of your domain that lists every IP or hostname authorized to send mail on your behalf. When a receiving MTA (Gmail, Microsoft 365, Yahoo, Fastmail) sees an inbound message, it queries the envelope-from domain for that TXT record and compares the connecting IP against the listed mechanisms. No record means no answer to the question "is this sender legitimate?".

Receivers treat a missing SPF record as a soft signal that the domain is unmanaged. Combined with a lack of DKIM or DMARC it pushes the message into the bulk/spam folder, and for newer Gmail accounts (post-Feb 2024 bulk-sender enforcement) it can produce hard rejects with the bounce text "5.7.26 unauthenticated email is not accepted".

SPF is also the foundation for DMARC alignment. Without a published SPF record, the SPF leg of your DMARC check always fails, so DMARC enforcement (p=quarantine or p=reject) becomes impossible without first publishing SPF.

Why it matters

Bulk Gmail senders without SPF are immediately deprioritized — Google Postmaster Tools shows the domain reputation drop within 24 hours of a high-volume send. Microsoft 365 routes the same mail to Junk Email with the X-Microsoft-Antispam header showing CAT:SPM and SCL:5 or higher.

Transactional mail (password resets, receipts, magic links) is affected first because users actively look for it; when it lands in spam, support tickets spike and password-reset abandonment climbs. A missing SPF record also lets attackers spoof your domain freely — DMARC cannot protect a domain that has no SPF or DKIM in the first place.

For B2B SaaS, missing SPF is one of the top three reasons large prospects flag your domain as untrustworthy during procurement security reviews. Mail-Tester scores drop by roughly 1.5 points the moment SPF is absent.

Common causes

• Domain was set up at a registrar but never had email DNS records added.
• SPF record was deleted during a DNS migration between providers.
• ESP (Mailgun, SendGrid, Postmark) onboarding was skipped or only partially completed.
• SPF was published on a subdomain (mail.example.com) instead of the apex envelope-from domain.
• TXT record was published with the wrong type (CNAME or A) and is invisible to SPF lookups.

Detect this on your site

Run a quick scan with the Email Checker. The tool surfaces this exact issue with the records and context needed to apply the fix below.

How to fix it

1. 1

   Inventory every service that sends as your domain

   List your transactional ESP (SendGrid, Postmark, Resend), marketing ESP (Mailchimp, Customer.io), CRM (Salesforce, HubSpot), and Google Workspace or Microsoft 365. Each one has a documented SPF include such as include:_spf.google.com or include:spf.mailgun.org. Missing one of these is the most common reason for legitimate mail to fail SPF after publication.

2. 2

   Compose a single SPF TXT record

   Open a text editor and assemble one record starting with v=spf1, followed by include: mechanisms for each provider, then ~all (softfail) for initial rollout. Do not exceed 10 DNS lookups total — count each include, a, mx, exists, redirect, and ptr. Use ~all instead of -all until you confirm no legitimate flow is broken.

3. 3

   Publish the TXT record at the apex

   In Cloudflare DNS, Route 53, Google Domains, or Namecheap, add a new TXT record with name @ (or your bare domain) and the value from step 2. Set TTL to 300 seconds during initial rollout so corrections propagate quickly, then raise to 3600 once stable.

4. 4

   Verify with dig and Mail-Tester

   Run dig +short TXT example.com and confirm exactly one v=spf1 line returns. Send a test message to a fresh address at mail-tester.com and read the SPF row of the report — it must say "SPF passes with the IP". If it says "SPF softfails", your sender IP is not in the include list.

5. 5

   Tighten the all qualifier once stable

   After two weeks of clean dmarc reports and no support tickets about missing mail, change ~all to -all (hardfail). This signals receivers to reject any unlisted source instead of merely marking it suspicious, and is required for DMARC reject policies to be meaningful.

Example

example.com.    300    IN    TXT    "v=spf1 include:_spf.google.com include:spf.mailgun.org include:sendgrid.net ~all"

Single SPF TXT record at the apex covering Google Workspace, Mailgun, and SendGrid.

Related fixes