Why Exchange Online Moderation Accepts Your Email But Then Rejects It with 550 5.7.134

What Does the 550 5.7.134 Error Mean in Exchange Online?

When Exchange Online rejects a message with 550 5.7.134, the delivery failed at the final delivery step after the message was already accepted and processed. The 550 prefix marks it as a permanent failure. The 5.7.134 sub-code indicates the sender is not authorized for the routing path or recipient, according to Microsoft documentation.

This is the confusing part: the message was accepted, often routed into a moderation queue for review, approved by a moderator, and then rejected when Exchange Online attempted the final delivery. The sender sees a bounce for a message that appeared to go through successfully.

How Exchange Online Moderated Connectors Work

A moderated connector in Exchange Online is used when an organization wants all inbound mail from certain external senders to be held for human approval before delivery. Instead of delivering directly, Exchange Online puts the message on a moderation queue. A designated moderator reviews it and approves or rejects it manually.

The flow looks like this:

1. External sender submits mail to the organization.
2. Exchange Online recognizes the recipient is configured for moderation and places the message in a moderation queue.
3. The moderator receives a notification and reviews the message.
4. If approved, Exchange Online attempts to deliver the message to the final recipient.
5. The delivery attempt fails with 550 5.7.134.

Step 5 is where the problem appears. The message was accepted into the moderation queue without issue. The moderator approved it. But the delivery fails.

Why Moderated Delivery Conflicts with Sender Authentication

The conflict arises from a mismatch between what Exchange Online accepts during moderation and what it checks during delivery.

When a message enters the moderation queue, Exchange Online validates the envelope sender (the MAIL FROM address used during SMTP transmission). This determines whether the message goes to the moderation queue at all.

When the message is approved and re-delivered internally, Exchange Online runs a second set of policy checks. These include DMARC alignment validation against the From header domain. If the From header domain does not align with the envelope sender domain, and the receiving domain has a strict DMARC policy, the message fails DMARC alignment and gets rejected with 550 5.7.134.

This happens even though the original envelope sender was valid. The From header domain is what the recipient's mail client displays, and DMARC policy is evaluated against that.

The key distinction:

• Envelope sender (MAIL FROM): the address used during SMTP transmission. Exchange Online uses this to route the message and determine moderation requirements.
• From header: the address displayed in the email client. DMARC is evaluated against this domain.

A message can pass envelope sender checks and still fail DMARC alignment if the From header domain does not match the MAIL FROM domain or the SPF-authenticated domain.

Five Common Causes of the 550 5.7.134 Rejection

1. DMARC p=reject policy rejecting the moderated relay

If your Exchange Online tenant receives mail from external senders who have published p=reject, and those senders use a third-party mail relay or forwarding service in their sending infrastructure, the relay may change the envelope sender during transit. This breaks DMARC alignment. The moderated connector then approves the message, but delivery fails because the final delivery attempt does not pass DMARC.

2. Connector sending domain restrictions are too broad

Exchange Online connectors can be configured to only accept mail from specific domains or IP ranges. If a connector's domain restrictions do not include the actual sending domain from the From header, but the envelope sender passes, messages enter moderation but fail on re-delivery when the policy engine evaluates the From header domain against the connector's accepted domains.

3. Remote domain settings blocking external relay

Remote domain configuration in Exchange Online controls what types of recipients external senders can mail. If the remote domain is configured to reject non-delivery reports for external senders, approved moderation messages may fail silently or with a 550 error when the system cannot reconcile the sender identity with the allowed relay path.

4. Shared sending infrastructure causing alignment failures

Organizations that use shared email infrastructure (marketing automation platforms, CRM systems, bulk mailers) may send through IP addresses or relay services that do not include the customer's domain in the MAIL FROM. The message passes SPF because the relay's IP is authorized, but DMARC alignment fails because the From header domain does not match the MAIL FROM domain. This is a common cause of failures specifically for bulk and automated senders.

5. Internal relay between Exchange Online and on-premises systems

In hybrid environments, messages approved from the moderation queue may route through on-premises Exchange servers before reaching the final mailbox. If the on-premises servers apply stricter DMARC checks or different connector rules, the approved message can be rejected at that boundary with 550 5.7.134.

How to Diagnose 550 5.7.134 Failures in Your Environment

