A Postfix server managed through Control Web Panel attempted direct delivery to Gmail and received:
550-5.7.1 The IP you're using to send mail is not authorized
to send email directly to our servers. Please use the SMTP relay
at your service provider instead.
The delivery status was 5.7.1, the action was failed, and Gmail returned the rejection after the message data was submitted. This is a permanent policy failure for that attempt, not a temporary queue delay.
The important part is the exact text. It does not say merely “SPF missing,” “DKIM failed” or “IP reputation is low.” Google is rejecting direct SMTP from the network range and explicitly recommends a relay.
What the bounce proves
The delivery-status notification shows:
- the local MTA accepted the message from the sender;
- DNS located a Gmail MX;
- the server established an SMTP session with Gmail;
- Gmail evaluated the sending IP and message;
- Gmail rejected it with a permanent authorization policy response.
This rules out several early-path failures. Port 25 was not simply blocked outbound, and the recipient domain’s MX was reachable. Retrying the same direct path with the same IP is not a repair.
Redact public IP addresses, local hostnames, sender and recipient addresses, queue IDs and message IDs before sharing a bounce publicly. They are valuable in a private incident ticket but unnecessary in a general guide.
Why SPF, DKIM, DMARC and PTR are not the direct fix
These controls remain necessary for responsible email delivery:
- SPF authorizes sending infrastructure for the envelope domain;
- DKIM signs the message with a domain key;
- DMARC checks alignment and publishes policy/reporting;
- PTR and forward DNS establish a coherent sending-host identity.
However, none can override a provider policy that classifies the IP range as unauthorized for direct mail. Google’s specific IP-not-authorized guidance says the ISP supplying the address determines whether it is authorized; consumer broadband ranges commonly fall into the refused category. Google does not offer an exception or allowlisting request.
Adding an SPF record containing the rejected IP may make SPF pass while Gmail continues returning the same 550. Setting PTR on a consumer or unsuitable range may improve identity but still not grant direct-send authorization.
Choose a supported delivery architecture
There are three legitimate options.
1. Use the ISP’s authorized SMTP relay
Ask the connectivity provider whether the service includes an authenticated or IP-authorized relay for business mail. Confirm submission hostname, port, TLS requirements, authentication method, sender-domain restrictions and rate limits.
2. Use a transactional or hosted SMTP provider
Select a provider that accepts authenticated message submission and delivers from its authorized infrastructure. Verify that it supports the required From domains, DKIM signing, bounce handling and traffic type. Marketing, transactional and ordinary mailbox traffic may have different policies.
3. Move direct delivery to suitable hosting
Operate Postfix on infrastructure whose provider permits mail, delegates reverse DNS and supplies a stable address. This creates ongoing obligations: abuse handling, updates, reputation, authentication, monitoring, complaint processing and queue operations. A static IP alone is not a deliverability guarantee.
For the error shown, a relay is normally the fastest controlled fix.
Prepare before changing CWP/Postfix
Control panels can regenerate Postfix configuration. First record:
postconf -n
postconf -M
postqueue -p
Back up the active Postfix configuration and note which files CWP owns. Use CWP’s supported relay/smarthost interface when the installed version provides one. If the panel has no supported mechanism, document the manual customization so a CWP update or mail-server rebuild does not silently remove it.
Do not paste relay credentials into screenshots, shell history, support tickets or article drafts.
Generic authenticated relay configuration
The exact settings come from the chosen provider. A standard Postfix submission pattern is:
relayhost = [smtp.provider.example]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt
Then /etc/postfix/sasl_passwd contains the matching destination and credential:
[smtp.provider.example]:587 account-name:application-password
The bracketed hostname and port must match exactly in both locations. The official Postfix SASL guide explains that brackets suppress MX lookup, port 587 is the submission service, TLS protects authentication and the password map must use the same destination form.
Protect and compile the map:
chmod 600 /etc/postfix/sasl_passwd
postmap /etc/postfix/sasl_passwd
postfix check
postfix reload
Use the map type supported by the installed Postfix build; postconf -m lists available database types. Some systems use lmdb instead of hash.
Never use a normal mailbox password if the provider offers scoped SMTP credentials or application passwords. Store and rotate the secret through the organization’s password-management process.
Update sender authentication for the relay
The infrastructure visible to recipients changes after relaying, so review DNS and signing.
SPF
Authorize the relay using the exact mechanism the provider publishes. Do not invent its IP ranges and do not create multiple SPF TXT records at the root; combine authorized sources into one valid policy. Remove the old direct IP only after confirming it no longer sends legitimate mail.
DKIM
Determine whether CWP signs before relaying, the provider signs with the customer domain, or both signatures are present. Confirm that at least one aligned signature survives transit and validates. A relay that rewrites message content can invalidate an upstream signature if it is not designed for that flow.
DMARC
Start with reporting if the domain has not been monitored, inspect legitimate sources, then move to the organization’s intended enforcement policy. DMARC alignment—not the mere existence of records—matters.
Google’s current email sender guidelines require all senders to use SPF or DKIM, valid forward and reverse DNS and TLS. Higher-volume senders must meet additional SPF, DKIM, DMARC, alignment and subscription-message requirements.
Test the new path
Send a new message and follow the log:
tail -f /var/log/maillog
The path should show the configured relay as the next hop, successful TLS and SASL negotiation, and an accepted relay queue response. It should no longer show direct delivery from the original server to Gmail’s MX.
At the recipient, inspect full headers and verify:
- the relay is present in the
Receivedchain; - SPF passes for the expected envelope domain;
- DKIM passes for the expected signing domain;
- DMARC passes through alignment;
- the visible From address is unchanged;
- the message is not rewritten unexpectedly.
Also test another recipient domain, a bounce to an invalid address and the CWP queue after restart. Confirm that credentials remain protected and that a control-panel update does not revert relayhost.
Do not confuse nearby 550 errors
Gmail uses 550 5.7.1 for several policies. The Gmail SMTP error reference lists distinct cases involving unsolicited mail, reputation, missing headers, IPv6 authorization and sender policy.
Always follow the diagnostic sentence and linked help page in the bounce. A low-reputation rejection calls for different evidence from an unauthorized consumer IP. A missing-From rejection is a message-format problem. A 5.7.26 SPF hard failure is an authentication problem.
For “The IP you’re using to send email is not authorized,” the repair is architectural: stop direct delivery from that IP. Relay through authorized infrastructure, then align SPF, DKIM, DMARC and monitoring with the new path.
