Why is my IP address not authorized to send email and how do I fix it?
Published 25 May 2025
Updated 20 Oct 2026
12 min read
Summarize with
Updated on 20 Oct 2026: We clarified SPF authorization, relay settings and policy-list removal conditions for unauthorized sending IP errors.
If your IP address is not authorized to send email, check the full SMTP rejection first. Gmail's instruction to use your provider's SMTP relay means the receiving server is refusing direct delivery from that IP. The most common fix is to stop sending directly from that IP and send through the SMTP relay provided by your ISP, hosting provider, or email service. If you have a static IP that the provider approves for mail, ask the ISP to confirm that it is allowed for direct SMTP, resolve any policy listing, and verify the server's forward and reverse DNS. Then check SPF, DKIM and DMARC for the sending domain.
Treat the exact Gmail-style rejection as a policy problem first. A message like 550 5.7.1 The IP you're using to send mail is not authorized usually points to the IP provider's policy, a policy blocklist or blacklist entry, or direct-to-recipient sending outside a network's permitted sending policy. It is different from an SPF failure or a low-reputation rejection, even though those responses can share the 550 5.7.1 status code.
If Gmail says your sending IP is not authorized to send directly, use the provider's SMTP relay or ask the ISP to confirm the IP policy. The Google help page makes the IP provider central to that decision and says Google cannot allowlist the IP or make an exception.
What Gmail's unauthorized IP error means
This rejection happens before the inbox placement question. The exact response says the connecting IP address is not permitted to act as a direct sender. Authentication-related rejections require their own diagnosis; always read the full response.
Typical Gmail rejectiontext
550-5.7.1 [203.0.113.10] The IP you're using to send mail is not authorized 550-5.7.1 to send email directly to our servers. Please use the SMTP relay 550-5.7.1 at your service provider instead. 550 5.7.1 gsmtp
Two types of authorization are often confused. An IP policy issue means the IP range is designated unsuitable for direct delivery, either by the network owner or a policy-list operator. A domain authorization issue means the evaluated SPF record does not authorize the system that sent the message. Read the complete SMTP text, not only the 550 5.7.1 code, because low IP reputation and other Gmail rejections can use the same status code.
Gmail also uses 5.7.25 for missing or mismatched PTR records, and 5.7.26 for authentication-related rejections. Compare the complete response with Google's SMTP error reference before choosing a fix.
IP policy rejection
- Signal: The receiver tells you to use your provider's SMTP relay.
- Cause: The IP range is designated unsuitable for direct delivery; a policy listing is one possible reason.
- Owner: Your ISP or hosting provider confirms the permitted route and any removal conditions.
SPF authorization failure
- Signal: The receiver reports an SPF failure for the evaluated domain and sending IP.
- Cause: The evaluated SPF policy does not authorize that sender, or the record has an error.
- Owner: The DNS owner of the evaluated domain controls the SPF update.
Flowchart for diagnosing an unauthorized sending IP: check direct delivery, IP policy and SPF, then use a relay and retest.
Common causes of unauthorized sending IP errors
Start with the IP before changing the domain record. If only one or two IPs in a pool fail while others keep delivering, the affected IPs need separate policy and reputation checks. Do not assume the whole pool has the same status.
|
|
|
|---|---|---|
Policy Blocklist (PBL) | IP range is designated unsuitable for direct delivery | Confirm policy; use relay or eligible removal |
Relay | Direct SMTP is not allowed | Use SMTP relay |
SPF | Envelope sender domain does not authorize IP | Update that domain's SPF |
PTR | Reverse DNS is missing or forward DNS does not return the sending IP | Correct PTR and A or AAAA records |
EHLO/HELO | SMTP greeting has an invalid or unsuitable hostname | Use a valid mail server hostname |
Reputation | IP has a poor sending history | Stop abuse and rebuild |
Related checks and the fix each requires
- Policy listing: A PBL entry means the IP is designated unsuitable for direct mail delivery. It can cover static as well as dynamic addresses and does not, by itself, mean the IP has sent spam.
- Consumer range: Residential and dynamic ranges, plus some cloud ranges, are commonly restricted by provider policy. Confirm the specific network's rules before attempting direct delivery.
- Missing SPF: The domain's SPF record authorizes one platform, but the message leaves through a different IP. Use Suped's SPF checker when you need to see the parsed result.
- DNS limits: SPF returns PermError when evaluation exceeds its limit of 10 DNS-causing terms, including nested includes. SPF flattening can reduce lookup pressure, but the flattened data must stay current as sender IP ranges change.
- Identity checks: The PTR hostname should resolve back to the sending IP, and EHLO or HELO should identify the server. The visible From domain does not have to match that server hostname.
Blocklist checker
Check your domain or IP against 144 blocklists.
A blocklist check answers a narrow question: is this exact IP or domain appearing on a list that receivers use as a policy or reputation signal? It does not prove Gmail used that blacklist directly, and it does not measure the IP's complete reputation. It gives you evidence for the next conversation with your ISP.
How to fix it step by step
The right fix depends on whether the problem belongs to the IP owner or the domain owner. Use this order to avoid wasted DNS changes when the IP itself is not allowed to send direct mail.
- Capture evidence: Save the full SMTP rejection, sending IP, timestamp, sender domain, recipient domain, queue ID, and hostname. Use the public IP shown in the rejection, including any NAT or IPv6 route.
- Check policy status: Look up the exact IP for policy listings or abuse-related blacklists, and read the listing's stated reason.
- Ask the ISP: Ask whether the IP is approved for direct outbound SMTP on port 25 and whether the provider has published a policy entry for that range.
- Use the relay: If the provider says direct sending is not allowed, route mail through the provider's SMTP relay, an authenticated MSA, or mail infrastructure that permits outbound delivery.
- Fix DNS identity: Ask the IP provider to set PTR and confirm the hostname's A or AAAA record points back to that IP. Use a valid EHLO/HELO hostname, configure SPF and DKIM for the actual sender, and check DMARC.
- Retest delivery: Send a small controlled test after relevant DNS caches expire. Confirm SMTP acceptance and the intended public sending IP, then inspect the receiver-added Authentication-Results header for SPF, DKIM and DMARC results.
If the IP appears on a PBL-style policy blocklist (blacklist), read the entry's removal conditions. Some policies allow the operator of an assigned static outbound mail-server IP to request a single-IP exclusion when forward and reverse DNS are correct. If the network owner forbids direct SMTP or controls removal, use its relay or ask it to correct the policy. Do not request removal for an ordinary dynamic client IP.
A 550 response is a permanent failure for that delivery attempt. Make the required routing or policy change before resending.
If the receiver explicitly reports an SPF authorization failure, update the SPF TXT record for the actual SMTP MAIL FROM domain. Subdomains do not inherit the parent domain's SPF record. Keep one SPF record at that name and place new include, ip4 or ip6 mechanisms before the final all mechanism. The 10-term DNS lookup limit includes nested evaluations; ip4 and ip6 do not count toward it, as defined in RFC 7208.
Illustrative SPF record, replace the example valuesdns
example.com. TXT "v=spf1 ip4:203.0.113.10 include:_spf.example.net -all"
203.0.113.10 is a documentation address, and _spf.example.net is a placeholder. Replace them with the real sending IP and the provider's documented include. Use -all once every legitimate sender is covered. Never use +all as a workaround because it authorizes every IP.
For more complex sender stacks, Suped's Hosted SPF lets approved users manage senders without giving every marketing or operations team direct DNS access. That matters when the unauthorized IP problem comes from forgotten platforms, stale includes, or a sender added outside the normal change process.
SPF flattening drawer showing an over-limit record, sender editing, lookup counts, and the hosted record setup
Choose the right sending route
The Gmail wording refers to direct delivery to recipient MX servers, normally over port 25. It does not mean the same IP can never submit a message. An authenticated SMTP relay (smarthost) or mail submission agent (MSA) can accept the message and deliver it from an authorized sending network.
Use the relay's documented submission hostname and SMTP AUTH credentials. Common secure submission options are port 587 with required STARTTLS or port 465 with implicit TLS, as specified in RFC 8314. These ports connect to the relay's submission endpoint; final delivery between mail servers still uses port 25.
|
|
|
|---|---|---|
Provider relay or MSA | The ISP blocks direct delivery | Authenticated submission |
Own-domain relay | An authorized server exists elsewhere | Restricted relay access |
Direct to MX | The provider approves the IP for mail | Mail-eligible static IP and forward-confirmed rDNS |
Sending routes for an unauthorized IP
A static IP does not automatically qualify for direct-to-MX email. If the provider offers business or static IP service, confirm in writing that the assigned range is approved for direct outbound SMTP before moving the mail server. Never configure an unrestricted open relay.
When SPF is the real problem
SPF normally checks the SMTP MAIL FROM (envelope sender) domain, which becomes the delivered Return-Path. It does not directly authenticate the visible From address. For messages with an empty MAIL FROM, such as delivery notifications, SPF uses the EHLO/HELO domain. DMARC passes when SPF or DKIM passes with a domain that meets DMARC's matching rules for the visible From domain.
SPF DNS lookup limit
Count DNS-causing terms actually evaluated, including nested includes. The 10-term limit is a protocol rule; the lower bands are operational guidance.
Comfortable margin
0-7 terms
The evaluation has room for sender changes without nearing the protocol limit.
Near the limit
8-10 terms
The lookup count is within the limit, but another include or redirect can exhaust it.
PermError
11+ terms
An evaluation that exceeds 10 DNS-causing terms returns SPF PermError.
If you already placed the IP in SPF and it still fails, check whether the message is using the domain you updated. This is where many fixes fail. The return-path can use a subdomain, a vendor domain, or a bounce domain that has a separate SPF record. A deeper walkthrough is available for cases where SPF still fails even after the IP appears in DNS.
A clean SPF fix has one SPF TXT record for each evaluated domain, only current senders, no duplicate SPF records, and no unmanaged includes. Use Suped's SPF checks to investigate duplicate records or lookup-limit errors before changing authorized senders.
If the issue started after moving to a new sender or dedicated IP, confirm that the actual public IPv4 or IPv6 address is authorized. An unmatched sender reaches ~all as softfail or ?all as neutral; changing the qualifier does not add the missing sender. When the failure is tied to a migration, the notes on SPF softfail errors are the next useful check.
What to ask your ISP or host
The ISP conversation has to be specific. A generic ticket saying Gmail is rejecting my mail usually gets a generic response. Include the exact rejection, the IP, the sending hostname, and a clear question about whether the IP range is authorized for direct outbound SMTP.
Ask the provider this: Is 203.0.113.10 authorized under your network policy to send direct outbound SMTP to recipient MX servers, or should it only send through your SMTP relay? If it is authorized, please confirm the policy blocklist status for the range and the reverse DNS required for mail service.
If the provider says nothing changed, ask them to check the actual listing or routing policy for the affected IPs, not only the account settings. Adjacent IPs in a pool can behave differently because policy data, reverse DNS, reputation, or prior use differs by address. If direct sending is restricted, ask whether business service or a mail-eligible static IP is available, but get explicit confirmation that the replacement range permits direct SMTP.
- Port policy: Confirm that outbound SMTP on port 25 is permitted for direct delivery, not only open at the firewall.
- Range policy: Ask whether the provider has submitted the range to a policy blacklist and whether single-IP exclusions are permitted.
- Reverse DNS: Request a stable PTR hostname with an A or AAAA record that resolves back to the same sending IP. This is forward-confirmed reverse DNS, required by Gmail's sender guidelines.
- Relay route: Get the provider's supported SMTP relay hostname, submission port, TLS mode and authentication settings if direct sending is not allowed.
For a broader authentication check, run the domain through Suped's domain health checker after the provider confirms the IP policy. That order matters: domain checks are useful, but they cannot override a network owner saying the IP should not send direct mail.
Use Suped to track sender authorization
Suped is our DMARC reporting and email authentication platform. It combines DMARC reports with authentication checks and issue-specific steps for investigating senders.
That workflow helps when an unauthorized IP problem crosses team boundaries. DMARC aggregate data can identify which sources send for the domain, Hosted SPF can control approved senders without broad DNS access, and issue steps can keep a policy blacklist entry separate from an SPF failure. Aggregate reports do not cover every SMTP connection, so keep the rejection and server logs as the primary evidence for this error. Relay policy still has to be confirmed by the IP provider.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Manual troubleshooting
- Evidence: You collect SMTP errors, DNS records, logs, and IP status in separate places.
- Ownership: DNS, infrastructure, and marketing teams trade screenshots and ticket updates.
- Risk: The same unauthorized sender returns after a platform or IP change.
Suped workflow
- Evidence: Compare reported sending IPs and SPF or DKIM results with the affected IP in your server logs.
- Ownership: Hosted SPF lets approved users manage senders without raw DNS access.
- Risk: Alerts and issue steps help investigate changes that reintroduce an unauthorized sender.
Frequently asked questions
Gmail is rejecting direct SMTP from an IP that the network owner or policy data says should not send mail directly. Use the provider's SMTP relay or ask the ISP to confirm the IP is mail-eligible. Google does not allowlist IPs or make exceptions for this rejection.
Only if the rejection is an SPF authorization failure for the evaluated domain. Add the actual sending IP or the provider's documented include to that domain's existing SPF record. If the IP itself is restricted by network policy, SPF changes will not fix direct-to-MX rejection.
Read the listing's policy. Some permit an assigned static mail-server IP's operator to request a single-IP exclusion; others require the network owner to act. If the provider says the range must use its relay, route through that relay instead.
Each IP can have different reverse DNS, prior use, policy status, and reputation. Test the failing IPs individually instead of assuming the whole pool has the same status.
Send the full SMTP rejection, affected public IP, timestamp, sending hostname, sender domain, and a direct question asking whether the IP is authorized for direct outbound SMTP.
