550 5.7.1 Invalid Credentials for Relay: Which of the Three Mismatches You Hit
If your app just got 550 5.7.1 Invalid credentials for relay back from smtp-relay.gmail.com, your password is almost certainly fine. The bounce is about identity, not credentials. Google accepted the connection, looked at who the message claimed to be from, and could not tie that to anything registered in your relay settings.
Three separate misconfigurations produce that same sentence: a From domain your registered IP was never allowed to send for, a domain that is not registered in your Workspace account at all, and a server announcing an unregistered name in its HELO greeting. Each has a different fix. You can tell which one is yours by reading two settings in the Admin console, which is faster than changing things and resending.
Start from your relay settings, not from the bounce
The relay has two knobs, and between them they decide whether you ever see this error.
The first is Allowed senders. Google gives three choices, and the wording matters:
- Only registered Apps users in my domains: the sender must be a Google Workspace user in one of your domains.
- Only addresses in my domains: the sender does not have to be a Workspace user, but the address must contain your primary domain. Subdomains are allowed.
- Any addresses (not recommended): the sender address can be anything, including addresses outside your domain.
The second is how the connection proves who it is. You get IP address authentication, where the relay only accepts mail from IPs you listed, or SMTP authentication, which Google describes as enforcing SMTP AUTH to identify the sending domain, with a TLS connection required. Both are documented on Google's SMTP relay settings page.
Here is the part people miss. An IP address proves which machine is connecting. It does not prove which domain the mail belongs to. So the relay falls back on the envelope and the greeting to work that out, and if those do not line up with a domain it knows, you get this bounce.
Mismatch one: a From domain your registered IP was never allowed to send for
This is the common one, and Google's own text for the error says so directly: the IP address you registered in the relay service does not match the domain of the account the email is being sent from.
It usually happens after something benign. You add a second brand, or a client's domain, or a noreply@ on a domain you bought separately, and you point the same server at the same relay. The IP is still on the list, so the connection opens. Then the relay reads a From domain it was not told about and refuses.
If your Allowed senders is set to Only addresses in my domains and the address you are sending from is not in your primary domain or a subdomain of it, that is your answer. Nothing about the server changed. The envelope did.
Mismatch two: a domain that is not registered anywhere in the console
The second case is broader. The domain in the message was never added to your Workspace account, so there is nothing for the relay to match against, whatever IP you connect from.
The ones that catch people:
- A domain bought for a campaign and pointed at the same mail server, but never added as a secondary domain in Workspace.
- A domain added to Workspace but never verified, so it is present in the list and not yet usable.
- A subdomain like
mail.yourcompany.comused in the envelope when onlyyourcompany.comis registered. This one is allowed under Only addresses in my domains, so if it is failing, check which Allowed senders option you are actually on.
Adding the domain and verifying it is the fix. There is no relay setting that works around an unregistered domain, and switching to SMTP AUTH will not help here either, because the authenticating user still belongs to a domain Google knows and the message still does not.
Mismatch three: the name your server announces in HELO
Before any of the above, your mail server introduces itself. RFC 5321 section 4.1.1.1 defines that greeting: the client identifies itself with EHLO or HELO and gives its own domain name. Google's documented resolution for this error is to configure your mail server to use SMTP AUTH or to present a registered domain name in the HELO/EHLO command, which tells you the greeting is load-bearing.
Most stacks do not set it on purpose. They send whatever the host is called. On cloud instances that produces greetings like ip-10-0-1-5.ec2.internal or localhost.localdomain, neither of which is a domain you registered. The message is fine, the IP is fine, and the introduction is a name Google has never heard.
Check what your server actually sends before you assume it is correct. In Postfix that is myhostname and smtp_helo_name; most application-level SMTP libraries let you set the EHLO name explicitly and default to the machine hostname when you do not.
The settings grid that tells you which mismatch is yours
Read your two settings, find the row, and you have the answer without a test send.
| Allowed senders | Authentication | What must be true for the message to pass |
|---|---|---|
| Only registered Apps users in my domains | IP address | The From address is a real Workspace user in a registered domain, and the HELO name is a registered domain |
| Only addresses in my domains | IP address | The From domain is your primary domain or a subdomain of it, and the HELO name is a registered domain |
| Any addresses | IP address | The HELO name is a registered domain. This is the row where HELO is usually the culprit, because the From address is no longer being checked |
| Any of the three | SMTP AUTH over TLS | The authenticated user identifies the sending domain, so the HELO name stops deciding the outcome |
The last row is why "turn on SMTP AUTH" gets handed out as the universal fix on forums. It does resolve mismatch three reliably, because the login now supplies the identity the greeting was failing to supply. It does nothing for mismatch two.
Why "Mail relay denied" is a different bounce
Google documents these as two separate errors, and people file them together. They are not the same complaint.
| Error | What it means |
|---|---|
| Mail relay denied | The sending IP or domain is not registered at all, or the HELO and MAIL FROM identification is malformed |
| Invalid credentials for relay | The connection is recognised, but the identity in the message does not line up with what you registered |
One is "I do not know you." The other is "I know you, just not for this domain." If you are seeing Mail relay denied, start with whether the IP is on the list at all. If you are seeing this error, the IP is almost always already on the list, and the problem is downstream of that.
What no amount of retrying will fix
The 550 is a permanent rejection and the 5.7.1 is a policy rejection. Under RFC 3463 section 3.8, the X.7.X class covers security and policy status, and 5.7.1 specifically means delivery was not authorised and the message was refused. Requeueing the same message re-presents the same identity and gets refused again. There is no backoff that helps.
It is also not a quota problem, which is worth stating because the relay's limit errors are easy to confuse with an access error when both arrive as a bounce mid-run. Google lists the quota errors separately and by name on its SMTP relay error messages page:
- Daily SMTP relay limit exceeded for customer
- Peak SMTP relay limit exceeded for customer
- Daily SMTP relay limit exceeded for user
- Your message has too many recipients
That last one is the one most often mistaken for a daily cap. The relay accepts up to 100 recipients in a single SMTP transaction, and the documented fix is to start another transaction, either a new connection or an RSET, rather than to wait. The per-user relay ceilings are separate again: 10,000 messages and 10,000 unique recipients per user in 24 hours.
And if you do switch to SMTP AUTH to solve mismatch three, note what it costs you. TLS is required, which means port 587 for the authenticated setup. The unauthenticated ports Google lists are 25, 465 and 587, and on those, IP authentication becomes mandatory. So you are not choosing between two equal options. You are choosing between proving the machine and proving the account, and only one of those proves the domain.
Frequently asked questions
Does 550 5.7.1 Invalid credentials for relay mean my SMTP password is wrong?
No. A wrong or rejected password comes back as a 535 authentication failure, not this. This error means the connection was accepted but the domain in your message could not be matched to anything registered in the relay settings, so it is an identity problem rather than a credentials problem despite the wording.
Will retrying the message eventually get it through?
No. The 550 is a permanent rejection and the 5.7.1 is a policy refusal, so a retry re-presents the same identity and gets the same answer. You have to change the registered domain, the From address, the HELO name, or the authentication method before the message will be accepted.
What is the difference between this error and Mail relay denied?
Mail relay denied means the sending IP or domain is not registered with the relay at all, or the HELO and MAIL FROM identification is malformed. Invalid credentials for relay means the relay does recognise the connection, but the identity carried in the message does not line up with what you registered for it.
Does switching to SMTP AUTH fix every version of this error?
It fixes the case where an unregistered HELO name is what the relay was objecting to, because the authenticated login then supplies the sending domain. It does not fix a domain that was never added and verified in your Workspace account, since no login makes an unknown domain known.
Which port do I need if I turn on SMTP authentication?
Google requires a TLS connection for SMTP authentication, so point your server at smtp-relay.gmail.com on port 587. The unauthenticated setup can use port 25, 465 or 587 without TLS, but then IP address authentication becomes mandatory.