550 5.7.133 to 5.7.136: sender not authenticated for this recipient
The Microsoft 365 recipient you emailed (a group, mailbox, public folder or mail user) is set to reject messages from senders outside its organization, so your message bounced.
Sender not authenticated for group
Microsoft's description for 5.7.133 in its Exchange Online NDR reference. The same table lists 5.7.134 "Sender was not authenticated for mailbox", 5.7.13 or 5.7.135 "Sender was not authenticated for public folder" and 5.7.136 "Sender was not authenticated".
What 550 5.7.133-136 means
These four codes mean the same thing for different kinds of recipient. The recipient is configured to reject messages from senders outside its organization, which Exchange calls unauthenticated senders. Microsoft's NDR reference maps them like this:
- 5.7.133: a group (distribution list).
- 5.7.134: a mailbox.
- 5.7.135 (or 5.7.13): a public folder.
- 5.7.136: a mail user.
Nothing is wrong with your mail, your domain or your authentication records. Microsoft's documentation treats authenticated senders as internal senders, so "not authenticated" here means "not from inside this organization". It isn't an SPF, DKIM or DMARC failure. Your message reached the right server and was refused by a setting on that one recipient.
Only the recipient's side can change it. For 5.7.133, Microsoft says the group owner or an email admin in the recipient's organization can fix it; for 5.7.134 to 5.7.136, only an email admin can. They can either let everyone send (clear "Require that all senders are authenticated", or for a group choose "Allow messages from people inside and outside my organization"), or keep the restriction and add specific outside senders to the recipient's allowed senders list. An outside sender has to be represented by a mail contact or mail user before it can be added.
For distribution groups the same switch is exposed in Exchange Online PowerShell as the RequireSenderAuthenticationEnabled parameter of Set-DistributionGroup. Microsoft documents $true as accepting messages only from authenticated (internal) senders, and $false as accepting them from internal and external senders.
Likely causes
- The group, mailbox, public folder or mail user only accepts messages from senders inside its organization.
- A group was set up for internal use, and nobody expected outside mail to reach it.
- Your address isn't on the recipient's allowed senders list.
How to fix it
If you sent the message
- Contact the recipient by another route, such as a direct address or phone, and send them the NDR.
- Ask whether they want to accept outside mail on that address, or whether there's a different address you should use.
- Don't change your SPF, DKIM or DMARC records for this error. They aren't the cause.
If you're the recipient or their admin
- For a group: in the Exchange admin center, go to Recipients > Groups, open the group, select Settings > Edit delivery management, and choose "Allow messages from people inside and outside my organization".
- For a mailbox, public folder or mail user: clear "Require senders to be authenticated" (or "Require that all senders are authenticated") in its message delivery restrictions.
- To allow only some outside senders, create mail contacts for them and add them to the recipient's allowed senders list instead.
- In PowerShell, run Set-DistributionGroup with -RequireSenderAuthenticationEnabled $false for a group that should take outside mail.
Frequently asked questions
Can I fix a 5.7.133 or 5.7.134 bounce from the sending side?
No. The recipient is set to reject outside senders, and only the group owner or an admin in the recipient's organization can change that. Send them the NDR through another channel and ask them to allow your address.
Does "sender not authenticated" mean my SPF or DKIM failed?
No. In these Microsoft 365 codes it means you aren't an internal sender of the recipient's organization. Your authentication records aren't involved, so changing them won't help. The fix is a delivery restriction setting on the recipient.
What is the difference between 5.7.133, 5.7.134, 5.7.135 and 5.7.136?
The type of recipient that refused the message. Microsoft uses 5.7.133 for a group, 5.7.134 for a mailbox, 5.7.135 (or 5.7.13) for a public folder and 5.7.136 for a mail user. In every case the recipient only accepts mail from inside its organization.
Sources
- Email nondelivery reports (NDRs) and SMTP errors in Exchange Online (Microsoft Learn)
- Fix NDR error 5.7.133 in Exchange Online (Microsoft Learn)
- Fix NDR error 5.7.134 in Exchange Online (Microsoft Learn)
- Fix NDR error 5.7.13 or 5.7.135 in Exchange Online (Microsoft Learn)
- Fix NDR error 5.7.136 in Exchange Online (Microsoft Learn)
- Set-DistributionGroup (Microsoft Learn)
Provider messages are quoted as the provider publishes them. Servers can change their wording, so the bounce you received may differ slightly.
Related codes
Related guides
How do you safely whitelist a sender in Microsoft 365 and Google Workspace?
Safely allow (whitelist) a sender in Microsoft 365 and Google Workspace without opening a spoofing hole: Tenant Allow/Block List, approved senders and gateways.
9 min read Running email day to dayHow to read email headers
Read email headers step by step: the Received chain from the bottom up, Authentication-Results, ARC, Return-Path, Message-ID and Microsoft 365 anti-spam fields.
10 min read SPF, DKIM & DMARCSPF vs DKIM vs DMARC: what each one proves, and what it doesn't
A plain-English comparison of SPF, DKIM and DMARC: what each checks, what it can't prove, how they work together, and where MTA-STS and BIMI fit.
8 min read