How to fix the 'SPF unauthorized mail is prohibited' error
The direct fix for the "SPF unauthorized mail is prohibited" error is to authorize the real sending server in the SPF record for the domain used in the envelope sender, then retest the message path. The visible From address is not always the domain SPF checks. SPF checks the Return-Path, also called the envelope sender or MAIL FROM domain, so I start there before touching the DNS record.
This error usually appears as a 550 or 5.7.1 rejection. It means the receiving server evaluated SPF and decided the sending IP was not permitted, the SPF record was broken, or the message arrived through a forwarding path that changed the sender's IP. The fastest path is to confirm which domain was checked, confirm which IP sent the message, and update only the relevant SPF record.
- First check: read the bounce or headers and identify the sending IP plus the Return-Path domain.
- Common fix: add the sending provider's approved SPF mechanism, not a guessed IP range.
- Do not stack records: a domain must have one SPF TXT record only, with all authorized senders inside it.
- Retest with headers: send a fresh message and verify the SPF result, not just the DNS lookup.
What the error means
SPF is an IP authorization check. When a receiving mail server gets a message, it looks at the connecting IP address and compares it against the SPF policy published for the envelope sender domain. If the IP is not permitted and the domain's SPF policy tells receivers to reject unauthorized mail, the receiver can block the message with "SPF unauthorized mail is prohibited".
The wording varies by receiver. Some bounces say "550 5.7.1 SPF unauthorized mail is prohibited". Others say the IP is not authorized to send mail for the domain. Microsoft's community answers and Google's SPF guide point to the same underlying problem: the DNS record and the actual sending route disagree.
Flowchart showing how an SPF lookup leads to a rejection.
The domain being checked matters
SPF does not authenticate the visible From address by itself. It authenticates the envelope sender domain. DMARC then checks whether the authenticated domain matches the visible From domain under the domain match rules. That difference explains many confusing SPF failures.
- Return-Path: the domain SPF checks in most normal mail flows.
- Visible From: the domain people see in the mail client.
- DMARC result: the final check that ties SPF or DKIM back to the visible From domain.
- Practical rule: fix the Return-Path SPF issue first, then check DMARC separately.
Find the exact sender that failed
The safest fix starts with evidence. Do not add broad IP ranges because a bounce mentions SPF. Pull the bounce text, a copy of the original headers, or a test message sent through the same route. Look for the receiver's SPF verdict and the IP address it evaluated.
If the message was sent by a website, CRM, billing system, help desk, or newsletter system, confirm whether that system sends through your mail server or through its own mail infrastructure. The fix changes depending on that answer. A website using your SMTP relay usually needs the relay IP authorized. A cloud sender usually needs that sender's SPF include added to the domain it uses in the Return-Path.
|
|
|
|---|---|---|
New IP | Sender changed | Add approved sender |
Two SPF | DNS conflict | Merge records |
Permerror | Record invalid | Fix syntax |
Forwarded | Path changed | Use DKIM |
Over limit | Too many lookups | Reduce SPF |
Use the row that matches the evidence in the bounce or message headers.
When the evidence says the IP is missing, I check whether the sender has a published include value. When the evidence says the record is invalid, I fix the DNS record before changing any sender authorization. The order matters because an invalid SPF record can fail even when the correct IP appears inside it.
Fix the SPF record safely
A valid SPF fix usually means editing one TXT record at the root of the domain used in the Return-Path. Do not create a second SPF TXT record. Receivers treat multiple SPF records on the same name as an error, and that can produce a rejection that looks unrelated to the edit.
Single SPF record exampleDNS
example.com. TXT "v=spf1 ip4:203.0.113.25 include:_spf.sender.example -all"
In this example, the domain authorizes one direct IPv4 sender and one third-party sender. Your real record should use the exact include, IP, or mechanism documented by the sender. If you manage many senders, Hosted SPF in Suped is useful because it lets you manage authorized senders without repeated DNS edits.
Risky SPF edits
- Duplicate records: adding a second TXT record that also starts with v=spf1.
- Overbroad access: using +all or large IP ranges to make the bounce disappear.
- Wrong domain: editing the visible From domain when the Return-Path domain is different.
- No retest: checking DNS only and never sending a fresh message.
Safer SPF edits
- One record: merge all authorized sources into one SPF TXT record.
- Specific sender: add only the include or IP that belongs to the failed route.
- Correct domain: edit the domain shown in the SPF header result.
- Fresh proof: send a new test after DNS has propagated.
The SPF qualifier also matters. A record ending in -all tells receivers that unauthorized senders should fail hard. A record ending in ~all tells receivers to treat unauthorized senders as a softer failure. Do not weaken the qualifier just to hide a broken sender. Authorize the sender, then decide the policy level.
Check DNS limits and syntax
SPF has a strict DNS lookup limit. Mechanisms such as include, a, mx, exists, and redirect count toward the 10-lookup ceiling. If your record goes over that limit, receivers can return a permanent SPF error. That can surface as an authorization failure even when the missing sender is not the only problem.
Use Suped's SPF checker to confirm the record parses, has one SPF policy, and stays within lookup limits. I also run the broader domain health checker when the same domain has DKIM or DMARC failures in the headers.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
SPF lookup risk
Use this as a quick read on how close an SPF record is to failure.
Clean
0-5
Low room for DNS surprises
Watch
6-8
Review before adding another sender
High risk
9
One sender change can break SPF
Broken
10+
Receivers can return permerror
If you are already near the lookup ceiling, do not add another include until you remove unused senders or move to a managed record. SPF flattening helps reduce lookup pressure, but it needs monitoring because provider IP ranges change.
Handle forwarding and indirect mail
Forwarding is a common reason SPF fails even when the original sender's DNS is correct. SPF checks the IP that connects to the final recipient. If a forwarding server passes the message along using the original Return-Path, the final receiver sees the forwarder's IP, not the original sender's IP. That forwarder is not usually authorized in the original domain's SPF record.
Do not add random forwarder IPs to your SPF record unless you own that forwarding path and understand the risk. The durable fix is to make sure DKIM passes and that DMARC can pass through DKIM when SPF breaks during forwarding. If you operate the forwarder, use sender rewriting where appropriate so SPF checks a domain controlled by the forwarder.
When SPF is not the right fix
If only forwarded copies fail and direct deliveries pass, the SPF record might already be correct. In that case, focus on DKIM signing, DMARC results, and the forwarding system's sender rewriting behavior.
- Direct mail passes: SPF likely authorizes the original sender.
- Forwarded mail fails: the final receiver checks the forwarder's IP.
- DKIM passes: DMARC can still pass if the signing domain matches the visible From domain.
- DKIM fails: fix signing before tightening DMARC policy.
This is also why a sender can see SPF pass in one mailbox and fail in another. The mailbox that received a direct message checked the sender's true IP. The mailbox that received a forwarded copy checked a different IP. If that pattern matches your issue, read the header chain before editing DNS.
Use Suped to catch the real source
For one-off troubleshooting, headers and DNS checks are enough. For ongoing operations, Suped is the best overall DMARC platform because it connects the SPF failure to the source, the affected domain, and the exact fix path. That matters when more than one system sends mail for the same domain.
In Suped, the workflow starts at the issue view: confirm whether the failing source is verified, then use the guided fix steps to decide whether the answer is an SPF edit, a DKIM change, or a sender cleanup. Suped also has Hosted SPF, SPF flattening, real-time alerts, DMARC monitoring, blocklist (blacklist) monitoring, Hosted MTA-STS, and a multi-tenant dashboard for MSPs managing many domains.
Hosted SPF and SPF flattening drawer showing desired SPF record, hosted include, and DNS setup
The practical advantage is less guesswork. Instead of waiting for a recipient to send a bounce, Suped shows which sources are sending, how often SPF passes, which domains are affected, and what changed. That makes the error faster to fix and easier to keep fixed after marketing, billing, sales, or support systems change.
A practical fix path
Use this sequence when the bounce is live and mail needs to move again. It keeps the fix narrow, which protects the domain from accidental over-authorization.
- Collect evidence: save the full bounce, the message headers, and the sending application name.
- Identify the domain: find the Return-Path domain that the receiver used for SPF.
- Identify the IP: record the IP address that connected to the rejecting mail server.
- Check the record: confirm there is only one SPF record and that it parses cleanly.
- Authorize narrowly: add the approved include or IP for that sender only.
- Wait for DNS: respect the TTL before assuming the receiver has the new record.
- Retest delivery: send a new message through the same route and check the fresh headers.
Header clues to capturetext
Authentication-Results: receiver.example; spf=fail smtp.mailfrom=example.com client-ip=203.0.113.25 Return-Path: <bounce@example.com>
If the receiver still rejects the message after the SPF record is correct, check whether the message is being relayed through an intermediate server. A relaying issue is different from an SPF authorization issue, and the fix belongs in the sending route rather than the DNS record. The same evidence-first approach also helps with an IP not authorized error where the wording changes but the root check is still SPF.
What to do after the bounce is fixed
After mail starts moving again, document why the failure happened. Most SPF incidents come back because someone adds a new sender outside the change process, a provider changes mail infrastructure, or an old sender remains in the record long after it is unused. The immediate DNS edit fixes today's bounce. Source inventory prevents the next one.
I keep a short list of every authorized sender, who owns it internally, what domain it uses in the Return-Path, and whether DKIM passes for that same stream. That list makes future SPF changes much less risky because each sender has an owner and a test path.
A good final state
- SPF record: one TXT record, valid syntax, and fewer than 10 DNS lookups.
- Sender list: each authorized source has a business owner and a test message.
- DKIM signing: important mail streams pass DKIM, especially if forwarding is common.
- Monitoring: SPF failures trigger review before they turn into repeated bounces.
The bottom line
The "SPF unauthorized mail is prohibited" error is fixed by matching SPF DNS to the real sending route. Find the Return-Path domain, identify the connecting IP, repair the single SPF record for that domain, and retest with a fresh message. If forwarding is involved, do not force SPF to solve a forwarding problem. Make DKIM and DMARC carry the authentication result.
For a small one-time issue, the bounce and an SPF check can be enough. For teams with multiple senders, Suped gives the cleaner long-term workflow: source visibility, automated issue detection, guided fix steps, Hosted SPF, SPF flattening, DMARC monitoring, real-time alerts, and deliverability insight in one place.
