Gmail 550 5.7.1 'Not Authorized to Send Email Directly': Fixing Direct-to-MX Blocks

550 5.7.1 The IP you're using to send email is not authorized to send email directly to our servers. Please use the SMTP relay at your service provider instead. means Gmail looked at the IP address that connected to it and decided that address should not be delivering mail itself. It is the kind of address, usually a home, office or dynamic one, that is supposed to hand mail to a relay, and the relay delivers it. Nothing is wrong with your list or your content. The fix is to change the path the mail takes.

What the error is and isn't

The message is in Google's Gmail SMTP errors and codes list (last updated 26 October 2026, read 2 November 2026): "The IP you're using to send email is not authorized to send email directly to our servers." Google's advice is in the same line: use your provider's SMTP relay.

It is	It isn't
A judgement about the connecting IP	A judgement about your domain's reputation
Permanent for that IP	A rate limit that clears if you slow down
The same for every Gmail recipient	A problem with one mailbox
Fixed by sending through a relay	Fixed by cleaning the list

If your error says "very low reputation of the sending IP" instead, that is a reputation problem with its own guide: Gmail low reputation. If it says "not RFC 5322 compliant", see Gmail 550 5.7.1 not RFC 5322 compliant.

Who gets it

Sender	Why it happens
A script on a laptop or office machine that connects to Gmail's MX	It is sending from the office or home connection's IP
An app, website or CRM on a small server that delivers its own mail	The server's IP is in end-user or dynamic space
A scanner, printer or alarm system set to "send directly"	Same, and these rarely support relays well without setup
A self-hosted mail server on a home broadband line	Residential IPs are the classic case
A self-hosted server on a cloud VM	Some cloud ranges are treated as end-user space, and many providers block port 25 anyway

On the last point, our cloud providers block port 25 guide lists which providers block outbound mail by default and how to ask for it to be opened.

The Spamhaus PBL connection

Many of the IPs Gmail refuses here are on the Spamhaus Policy Blocklist (read 2 November 2026). Spamhaus describes the PBL as "end-user IP address ranges from which email should never be sent directly to the final destination", and says "A PBL listing is NOT a result of any actions undertaken by the end users." ISPs and network owners add their own ranges.

So a PBL listing is a statement about the type of address, not a black mark. You can check an IP at check.spamhaus.org, or run it through our IP blacklist check, which queries Spamhaus ZEN and labels a PBL answer as a policy listing rather than a spam listing.

Spamhaus says removals are handled only at check.spamhaus.org, and that whether an end-user IP can be removed depends on the network owner's policy. If you are on a static business IP and run a real mail server, removal can be possible. If you are on a dynamic consumer line, it usually is not, and the relay is the answer.

Fix 1: Send through a relay (the usual answer)

Point the sending software at an authenticated SMTP server instead of at Gmail's MX. Which one depends on what is sending:

Sending	Relay to use
A person's mailbox, or a script sending as that person	The mailbox provider's submission server, for example Google Workspace or Microsoft 365, on port 587 with login
An app or website sending notifications	An email sending service, authenticated with an API key or SMTP credentials
An office device	The organisation's mail server, or the provider's device relay option
A small mail server	A "smarthost" setting that sends everything through a sending service

Our SMTP settings lookup gives the host, port and security settings for the common providers.

When you relay, the relay's IP is the one Gmail sees. Make sure your domain's SPF record includes the relay, and that the relay signs DKIM with your domain, or you will swap this error for an authentication one. The SPF checker and DKIM checker confirm both.

Fix 2: Run a proper mail server on an IP you control

If you need to deliver mail yourself, Gmail expects what it expects from any sender. Google's sender guidelines (read 2 November 2026) require, for all senders:

• A PTR record. "The public IP address of a sending SMTP server must have a corresponding PTR record that resolves to a hostname." The host name should resolve back to the same IP. Check it with the reverse DNS lookup. Our guide to reverse DNS and PTR records explains how to set one through your IP provider.
• SPF or DKIM, and for bulk senders SPF, DKIM and DMARC with the From domain aligned.
• TLS. "Use a TLS connection for transmitting email."
• A static IP outside policy blocklists. A dynamic IP changes, and its range is likely on the PBL.

Even then, a new IP has no history. Start with low volume to people who expect your mail and build up slowly. For anything that looks like bulk or outreach mail, a sending service with established IPs is the safer route; see shared vs dedicated IP for the trade-off.

The IPv6 variant

Google lists a related 550 5.7.1: the message doesn't meet Gmail's IPv6 sending guidelines for PTR records and authentication. It shows up when a server has an IPv6 address and prefers it for outbound mail, and that address has no PTR record or the mail is not authenticated.

Two ways out:

1. Make IPv6 meet the same bar. Add a PTR record for the IPv6 address that resolves to a host name that resolves back to it, and make sure SPF includes the IPv6 address (with an ip6: mechanism) and DKIM signs the mail.
2. Send over IPv4 only. In Postfix, setting inet_protocols = ipv4 makes outbound connections use IPv4. Other mail servers have a similar setting. This is the quick fix when the IPv4 address is already set up correctly.

A quick way to tell what IP you are sending from

Send a message to a Gmail address that does get through (from the same machine, using another path if needed), or to any mailbox you control, and open the raw headers. The top Received: line, added by the receiving server, shows the IP that connected to it. The email header analyzer lays out each Received hop in order. Compare that IP to the one in the bounce, and check its reverse DNS: a host name containing words like "dynamic", "dsl", "cable" or a long string of numbers is a strong sign you are on end-user space.

Where SimpleVerifier fits

This block is about your sending path, so verification can't clear it. If you're building a sender of your own, verification belongs earlier in the flow: SimpleVerifier runs a live mailbox check on each address and returns safe to send, send with care, check again later or do not send, with the reason, so the mail you send through your new relay goes to addresses a server confirmed. Catch-alls stay risky, never guessed valid. The API checks one address per call.

The first 100 checks are free with a Google sign-in on the verify page. Pro is $39 a month with the first 100,000 checks a month at full speed, then slower, never cut off, and includes 10,000 API calls a month. See pricing.