How to resolve SPF SOFTFAIL errors when moving to a dedicated IP address?
Updated on 11 Oct 2026: We updated the dedicated IP migration checks for authoritative DNS, cached SPF answers, and authentication before increasing volume.
Fix SPF SOFTFAIL on a new dedicated IP by checking the domain in the envelope sender, confirming that domain has exactly one SPF TXT record, and making sure the new IP or its sending include is inside that one record. The header often describes this result as 'domain does not designate IP as permitted sender.' In most migrations, the problem is not that the IP is new. The problem is that Gmail evaluated a return-path domain whose SPF record did not authorize that IP.
Check DKIM and DMARC while the SPF fix is in progress. During IP warming, clean authentication matters. With a typical policy ending in ~all, softfail means the connecting IP did not match an earlier authorization mechanism. That is a sender authorization issue, not a reputation verdict by itself.
The fastest practical path is to fix the SPF record first, then send a real test message to Gmail and read the Authentication-Results and Received-SPF headers. If SPF, DKIM, and DMARC pass on the direct test message, continue warming at a controlled pace. If it still shows softfail, trace the return-path domain and the reported client IP again before touching unrelated DNS records.
Fix SPF SOFTFAIL at the return-path domain
The direct fix is to publish one valid SPF record for the hostname used in the return-path of the message. If you added the dedicated IP as a second SPF record, remove the duplicate and merge the mechanisms into the existing SPF record. A DNS hostname can have multiple TXT records for different purposes, but it must not have multiple SPF records beginning with v=spf1. Duplicate SPF policies produce permerror under the SPF standard. With a typical softfail policy, the receiver found one usable policy, no earlier mechanism matched the connecting IP, and evaluation reached ~all.
- Use the message header to find the return-path or envelope sender domain that Gmail evaluated.
- Verify exactly one applicable SPF TXT record, following a CNAME if the return-path is delegated.
- Keep the shared route and the dedicated route in that policy, using only the includes or IP mechanisms your provider requires.
- Send a real message and confirm SPF pass in the received header, not only in a DNS lookup.
Combine SPF TXT recordsdns
Before, invalid: mail.example.com. TXT "v=spf1 include:_spf.shared.example.net ~all" mail.example.com. TXT "v=spf1 include:_spf.dedicated.example.net ~all" After, one SPF record: mail.example.com. TXT ( "v=spf1 " "include:_spf.shared.example.net " "include:_spf.dedicated.example.net " "ip4:203.0.113.44 " "~all" )
The parenthesized version above is still one TXT record in DNS. It is not multiple SPF records. DNS providers display long TXT values in different ways, so the important part is the resource record count: one hostname, one TXT answer that starts with v=spf1. Each quoted TXT string is limited to 255 octets, but one record can contain several strings. DNS joins them without inserting spaces, so preserve spaces between SPF mechanisms. See RFC 7208. The example IP and include domains are placeholders; replace them with your provider's published values.
Do not add another SPF record
Multiple SPF records at the same hostname produce SPF permerror, so merge authorized sources into one policy. With a typical ~all policy, softfail means the connecting IP did not match any preceding authorization mechanism. Diagnose the result shown in the live header. RFC 7208 advises receivers not to reject a message solely because of softfail; it does not guarantee acceptance or inbox placement.
Why the dedicated IP exposed the problem
Moving to a dedicated IP changes the IP address that receivers compare against SPF. Shared pools often passed because their provider include already covered the shared infrastructure. The dedicated IP can sit behind a different include path, a newly assigned pool, or a return-path host that was not updated. That is why the same subdomain can pass from shared IPs and softfail from the dedicated IP.
|
|
|
|
|---|---|---|---|
Duplicate SPF | SPF permerror | Combine into one | High |
Wrong host | Return-path differs | Update that host | High |
Missing IP | IP absent from chain | Add include or IP | High |
Wrong address family | Header shows IPv6 | Add ip6 or include | High |
DNS cache | Live header uses old policy | Check authoritative DNS and old TTL | Medium |
Lookup limit | SPF permerror | Reduce lookups | High |
No SPF policy | SPF none | Check the exact host and publish SPF | High |
DNS timeout or SERVFAIL | SPF temperror | Repair DNS availability and retest | High |
SPF results and causes during a dedicated IP migration
A new dedicated IP does not inherit the SPF behavior of the old shared route. SPF authorizes the connecting IP against the policy for the envelope sender domain. If the provider changes either side of that comparison, verify the whole path instead of assuming the old DNS still applies.
SPF compares the dedicated IP with the return-path domain's SPF record
Check the domain and IP Gmail evaluated
Start with the Gmail header, not the DNS zone editor. SPF is checked against the envelope sender domain, which appears in Gmail's authentication results as the SMTP mail-from domain. That domain can differ from the visible From domain and from the branded subdomain you expect to be in use. For a null envelope sender, such as a bounce with Return-Path: <>, SPF uses the HELO/EHLO domain. This exception is defined in RFC 7208.
Gmail authentication headertext
Return-Path: <bounce@bounces.mail.example.com> Authentication-Results: mx.google.com; spf=softfail smtp.mailfrom=bounces.mail.example.com; dkim=pass header.d=mail.example.com; dmarc=pass header.from=example.com Received-SPF: softfail (domain does not designate 203.0.113.44 as permitted sender) client-ip=203.0.113.44; envelope-from=bounce@bounces.mail.example.com;
In that example, SPF is about bounces.mail.example.com. If you edit mail.example.com but the return-path is bounces.mail.example.com, Gmail will keep evaluating the unchanged policy. If a cloud sending route uses its own return-path domain, SPF for your visible subdomain is not the deciding record for that message. SPF records are not inherited by subdomains. See RFC 7208. The DKIM and From domains in this example share example.com, so the DMARC pass assumes relaxed DKIM domain matching. With adkim=s, they must match exactly. See RFC 9989.
- In Gmail, open the message, choose "Show original", and read the Authentication-Results added by mx.google.com and its Received-SPF header. Record the SMTP mail-from domain and client IP.
- Look up TXT records for that exact hostname, not the parent domain unless the header uses it.
- If the header reports IPv6, confirm the policy has a matching ip6 mechanism or a provider include that covers it; an ip4 mechanism does not authorize IPv6.
- Follow provider includes and any redirect to confirm that the dedicated IP is covered by a mechanism reached during evaluation.
- Check whether DKIM passed with a domain that meets the DMARC policy's relaxed or strict domain matching requirement.
- Retest after DNS changes and compare the new header with the old one.
Suped's SPF checker is useful here because it exposes the parsed SPF mechanisms and lookup count before you send another warm-up message. For a related failure path, the IP authorization guide covers what to do when the IP is not authorized anywhere in the SPF chain.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
The checker tells you whether DNS is structurally correct. The live Gmail message tells you what the receiver actually evaluated at delivery time. Use both because cached DNS, provider routing, and return-path changes can make a DNS-only check look cleaner than the message that just landed in the inbox. If Gmail evaluated a forwarding server's IP rather than your dedicated IP, repeat the test directly to Gmail before changing SPF. Forwarding that preserves the original envelope sender changes the connecting IP, as described in RFC 7960.
What to change in DNS
For a migration where the old shared IPs and the new dedicated IP send from the same return-path domain for a while, the SPF record needs to authorize both routes at the same time. Do not replace the old include too early, and do not create a second SPF record for the new route. Remove the old route only after it has stopped sending and its queued retries have drained.
Bad migration pattern
- Duplicate policy: One SPF record authorizes shared IPs and another authorizes the dedicated IP.
- Wrong hostname: The visible sending subdomain is updated, but the return-path host is not.
- Too many includes: Every sender is added without checking SPF's DNS lookup limit.
Clean migration pattern
- Single policy: One SPF record contains the shared include and the dedicated route.
- Correct hostname: The return-path domain in the header is the domain you edit in DNS.
- Lookup control: The combined SPF record stays within the DNS lookup limit.
The limit applies to ten DNS-causing terms during evaluation, including nested provider includes: include, a, mx, exists, ptr, and redirect. Direct ip4 and ip6 mechanisms do not consume that lookup allowance. If the combined policy has too much lookup pressure, SPF flattening or managed sender authorization can keep the policy within the limit. Remove unused senders first. If you flatten provider includes, keep the resulting IP ranges refreshed when the provider changes them.
Minimal dedicated IP additiondns
mail.example.com. TXT ( "v=spf1 " "include:_spf.shared.example.net " "ip4:203.0.113.44 " "~all" )
Use a direct IP mechanism only when the dedicated IP is yours to list directly and your sending provider expects that. Use ip4 for IPv4 and ip6 for IPv6. If the provider gives you an include, use that include. If a hosted SPF service controls the record, make the sender change there so the generated DNS stays consistent. Place the new IP or include before ~all; mechanisms after all are ignored. A record using redirect= must not also contain all, because that disables the redirect. See RFC 7208.
Verify authoritative DNS and cached SPF answers
When a DNS lookup looks correct but Gmail still softfails, compare authoritative name servers with cached answers. Replace the example hostname below with the return-path domain. Use the trace to identify the authoritative servers for its zone, then replace ns1.example.net and ns2.example.net with those servers.
Inspect SPF DNS answers and delegationbash
dig bounces.mail.example.com TXT +noall +answer dig bounces.mail.example.com CNAME +noall +answer dig +trace bounces.mail.example.com TXT dig @ns1.example.net bounces.mail.example.com TXT +norecurse dig @ns2.example.net bounces.mail.example.com TXT +norecurse
- Compare every authoritative server and check the aa flag. If they disagree, fix the zone update or delegation before waiting for caches. RFC 2181 distinguishes authoritative answers from cached data.
- If the custom return-path is a CNAME, check the target's TXT policy and ask the provider to authorize the dedicated IP there. Do not add a TXT record beside the CNAME. RFC 2181 prohibits that combination.
- Once authoritative answers agree, allow the previous TTL for cached policies to expire, then send another direct test. Check TTLs for changed include or CNAME targets too. Lowering TTL after the edit does not shorten existing caches. See RFC 1034.
- For the next migration, lower TTL at least one previous TTL before the cutover, then restore it after successful tests.
When to resume dedicated IP warming
Pause volume increases while SPF is duplicated, malformed, or missing the dedicated IP. If authoritative DNS is correct but Gmail still uses an old cached answer, wait out the previous TTL and send a small direct test again. Resume the planned increase after SPF, DKIM, and DMARC pass on that test. Google's sender guidelines require SPF and DKIM for senders exceeding 5,000 messages per day to personal Gmail accounts, plus a DMARC record; passing DMARC through DKIM alone does not replace those requirements.
Warm-up readiness after SPF testing
Check a direct Gmail test and authoritative DNS before increasing volume; authentication is only one warm-up requirement.
Proceed
Authentication passes
SPF, DKIM, and DMARC pass on the direct test message.
Wait briefly
TTL cache
Authoritative DNS agrees, but the live test still uses an old policy. Retest after the previous TTL.
Pause
Invalid SPF
The checked SPF policy has duplicates, syntax errors, or no authorization for the dedicated IP.
SPF is only one warm-up signal. Dedicated IPs also need reputation checks, complaint control, bounce monitoring, and blocklist (blacklist) visibility. Confirm forward and reverse DNS for the new IP as a separate readiness task, but do not expect a PTR change to repair SPF. A direct-message softfail is an SPF authorization result. A blocklist or blacklist listing is a separate filtering signal. Treat them separately so you do not chase the wrong root cause.
DMARC caveat
DMARC passes when either SPF or DKIM passes and its authenticated domain meets the visible From domain's matching requirement. Relaxed mode requires the same organizational domain; strict mode requires an exact domain match. RFC 9989 defines these rules. DKIM can keep DMARC passing while SPF is repaired, but continue fixing SPF before increasing dedicated IP volume.
How Suped fits the workflow
Suped's DMARC and email authentication platform groups authentication results by sending source. During a dedicated IP migration, use that source view to identify the reported IP and authentication domain, verify whether the source is expected, and compare failure counts after the DNS correction. Aggregate reports arrive after receiving systems process traffic, so confirm the immediate fix with a live message header.
When DNS access is slow or split across teams, Suped's Hosted SPF lets authorized senders be managed after the initial DNS setup without repeated manual DNS edits. Its automatic SPF flattening reduces lookup usage and refreshes provider IP ranges. Suped's DMARC monitoring alerts the team when reported authentication failures rise during the warm-up period.
SPF flattening drawer showing an over-limit record, sender editing, lookup counts, and the hosted record setup
After correcting SPF, run Suped's domain health checker to check SPF syntax and lookup limits, DKIM selector records, and DMARC reporting configuration. Verify the selector used in the actual message separately, and check forward and reverse DNS with the sending provider.
Practical Suped workflow
- Identify the dedicated IP source in DMARC reports and confirm that it is expected for the domain.
- Update the single SPF policy or its hosted sender configuration without creating a duplicate record.
- Confirm SPF, DKIM, and DMARC pass in a live message, then watch source-level failure counts as reports arrive.
- Investigate renewed authentication failures before increasing volume.
Confirm authentication before increasing volume
Once SPF passes on a direct message, verify DKIM and DMARC before increasing volume. Keep the corrected return-path domain, client IP, and test headers in the migration log. If authentication passes but delivery remains poor, use the SMTP responses and complaint data to investigate reputation or rate limits.
Frequently asked questions
The dedicated IP is not authorized by the SPF record for the return-path domain Gmail checked. Shared IPs can pass because a different provider include covered them. Compare the exact client IP in the header, including whether it is IPv4 or IPv6, with that policy.
Pause volume increases if SPF is duplicated, malformed, or missing the dedicated IP. If the remaining issue is cached DNS, wait for the previous TTL and retest. Resume the planned increase after a direct message shows SPF, DKIM, and DMARC pass.
You need SPF on the domain used in the return-path. The visible From domain matters for DMARC domain matching, but SPF itself checks the envelope sender domain. When SPF passes for a provider-owned return-path domain, it does not satisfy DMARC domain matching for your From domain; DKIM must provide the matching pass unless you configure a matching custom return-path.
No. Changing ~all to -all changes an unmatched result from softfail to fail, but it does not authorize the missing IP. Never use +all to hide a migration problem. Add the correct include, ip4 mechanism, or ip6 mechanism to the single SPF record.
First confirm that every authoritative server publishes the corrected policy. Then allow up to the previous TTL for ordinary cached answers to expire. An old 24-hour TTL means some receivers retain the old answer for up to 24 hours after the correction reaches authoritative DNS. If softfail continues after that, recheck the return-path, client IP, and DNS delegation.
