Skip to main content
Relaymetry

Outlook 5.7.134 Fix: Sender Was Not Authenticated for Mailbox

An Outlook 5.7.134 bounce means the specific recipient mailbox you sent to is configured to reject messages from senders outside its own organization, and your message came from outside. The full text is “Sender was not authenticated for mailbox,” and per Microsoft only an email administrator for the recipient’s organization can change this configuration. This is a recipient-side restriction on one mailbox, not a spam block, not an SPF problem, and not a DMARC failure, so your SPF, DKIM, and DMARC can all be perfect while the message is still rejected. The fix is to confirm your own authentication is clean, verify you are sending to the right address, and ask the recipient’s email administrator to allow your sender or relax the mailbox’s authenticated-senders-only restriction.

Quick answer

An Outlook 5.7.134 bounce means the specific recipient mailbox you sent to is set up to reject messages from senders outside its organization, and your message came from outside. The full text is Sender was not authenticated for mailbox, and per Microsoft only an email administrator for the recipient’s organization can change this configuration. This is a recipient-side restriction on one mailbox, not a spam block, not a DMARC failure, and not an SPF problem, so your SPF, DKIM, and DMARC can all be perfect while the message is still rejected. The fix lives on the recipient’s side: you confirm your own authentication is clean, verify you are sending to the right address, and ask the recipient’s email administrator to allow your sender or relax the mailbox’s authenticated-senders-only restriction.

What the 5.7.134 code means

Microsoft’s NDR table defines 5.7.134 Sender was not authenticated for mailbox as a message rejected because the recipient address is a mailbox that’s set up to reject messages sent from outside its organization. In Microsoft’s own words, only an email administrator for the recipient’s organization can change this configuration.

The key detail that 5.7.134 carries, and that distinguishes it from its neighbours, is scope: the restriction sits on a single mailbox, not on a whole tenant. In Exchange Online this is the mailbox’s message-delivery restriction "Require that all senders are authenticated" (sometimes surfaced as accept-only-from-internal-senders). When that switch is on, the mailbox accepts mail only from authenticated senders inside the same organization, and any external message to that one address bounces with 5.7.134 while every other mailbox in the same tenant keeps receiving your mail normally.

The word "authenticated" here is easy to misread. It does not mean your message failed SPF, DKIM, or DMARC. It means the recipient’s tenant treats a sender from outside its organization as "not authenticated" for the purpose of this one mailbox’s restriction, and that mailbox has been configured to accept only internal, authenticated senders.

The per-recipient-type family

5.7.134 is the mailbox member of a small family of codes Microsoft uses when a recipient is set up to reject external senders. Every member describes the same underlying restriction — the recipient only accepts internal, authenticated senders — and they differ only in which recipient object carries it. The code you got tells the recipient’s administrator exactly which object to look at:

  • 5.7.134 — the recipient is a mailbox (Sender was not authenticated for mailbox). This page’s focus.
  • 5.7.136 — the recipient is a mail user (Sender was not authenticated).
  • 5.7.13 / 5.7.135 — the recipient is a public folder (Sender was not authenticated for public folder).
  • 5.7.12 — the restriction is at the organization level (Sender was not authenticated by organization), covered on its own page.

Because the codes share a cause but point at different objects, the practical value of reading the exact code is that it scopes the fix. A 5.7.134 means the recipient’s administrator should look at the delivery restriction on one mailbox — not a tenant-wide mail-flow rule, not a mail-user object, and not a public folder. Quoting 5.7.134 back to them saves a round of guessing.

Why Outlook returns 5.7.134

The target mailbox has been configured to accept mail only from authenticated senders inside its own organization. When your message arrives from outside that tenant, it does not meet the mailbox’s restriction, so Exchange Online rejects it with 5.7.134. The common reasons a single mailbox has this turned on:

  • A deliberate lock-down of a sensitive internal mailbox — an HR, finance, payroll, or executive address restricted to internal senders only.
  • The "Require that all senders are authenticated" delivery restriction left enabled on the mailbox, sometimes from a migration default or a security-hardening step that was never relaxed.
  • An internal-only or shared mailbox that was never meant to receive external mail being published or used as a contact by mistake.

Because the decision is made entirely on the recipient’s side and reflects one mailbox’s configuration, nothing you change in your own DNS or sending setup will lift it. The restriction is theirs to remove. This is the key difference from a reputation ban or an authentication failure: you cannot fix 5.7.134 from your side by tuning records.

How to diagnose a 5.7.134

Start by reading the NDR and confirming the diagnostic line is genuinely 5.7.134 Sender was not authenticated for mailbox. The word "mailbox" in the text is the signal that the restriction is on a single recipient mailbox rather than the whole organization (5.7.12), a mail user (5.7.136), or a public folder (5.7.13 / 5.7.135). Quote the exact enhanced status code, because it is what scopes the fix.

Next, confirm your own authentication is clean. A 5.7.134 is not an authentication failure, but if your SPF, DKIM, or DMARC is broken you can be mistaken for a spoofed or unauthenticated external sender elsewhere, and you want that ruled out before you approach the recipient. The Relaymetry DMARC checker reads your domain’s published SPF, DKIM, and DMARC records so you can confirm they are present and aligned, and present a clean posture when you ask the recipient to allow you.

