Fixing "SPF Fail: Domain Does Not Designate Permitted Sender"

Introduction

The error "SPF Fail: Domain Does Not Designate Permitted Sender" means the mail server that delivered the message is not authorized in the SPF record for the domain being checked. Receiving mail servers compare the sending IP against the SPF TXT record published in DNS. If the IP is not listed, SPF returns fail.

This error is common after adding a new email provider, switching hosting, enabling a contact form plugin, or sending through a third-party SMTP service without updating DNS. The fix is to identify which server actually sent the mail, then update your SPF record so that source is included.

Quick answer

What SPF fail domain not permitted means

When a receiving server checks SPF, it looks at the domain in the envelope sender — also called the Return-Path or MAIL FROM address. It fetches the SPF TXT record for that domain and checks whether the connecting IP address is permitted. A fail result means the IP is not authorized.

Common reasons SPF returns fail:

• the sending IP is not listed in the SPF record
• the wrong include mechanism is used for your provider
• a new SMTP provider was added but SPF was not updated
• multiple SPF records exist on the same domain
• SPF exceeds the 10 DNS lookup limit (PermError, treated as fail)
• a WordPress or contact form plugin sends through hosting SMTP not in SPF
• a third-party CRM, newsletter or transactional service is missing from SPF
• shared hosting sends mail but only Google Workspace is authorized
• SPF passes for one domain but DMARC alignment fails on the From domain

SPF and DMARC work together but check different things. SPF validates the Return-Path domain against the sending IP. DMARC checks whether SPF or DKIM aligns with the visible From address and applies your policy. Fixing SPF alone may not fix DMARC if alignment is wrong.

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Why this matters

Unauthorized senders that pass without SPF checks can also damage your domain reputation. A correct SPF record tells receivers which servers are allowed to send on your behalf.

How to check

Start by finding the actual sending server and comparing it to your published SPF record.

1. Send a test email to a mailbox you control (Gmail, Outlook or similar).
2. Open the message headers and find the Return-Path / envelope sender domain.
3. Note the sending IP address from Received headers.
4. Run SPF Checker on the Return-Path domain to see the live SPF record.
5. Confirm the sending provider’s include mechanism appears in SPF.
6. Check for multiple SPF TXT records on the same domain.
7. Review SPF lookup count — more than 10 nested lookups causes PermError.
8. Check whether a WordPress plugin, contact form or CRM sends through a different SMTP server.
9. Review DMARC alignment — SPF may pass on Return-Path but fail DMARC on the From domain.
10. Re-run SPF Checker after any DNS change and allow time for propagation.

Common problems

How to fix

1. Step 1: Find the sending server

   Send a test message and read headers to identify the Return-Path domain and sending IP address.

2. Step 2: Check the live SPF record

   Run SPF Checker on the Return-Path domain and note existing includes, ip4 entries and lookup count.

3. Step 3: List all sending sources

   Document every service that sends mail: workspace, hosting, CRM, forms, newsletters and transactional providers.

4. Step 4: Add the missing include or IP

   Edit your single SPF TXT record to include the provider mechanism. Do not create a second SPF record.

5. Step 5: Fix contact form and plugin SMTP

   Configure WordPress and contact forms to send through an authorized SMTP provider instead of unauthenticated PHP mail.

6. Step 6: Resolve lookup limit issues

   If lookup count exceeds 10, flatten nested includes or switch to your provider’s consolidated SPF value.

7. Step 7: Verify and test

   Wait for DNS propagation, re-run SPF Checker, then send another test and confirm SPF pass in message headers.

8. Step 8: Monitor DMARC reports

   After SPF passes consistently, review DMARC aggregate reports to confirm alignment before tightening policy.

Examples

Problem:
SPF Fail: example.com does not designate permitted sender

Headers show:
Return-Path: bounce@example.com
Sending IP: 198.51.100.42

Live SPF record:
v=spf1 include:_spf.google.com ~all

Cause:
Mail was sent through SendGrid (198.51.100.42),
but SPF only authorizes Google Workspace.

Fix:
v=spf1 include:_spf.google.com include:sendgrid.net ~all

Verify:
Run SPF Checker → confirm SendGrid include resolves.
Send test → headers show spf=pass.

Frequently asked questions