DMARCGuardian Practical help for DMARC, SPF, DKIM, and BIMI.

Blog · Deliverability

How to Fix the 550 5.7.134 Error When External Senders Email Exchange Online Moderated Mailboxes

By DMARCGuardian Editorial Team ·

What the 550 5.7.134 Error Means

The short version: Exchange Online rejected an email because the sender was not authenticated to your Microsoft 365 tenant, and your moderated mailbox requires authentication before delivering messages.


550 5.7.134 RESOLVER.RST.SenderNotAuthenticatedForMailbox;
authentication required; Delivery restriction check failed because
the sender was not authenticated when sending to this mailbox

This is not an SPF problem, a DKIM failure, or a DMARC reject. Those checks happen at the DNS level, before mail arrives at your tenant. The 5.7.134 error fires at a different layer: the mailbox-level transport and moderation settings inside Exchange Online.

Why It Happens

Exchange Online moderated mailboxes route incoming messages through an approval workflow. Before a message is delivered to the moderated recipient, Exchange Online checks whether the sender is authorized.

The check that matters here is RequireSenderAuthenticationEnabled. When this is set to $true on a mailbox, the mailbox only accepts messages from senders who are authenticated to your Microsoft 365 tenant. External senders - anyone sending from outside your organization - are blocked by default when this setting is on.

External senders from Gmail, business domains, and other organizations cannot authenticate to your Microsoft 365 tenant without a connector. When they hit a moderated mailbox that requires authentication, they fail at the moderation review step, not at delivery.

This is a common misconfiguration when IT teams set up moderated mailboxes for compliance workflows and then discover that external reviewers, auditors, or partner contacts cannot send to them.

How to Diagnose It

Use Message Trace in the Exchange admin center to confirm the error:

  1. In the Exchange admin center, go to Mail flow > Message Trace.
  2. Search for the sender address that reported the failure.
  3. Set the date range to cover the time of the failed delivery.
  4. In the detail view, look for the event type "FAIL" with the enhanced detail showing 5.7.134.

The detail will show whether the failure happened at the mailbox level or at a transport rule. If the issue is at the mailbox level, the fix is on the mailbox object. If it is at the transport rule level, the fix is on the rule.

Also check the moderation settings on the mailbox itself:

powershell
Get-Mailbox -Identity "Mailbox Name" | Select RequireSenderAuthenticationEnabled, ModerationEnabled

If RequireSenderAuthenticationEnabled is $true and ModerationEnabled is also $true, that is the combination that causes external senders to be rejected.

Four Ways to Fix It

Option 1: Disable RequireSenderAuthenticationEnabled (fastest)

The simplest fix is to turn off the authentication requirement for the specific mailbox:

powershell
Set-Mailbox -Identity "Mailbox Name" -RequireSenderAuthenticationEnabled $false

This tells Exchange Online to allow unauthenticated messages through to the mailbox, bypassing the sender authentication check. Moderation still runs for messages from external senders - the approval workflow still requires review, but the sender no longer needs to be authenticated to your tenant to enter that workflow.

Use this when: you have a small team, no strict external sender policy, and simply need external reviewers or partners to reach a moderated mailbox.

Watch out for: this opens the mailbox to all external senders without any authentication requirement. If your compliance or security policy restricts who can contact this mailbox, use Option 2 or 3 instead.

Option 2: Add specific addresses or domains to the acceptance list

Instead of opening the mailbox to all external senders, you can allow specific addresses or domains:

powershell
Set-Mailbox -Identity "Mailbox Name" -AcceptMessagesOnlyFrom @("external-reviewer@example.com") -RequireSenderAuthenticationEnabled $true

Or for a domain-level allowance:

powershell
Set-Mailbox -Identity "Mailbox Name" -AcceptMessagesOnlyFromDLMembers @() -RequireSenderAuthenticationEnabled $true

You can also configure the acceptance list in the Exchange admin center under Mail flow > Rules. Create a rule that adds the external domain to the safe sender list for the specific mailbox.