Then verify the recipient itself. Check that you have the correct address, that it is a real external-facing mailbox, and that the person you are emailing actually expects mail from outside their organization. A surprising share of 5.7.134 bounces are an internal-only mailbox being used by mistake, which no amount of allow-listing will fix.

One thing you cannot see from your side is the mailbox’s delivery-restriction setting. That configuration is private to the recipient’s tenant. Your authentication posture and the exact NDR code are the groundwork; the actual restriction on that mailbox is theirs to read and change.

How to fix a 5.7.134

The fix is confirm-your-side-is-clean, then get the recipient’s administrator to relax the mailbox restriction or allow you. There is no sender-side DNS change that clears it.

  1. Read the NDR and confirm it names a mailbox. Verify the code is 5.7.134 Sender was not authenticated for mailbox and not a neighbour such as 5.7.12 (organization), 5.7.136 (mail user), 5.7.13 / 5.7.135 (public folder), or 5.7.509 (a DMARC reject).
  2. Confirm your SPF, DKIM, and DMARC are clean and aligned for your visible From domain, so you cannot be mistaken for an unauthenticated or spoofed sender.
  3. Verify the recipient address is correct, real, and meant to receive external mail; rule out an internal-only mailbox being used by mistake.
  4. Ask the recipient’s email administrator to allow your sender or domain, or to relax the mailbox’s "Require that all senders are authenticated" delivery restriction so it accepts your external mail. This is the only real fix — only they can change the mailbox configuration.
  5. Do not keep retrying. Retries against an unchanged mailbox restriction will keep bouncing and add noise; send again only after the recipient confirms the change.
  6. If you control the recipient mailbox — for example, it is in a tenant you administer — edit that mailbox’s message-delivery restriction to turn off "Require that all senders are authenticated," or add your external sender to the accepted-senders list for the mailbox.

What this does not prove

A public DNS and authentication check confirms whether your SPF, DKIM, and DMARC records are present and aligned. It cannot read the recipient mailbox’s delivery restrictions, confirm that a specific message was rejected for this exact reason, or change the mailbox’s configuration. The restriction is set on a mailbox inside the recipient’s organization, and only their email administrator can lift it.

Relaymetry checks the public, sender-side signals that you control. It does not have access to the recipient’s tenant configuration, the mailbox’s delivery restrictions, or the exact policy applied to a given message.

Frequently asked questions

What does Outlook 5.7.134 sender was not authenticated for mailbox mean?

Per Microsoft, 5.7.134 "Sender was not authenticated for mailbox" means the recipient address is a mailbox that is set up to reject messages sent from outside its organization, and your message came from outside. It is a recipient-side restriction on one specific mailbox — typically the Exchange delivery restriction "Require that all senders are authenticated" — not a spam block, not an SPF failure, and not a DMARC failure. Microsoft states that only an email administrator for the recipient’s organization can change this configuration.

Why can’t I fix 5.7.134 myself by changing my DNS or SPF, DKIM, and DMARC?

Because the restriction lives entirely on the recipient’s mailbox, not in your sending setup. That mailbox has been configured to accept mail only from authenticated senders inside its own organization, so no change to your DNS, SPF, DKIM, or DMARC will satisfy it. The only real fix is for the recipient’s email administrator to allow your sender or domain, or to relax the mailbox’s authenticated-senders-only restriction. Confirming your own authentication is clean is still worth doing so you are not mistaken for a spoofed sender, but it does not lift the block.

What is the difference between 5.7.134, 5.7.12, 5.7.136, and 5.7.13?

They are siblings in the same "recipient is set up to reject external senders" family, and they differ only by which recipient object carries the restriction. 5.7.134 is "sender was not authenticated for mailbox" (a mailbox, this page). 5.7.136 is "sender was not authenticated" (a mail user). 5.7.13 or 5.7.135 is "sender was not authenticated for public folder" (a public folder). 5.7.12 is "sender was not authenticated by organization" (the whole organization). Reading the exact code tells the recipient’s administrator which object to adjust — for 5.7.134, the delivery restriction on one mailbox.

Is 5.7.134 a DMARC failure or a spam block?

No to both. 5.7.509 means your domain failed DMARC and the recipient enforced a reject policy — an authentication problem you fix on your side by aligning SPF, DKIM, and DMARC. A reputation ban such as 5.7.511 blocks your sending IP. 5.7.134 is neither: it means one recipient mailbox is configured to accept only internal authenticated senders, so perfect SPF, DKIM, and DMARC will still bounce, and the fix is on the recipient’s side. Read the exact enhanced status code to tell them apart.

Can Relaymetry check whether the recipient mailbox will accept my mail?

No. The mailbox’s delivery restrictions live inside the recipient’s tenant and are not exposed through any public lookup. Relaymetry checks public, sender-side signals only — your domain’s SPF, DKIM, and DMARC records. Confirming those are clean and aligned is useful groundwork so you present as a fully authenticated sender when you ask the recipient’s administrator to allow you, but it cannot read or change the mailbox’s configuration.

Other Outlook issues

References