Skip to main content
Relaymetry

Outlook 5.7.12 Fix: Sender Was Not Authenticated by Organization

An Outlook 5.7.12 bounce means the recipient’s mailbox or organization 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 by organization,” and per Microsoft only an email administrator for the recipient’s organization can change this configuration. This is a recipient-side policy refusal, not a spam block 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 domain.

Quick answer

An Outlook 5.7.12 bounce means the recipient’s mailbox or organization 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 by organization, and per Microsoft only an email administrator for the recipient’s organization can change this configuration. This is a recipient-side policy refusal, not a spam block and not a DMARC failure, 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 domain.

What the 5.7.12 code means

Microsoft’s NDR table defines 5.7.12 Sender was not authenticated by organization as a message rejected because the recipient address is 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 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 senders from outside its organization as "not authenticated" for the purpose of this restriction, and the recipient has chosen to accept mail only from internal, authenticated senders. Typically this is an Exchange Online mail-flow (transport) rule, or a per-mailbox setting that requires senders to be authenticated, deliberately turned on by the recipient’s administrators.

The "rejected external sender" family

5.7.12 is one member of a small family of codes Microsoft uses when a recipient is set up to reject external senders. They differ only in which recipient object carries the restriction, so reading the exact code tells you what was locked down:

  • 5.7.12 — the recipient organization is set up to reject external senders. This is the org-level member.
  • 5.7.134 — the sender was not authenticated for a mailbox.
  • 5.7.136 — the sender was not authenticated for a mail user.
  • 5.7.13 / 5.7.135 — the sender was not authenticated for a public folder.

In every case the cause is the same shape: the recipient object only accepts internal, authenticated senders, and your external message was refused. The scope (organization, mailbox, mail user, or public folder) tells the recipient’s administrator exactly which setting to adjust.

Why Outlook returns 5.7.12

The recipient’s organization has a policy that says "accept mail only from authenticated senders inside this organization." When your message arrives from outside that tenant, it does not meet the policy, so Exchange Online rejects it with 5.7.12. The common reasons a recipient has this turned on:

  • A deliberate mail-flow rule restricting a sensitive distribution group, shared mailbox, or executive address to internal senders only.
  • A "require senders to be authenticated" mailbox setting left on, sometimes from a migration default or a security hardening step.
  • An internal-only address that was never meant to receive external mail being used as a contact by mistake.

Because the decision is made entirely on the recipient’s side and reflects their chosen policy, nothing you change in your own DNS or sending setup will lift it. The block is theirs to remove. This is the key difference from a reputation or authentication problem: you cannot fix 5.7.12 from your side by tuning records.

How to diagnose a 5.7.12

Start by reading the NDR and confirming the code is genuinely 5.7.12 and not a neighbour like 5.7.509 (a DMARC reject) or 5.7.1 (a different recipient-policy refusal). The enhanced status code in the diagnostic line is what tells the two apart, so quote it exactly.

Next, confirm your own authentication is clean. A 5.7.12 is not an authentication failure, but if your SPF, DKIM, or DMARC is broken you may be mistaken for a spoofed or unauthenticated sender in other places, 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.12 bounces are an internal-only address being used by mistake, which no amount of allow-listing will fix.

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

How to fix a 5.7.12

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

  1. Read the NDR and confirm it is recipient-side. Verify the code is 5.7.12 Sender was not authenticated by organization and not a DMARC (5.7.509) or other refusal.
  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 expected to receive external mail; rule out an internal-only address used by mistake.
  4. Contact the recipient’s email administrator and ask them to allow your sender or domain, or to relax the external-sender restriction on the mailbox, group, or organization in question. This is the only real fix.
  5. Do not keep retrying. Retries against an unchanged recipient policy will keep bouncing and add noise; send again only after the recipient confirms the change.
  6. If you control both sides — for example, two tenants you administer — adjust the recipient organization’s mail-flow rule or the mailbox’s "require authenticated senders" setting so it permits your external domain.

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’s mail-flow rules or mailbox settings, confirm that a specific message was rejected for this exact reason, or change the recipient’s policy. The restriction is configured 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, transport rules, or the exact policy applied to a given message.

Frequently asked questions

What does Outlook 5.7.12 sender was not authenticated by organization mean?

Per Microsoft, 5.7.12 "Sender was not authenticated by organization" means the recipient address is set up to reject messages sent from outside its organization, and your message came from outside. It is a recipient-side policy refusal — an Exchange mail-flow rule or a mailbox setting that only accepts internal, authenticated senders — not a spam block 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.12 myself by changing my DNS or SPF, DKIM, and DMARC?

Because the restriction lives entirely in the recipient’s organization, not in your sending setup. The recipient has chosen to accept mail only from authenticated senders inside their own tenant, so no change to your DNS, SPF, DKIM, or DMARC will satisfy that policy. The only real fix is for the recipient’s email administrator to allow your sender or domain, or to relax the external-sender 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.

Is 5.7.12 the same as a 5.7.509 DMARC failure?

No — they are different problems. 5.7.509 means your domain failed DMARC and the recipient enforced a reject policy, which is an authentication problem you fix on your side by aligning SPF, DKIM, and DMARC. 5.7.12 means the recipient’s organization is configured to reject any sender from outside its organization, regardless of how well your mail authenticates. With 5.7.12, 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.

What are 5.7.134, 5.7.136, and 5.7.13 — are they related?

Yes — they are siblings of 5.7.12 in the same "recipient set up to reject external senders" family, differing only by which recipient object carries the restriction. 5.7.134 is "sender was not authenticated for mailbox" (a mailbox), 5.7.136 is "sender was not authenticated" (a mail user), and 5.7.13 / 5.7.135 is "sender was not authenticated for public folder" (a public folder). 5.7.12 is the organization-level member. The scope in the code tells the recipient’s administrator exactly which setting to adjust.

Can Relaymetry check whether the recipient will accept my mail?

No. The recipient’s mail-flow rules and mailbox settings live inside their 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 recipient’s policy.

Other Outlook issues

References