Use this when: you only need to allow specific known external senders, and you want to keep the default block in place for everyone else.

Watch out for: managing a growing list of allowed addresses across multiple mailboxes can become tedious. Document the rationale for each entry.

Option 3: Create an inbound connector for trusted external senders (most secure for partners)

If an external organization needs to reliably reach your moderated mailboxes, set up a partner connector. This authenticates their specific mail server using TLS and a certificate:

  1. In the Exchange admin center, go to Mail flow > Connectors.
  2. Add a new inbound connector.
  3. Set the connector type to "Partner" and configure the domain or IP range of the external organization's mail server.
  4. Enable TLS and require certificate authentication.
  5. Point the connector to your moderated mailbox or mail flow rule.

External senders from that partner organization will then authenticate through the connector and bypass the SenderNotAuthenticatedForMailbox check.

Use this when: you need to allow a trusted partner's mail server to reliably reach your moderated infrastructure, and you want the authentication to be server-level rather than per-address.

Watch out for: this requires coordination with the external organization's IT team to get their mail server's TLS certificate details. It is more setup work than Option 1 or 2.

Option 4: Use a shared mailbox or distribution group instead of moderation

If external communication through a moderated mailbox is a frequent requirement, consider whether a shared mailbox or distribution group is a better fit:

  • Shared mailboxes do not require sender authentication for basic delivery (though you can restrict them).
  • Distribution groups can be configured to accept external messages without requiring authentication.
  • You can still apply journal rules or other compliance controls at the organization level instead of per-mailbox.
powershell
Set-DistributionGroup -Identity "External Reviewers" -RequireSenderAuthenticationEnabled $false

Use this when: external communication is routine rather than exception-based, and per-mailbox moderation overhead is slowing down your team.

Watch out for: moving from moderation to open distribution changes the security posture. Make sure your compliance team is aligned before making this change.

Which Fix Should You Use?

| Situation | Recommended fix |
|---|---|
| Small team, external reviewers need rare access | Option 1 |
| Specific known external senders | Option 2 |
| Trusted partner mail servers on ongoing basis | Option 3 |
| Routine external communication needed | Option 4 |

For most IT teams managing occasional external reviewer or auditor access, Option 1 or Option 2 is the fastest path. For organizations with strict external sender policies, Option 3 is the most defensible approach because it authenticates the sending server rather than opening the mailbox globally.

How to Keep This From Happening Again

After you fix the issue, document it:

  1. List every moderated mailbox in your tenant and the reason it requires moderation.
  2. For each one, record whether external senders need access and through which method.
  3. Review the acceptance lists and connectors quarterly.
  4. Set up an alert for 5.7.134 errors in the Exchange admin center so you catch new occurrences before users report them.

Run a message trace monthly if you manage a busy mail environment. Catching 5.7.134 errors early is easier than tracing them after the fact.

Related Authentication Errors

The 550 5.7.134 error is different from other authentication-related rejection codes:

  • 550 5.7.1 usually means the sending server's SPF, DKIM, or DMARC record failed organizational authentication checks. This is a DNS-level issue, not an Exchange Online mailbox configuration issue.
  • 550 5.7.134 is an Exchange Online transport-layer check requiring tenant authentication before a message enters a moderated workflow.

If external senders are failing with 5.7.1 across multiple recipients rather than one specific moderated mailbox, the problem is at your domain's DNS authentication level. Check your SPF record, DKIM configuration, and DMARC policy before reviewing mailbox-level settings.

Where DMARC, SPF, and DKIM Fit Into This

The 5.7.134 error is about Exchange Online mailbox-level authentication requirements, not about your domain's email authentication records. SPF, DKIM, and DMARC are DNS-level checks that operate before mail reaches Exchange Online moderation. If external senders cannot reach your organization at all, your SPF record, DKIM setup, or DMARC policy may be misconfigured at the DNS level.

If you want to audit your domain's overall email authentication posture, DMARCFlow can monitor your SPF, DKIM, and DMARC records across all sending domains and alert you to misconfigurations that could affect deliverability for external senders.