5.7.703 means the sending organization’s own Microsoft 365 tenant blocked the message: the recipient address or domain is on the tenant’s block list. Nothing about the destination or the sender’s DNS is involved, which is why external checks all pass.
Most common causes
- The destination address is on the organization’s block list
- The destination domain is blocked by tenant policy
- A blocked recipient in a multi-recipient message causes the message to be rejected
What to verify next
- Confirm the exact blocked recipient or domain in the NDR
- Review tenant allow/block policy with the organization’s email administrator
- Retest after the policy entry is corrected
The block is on the sender’s side
Microsoft 365 keeps a Tenant Allow/Block List. When a recipient address or domain is blocked there, outbound messages to it are rejected before leaving the tenant. The NDR names the blocked recipient so it can be located in the list.
This surprises people because the rejection reads like a delivery failure at the destination. It is a policy decision inside the sending organization, usually created after a phishing incident, a mistaken bulk block, or an automated threat response.
Multi-recipient messages fail as a whole
When one recipient in a message is blocked, Microsoft rejects the entire message rather than delivering to the others. A single stale entry can therefore stop mail to a distribution list or a group thread.
Related codes: 5.7.705 covers a tenant that exceeded a threshold, 5.7.708 an IP that was not accepted, and 5.7.750 an unregistered sending domain. They share the 5.7.7xx family but have different remediation paths.
- The blocked address or domain is named in the NDR.
- One blocked recipient rejects a multi-recipient message entirely.
- Only a tenant administrator can remove the entry.
How to resolve it
Locate the exact recipient or domain from the NDR and have a Microsoft 365 administrator review the Tenant Allow/Block List in the Defender portal. Confirm why the entry exists before removing it; a block created after a compromise may still be warranted.
After the entry is removed, resend. There is no propagation delay for tenant policy, so a repeated 5.7.703 means the entry still exists or another matching entry does.
Best diagnostic path
Mail Failure Doctor
Classify the complete rejection and preserve provider-specific diagnostic context.
Open analysis → Live analysisEmail Infrastructure Digital Twin
Map the domain’s public mail infrastructure and provider relationships before remediation.
Open analysis →Known limits
- The list and its history are visible only to tenant administrators.
- Automated threat responses can re-create entries; a removed block that returns has a cause worth investigating.
Common questions
Should I change my SPF or DMARC?
No. This code is internal tenant policy and unrelated to DNS authentication.
Why did it start suddenly?
Blocks are often added automatically after a reported phishing message or manually during an incident. Check the list’s change history.
Can the recipient fix it?
No. The block is inside the sending tenant; the recipient’s configuration is not involved.
Why the exact message matters
The same status family can be triggered by different conditions, and providers frequently add diagnostic text that narrows the issue. Use the complete rejection text rather than treating the numeric code as a complete diagnosis.
Provider reference
For the provider-defined meaning and current requirements, review Microsoft Exchange Online NDR reference.