5.7.64 "TenantAttribution; Relay Access Denied" means Exchange Online received a message it was expected to relay onward but could not attribute it to a tenant, because the connection did not match the inbound connector that should have claimed it.
Most common causes
- The on-premises or gateway source IP changed
- Connector certificate identity no longer matches the configured path
- Mail was routed through a different gateway than the connector expects
- Hybrid or relay configuration changed without a corresponding connector update
What to verify next
- Map the message route and identify the actual connecting host
- Compare current source IP and certificate identity with the connector design
- Review recent gateway, NAT or routing changes
- Retest through the intended connector path after configuration is aligned
Connectors attribute mail to tenants
When mail arrives at Exchange Online from your on-premises servers or a gateway and is destined for an external recipient, Microsoft needs to know which tenant is responsible. It decides by matching the connection to an inbound connector — by source IP or by the TLS certificate the sender presents. If nothing matches, relay is denied with this code.
Hybrid deployments rely on this attribution for every outbound message routed through the cloud, so a mismatch stops all of it at once.
What breaks the match
The public IP of the on-premises server changed, NAT or a new firewall path altered the source address, the TLS certificate was renewed with a different subject name, or a new gateway was introduced that the connector does not know. Any of these silently breaks attribution.
Use the Email Route Visualizer on a rejected message’s headers to see which host actually connected, then compare that host’s IP and certificate against the connector configuration.
- Attribution is by source IP or certificate subject.
- IP, NAT, certificate and gateway changes are the usual causes.
- The connecting host in the headers is the fact to compare.
Restore attribution
Update the inbound connector with the current source IP range, or ensure the certificate presented matches the connector’s expected subject and is issued by a trusted authority. Re-run the hybrid configuration wizard if the environment changed substantially.
Send a test through the intended path after the change. There is no DNS propagation involved; a persisting 5.7.64 means the connection still does not match.
Best diagnostic path
Mail Failure Doctor
Classify the complete rejection and preserve provider-specific diagnostic context.
Open analysis → Live analysisEmail Dependency Discovery
Map applications and devices that depend on a relay or submission path before changing it.
Open analysis → Live analysisEmail Infrastructure Digital Twin
Map the domain’s public mail infrastructure and provider relationships before remediation.
Open analysis →Known limits
- Connector configuration is visible only to tenant administrators.
- Certificate-based attribution depends on the exact subject name and chain the sending server presents.
Common questions
Nothing changed on our side. Why now?
Something did: an IP, a NAT rule, a renewed certificate, or a routing change upstream. Compare the connecting host in a rejected message against the connector.
Is this related to SPF?
No. It is connector attribution inside Microsoft 365, not sender authentication.
Does it affect internal mail?
Usually not. It concerns mail that must be relayed externally and therefore attributed to a tenant.
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.