Use message tracing in Exchange Online

Run a message trace in the Exchange Online admin center or via PowerShell for the affected sender addresses. Filter for messages with status "Failed" and the specific error code 5.7.134. The trace will show whether the message entered the moderation queue and where exactly it failed.

Review DMARC aggregate reports

If your domain receives DMARC reports from partner domains, look for alignment failures flagged in the reports. A spike in auth-failure or policy-cover-forced failures from a specific partner domain often coincides with 550 5.7.134 rejections in the moderation queue.

Audit connector configuration

Check the moderated connector's sending domain restrictions in the Exchange Online admin center. Look at which domains and IP addresses are permitted, and compare that against the From header domains used by the external senders who are being rejected.

Check remote domain settings

In the Exchange Online admin center, review the remote domain configuration for the affected external domains. Specifically look for the ability to report non-delivery status and whether the remote domain is marked as internal or external, which affects how DMARC policy is applied.

How to Fix Moderated Connector Rejections

Adjust the moderated recipient's routing

If the external sender's address should not require moderation in the first place, change the recipient's mail flow settings to bypass the moderated connector. Moderation should be applied to specific senders or domains, not blanket-applied to all inbound mail.

Update connector domain permissions

Add the external sender's From header domain to the connector's accepted domain list, or create a separate connector with appropriate permissions for the specific sending domain. This prevents the connector from rejecting the message during re-delivery after moderation approval.

Use a dedicated sending domain for moderated flows

If external senders must go through moderation, configure them to send from a domain that is explicitly authorized in your connector configuration and that has matching SPF and DKIM records. This ensures DMARC alignment passes on re-delivery.

Consider p=quarantine for domains that send through third-party relays

If partner organizations cannot control their sending infrastructure enough to pass DMARC alignment, and they need to send to your moderated recipients, consider temporarily setting their DMARC policy to p=quarantine rather than p=reject while working with them to fix their authentication setup.

Review hybrid routing for DMARC compliance

In hybrid deployments, ensure that on-premises Exchange servers do not apply additional DMARC checks that would block messages already approved by the Exchange Online moderation queue. Consider whether the on-premises servers need their ownDmarcRecord configured for the relaying domain.

Catch Authentication Failures Before Users Complain with DMARCFlow

The 550 5.7.134 rejection is particularly frustrating because the message appears to have been accepted. The sender sees no immediate failure. The rejection only surfaces when the moderator approves and delivery is attempted.

DMARCFlow aggregate reports surface these failures automatically. When external senders are hitting 550 5.7.134 errors against your domain, DMARCFlow captures the authentication results in the aggregate report, even when the message was routed through a moderation queue. This means you can identify which external senders are failing DMARC alignment and why, before your users escalate rejected messages or complain that their contacts cannot reach them.

For IT teams managing Exchange Online environments with moderated connectors, reviewing DMARCFlow reports for auth-failure patterns is faster than tracing individual messages through the moderation queue and connector logs.

FAQ

What does 550 5.7.134 mean in Exchange Online?

It means the message was rejected because the sender is not authorized for the routing path or recipient. The 5.7.134 sub-code specifically indicates an organizational policy restriction in Exchange Online.

Why does my moderated connector accept mail but then reject it?

The moderation queue checks the envelope sender during submission. After a moderator approves the message, Exchange Online runs a second policy check that includes From header validation against DMARC rules. If the From header domain does not align with the envelope sender or authenticated domains, the approved message is rejected.

How do I stop 550 5.7.134 errors from external senders?

Check your connector domain permissions to ensure they include the external sender's From header domain. Consider whether the sender needs to go through a moderated connector at all, or whether they should be added to an allowed senders list. Ensure the sender's DMARC policy is compatible with your routing requirements.

Does DMARC cause 550 5.7.134 rejections?

Yes, indirectly. DMARC alignment failures during the post-moderation delivery attempt are a common cause of 550 5.7.134 errors, particularly when the sender uses a different domain in the From header than their envelope sender or authenticated sending domain.

How do I read DMARC reports to find 550 5.7.134 errors?

DMARCFlow aggregate reports show authentication results for all messages sent to your domain, including failures. Look for entries where the result shows alignment failures or policy actions (quarantine or reject) for the specific external senders that are being moderated. This tells you which senders need their authentication setup reviewed.