Rejected Because the Recipient Only Accepts Internal Mail: Microsoft 5.7.133, 5.7.134, 5.7.12 and Gmail's Policy Block
550 5.7.133 RESOLVER.RST.SenderNotAuthenticatedForGroup, its siblings 5.7.134 and 5.7.12, and Gmail's 550 5.7.1 ... policy that prohibits the email all say the same thing: the address exists, but it only accepts mail from inside its own organisation, or from senders its admin has allowed. Nothing is wrong with your domain, your authentication or your reputation. The recipient's admin made a choice, and only they can change it. For cold outreach, the right move is to suppress the address and find a named person.
Paste the bounce into Bounce Doctor to confirm it is a recipient policy and not a reputation block.
The codes
| Provider | Code | Recipient type | What it says |
|---|---|---|---|
| Microsoft 365 | 550 5.7.133 | Group (distribution list, Microsoft 365 group) | SenderNotAuthenticatedForGroup |
| Microsoft 365 | 550 5.7.134 | Mailbox | SenderNotAuthenticatedForMailbox |
| Microsoft 365 | 550 5.7.136 | Mail user | SenderNotAuthenticatedForMailUser |
| Microsoft 365 | 550 5.7.13 / 5.7.135 | Public folder | Rejects external senders |
| Microsoft 365 | 550 5.7.12 | The organisation | Sender was not authenticated by organisation |
| Google Workspace | 550 5.7.1 | User or domain | "The user or domain has a policy that prohibits the email" |
Sources: Microsoft Learn, Fix NDR error 5.7.133 in Exchange Online (ms.date 10 August 2026), 5.7.134, 5.7.136 and 5.7.13 or 5.7.135; Google's Gmail SMTP errors and codes (last updated 26 October 2026). All read 2 November 2026.
Microsoft's 5.7.133 article describes the case plainly: you see it "when the recipient is a group that's configured to reject messages from external senders who are from outside the organization", and "Only the group owner or an email admin in the recipient's organization can fix this issue."
Our /smtp/550-5-7-12 page has the short reference for the Microsoft code. This guide is about what it means for a sender and what to do with the list.
Why the admin set it
These settings are a normal part of running email at a company. Common reasons:
- Internal lists. An all-staff list or a department group is meant for colleagues. Opening it to the internet would let anyone email the whole company.
- Spam and phishing. A shared address that got a lot of junk is easier to lock down than to filter.
- Service accounts. Addresses used by systems, not people, often accept mail only from those systems.
- Allow lists. Some organisations accept mail for certain addresses only from named partners and suppliers.
In Google Workspace, Google's admin help on restricting messages to authorized addresses or domains (read 2 November 2026) says that with the Restrict delivery setting, "Users can receive messages only from addresses or domains you authorize", and messages from anyone else "are returned to the sender with a bounce message that describes the policy." Admins can also block senders by name and set content rules.
Why cold senders hit it
The addresses where this happens most are the shared ones that look like a way in:
| Address | Why it may be restricted |
|---|---|
| sales@, info@, hello@ | Often a group that fans out to several people, sometimes internal-only |
| team@, staff@, everyone@, all@ | Almost always an internal distribution list |
| A department: finance@, hr@, it@ | Groups set up for internal routing |
| A project or office alias | Internal groups the admin forgot to open |
Shared addresses come with other problems too: several people read them, they're more likely to report mail as spam, and they don't reply as often as named people do. Our guide to role-based email addresses covers when they are worth emailing, and the role-based email filter pulls them out of a list.
Why a verifier can't always see it
An email verifier asks the recipient's server whether it will accept mail for an address, without sending a message. For these addresses, the honest answer is often "yes": the address exists, and the restriction is applied later, when the server works out who the recipient is and who the sender is. So a check can come back accepting, and the real message still be rejected.
That is not a reason to skip verification. It is a reason to treat shared addresses differently and to feed your bounces back into your suppression list. A verifier removes the addresses that don't exist; your own bounce data removes the ones that exist but won't take your mail.
What to do
1. Suppress the address
It's a permanent rejection for that address. Add it to your suppression list so no future campaign sends to it. If you use several tools, the suppression list merger combines their lists into one.
2. Find a named person instead
The organisation still exists and may still be a good fit. Look for the person who owns the problem you solve, and work out their address from the company's pattern. The email format finder shows a domain's likely pattern, and the email permutator generates the candidates to verify.
3. If you have a relationship, ask
If you are a supplier, a partner, a customer or an event contact, ask your contact to have their IT team allow your domain or address. Microsoft's article gives their admin two options: allow messages from people inside and outside the organisation, or add specific senders to the group's allowed senders list, which needs a mail contact for you first. Send the bounce with your request; it tells them exactly which setting to change.
4. Don't work around it
Don't resend from another domain or a personal address. The setting rejects every outside sender, so it won't work, and an admin who sees repeated attempts is likely to block you by name.
How it differs from look-alike errors
| Error | Meaning | Action |
|---|---|---|
| 550 5.7.133 / 5.7.134 / 5.7.12 / Gmail "policy" | Address exists, internal or allow-listed senders only | Suppress; find a named person |
| 550 5.4.1 "Recipient address rejected: Access denied" | Microsoft's directory check: no such recipient in that tenant | Suppress. See 550 5.4.1 |
| 550 5.1.1 / 5.1.10 | Address doesn't exist | Suppress. See /smtp/550-5-1-1 |
| 550 5.7.1 "very low reputation" | Your reputation at Gmail | Fix your sending. See Gmail low reputation |
| 550 5.7.606 "banned sending IP" | Microsoft blocked your IP | Delist. See 550 5.7.606 |
If many addresses at the same company bounce at once with a mix of these, our bounces from one domain guide walks through how to tell a policy from a migration or a block. For lists aimed at large organisations, cold email to enterprise companies covers the gateways and policies you'll meet.
Where SimpleVerifier fits
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. It flags role addresses, so you can decide whether to send to sales@ before you do. It can't see a restriction that the recipient's server applies after accepting the address, which is why bounces like these belong in your suppression list. Catch-alls stay risky, never guessed valid.
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. See pricing.
Common questions
What does 550 5.7.133 RESOLVER.RST.SenderNotAuthenticatedForGroup mean?
The recipient is a Microsoft 365 group that is set to reject messages from senders outside the organisation. Microsoft says only the group owner or an email admin in the recipient's organisation can change it.
Is this a hard bounce?
It is a permanent rejection for that address. The mailbox or group is real, so it is not the same as an unknown user, but you should stop sending to it unless the organisation changes the setting for you.
Why did my email verifier say the address was valid?
A verifier asks whether the server will accept mail for the address. Restrictions like this can be applied after the address is accepted, when the server works out who the recipient is, so the check can come back as accepting and the message still be rejected. The address really does exist.
Can I get around it by sending from a different domain?
No. The setting accepts internal or specifically allowed senders only, so any outside domain gets the same rejection. Trying to get round a block like this is also a fast way to have your domains blocked by name.
How does the recipient fix it?
In Microsoft 365, an admin can allow people inside and outside the organisation to send to the group, or add specific outside senders to the group's allowed senders list. In Google Workspace, an admin can change the Restrict delivery or blocked senders settings for their users.
Check your list before you send
Real mailbox checks over SMTP, and nothing is sent to the address. Sign in with Google and your first 100 email checks are free, no card. Plans for bigger lists are on the pricing page.