Skip to content
iBlockSpam
Get started
Check your domain Get started Log in
How it works
Platforms
Microsoft 365 Google Workspace cPanel / WHM Exchange Server
Solutions
Small business MSPs Hosting providers Law firms Accounting firms Healthcare practices Real estate & title
Free tools Pricing
Blog
All guides
By topic
Email security basics Phishing & threats SPF, DKIM & DMARC Setup guides Running email day to day Switching & migration Choosing a filter
Reference
Glossary Research: top 1,000 sites
SMTP error code · Microsoft 365 / Outlook.com

550 5.7.64 TenantAttribution; Relay Access Denied

550 5.7.64 Permanent failure (5xx): the message bounced
By iBlockSpam Team Checked against sources 3 sources How we check our content
What it means

Microsoft 365 refused to relay a message from your on-premises server or device because it no longer matches the inbound connector that should identify it, by certificate or by IP address.

What the bounce says
550 5.7.64 TenantAttribution; Relay Access Denied SMTP.

The error users see, as quoted in Microsoft's article on 550 5.7.64 TenantAttribution.

What 550 5.7.64 means

Microsoft documents 550 5.7.64 for organizations that send mail from an on-premises email environment (often a hybrid Exchange server) out through Microsoft 365. To relay that mail, Microsoft 365 has to recognize the submitting server, using an inbound connector that identifies it either by a certificate (the method Microsoft recommends) or by IP address. When it can't attribute the connection to your tenant, it refuses with "TenantAttribution; Relay Access Denied".

Microsoft names two causes. Either the certificate presented by the on-premises server no longer matches the one specified on the Microsoft 365 connector, for example after a configuration change or a new or renewed certificate with a different name, or the IP address configured on the connector no longer matches the address the submitting server actually uses. Microsoft also notes that the sender's domain must be verified in the tenant to relay through Microsoft 365.

Only an email admin can fix it. For hybrid setups, Microsoft recommends rerunning the Hybrid Configuration Wizard and selecting the new certificate, so the connector's TlsSenderCertificateName matches the certificate the on-premises server presents. Otherwise, update the inbound connector by hand: check the send connector's protocol logs to see which certificate is really sent, then make the connector match it. The NDR's diagnostic section holds the original error, which helps confirm which case you're in.

Likely causes

  • The on-premises server's certificate was renewed or replaced, and its name no longer matches the inbound connector.
  • The submitting server's public IP address changed, so it no longer matches the IP-based inbound connector.
  • The sender's domain isn't verified in the Microsoft 365 tenant.
  • A configuration change on the on-premises side made the connector settings incorrect.

How to fix it

If you sent the message

  1. Forward the NDR to your email admin: Microsoft says only an admin can fix 550 5.7.64.
  2. Admins in hybrid setups: rerun the Hybrid Configuration Wizard and select the current certificate on the transport certificate page.
  3. Without the wizard: read the send connector's protocol log for the certificate subject, then set the inbound connector's TlsSenderCertificateName to match.
  4. For IP-based connectors, update the connector with the server's current public IP address.
  5. Confirm the sender's domain is an accepted, verified domain in the tenant.

If you're the recipient or their admin

  1. No action needed by external recipients: the problem is in the sender's Microsoft 365 connector setup.
MX Lookup Email Header Analyzer SPF Checker

Frequently asked questions

Why did 550 5.7.64 start right after we renewed our Exchange certificate?

Because the Microsoft 365 inbound connector still expects the old certificate. Microsoft lists a new or renewed certificate with a different name as a cause. Rerun the Hybrid Configuration Wizard with the new certificate, or update the connector's certificate name by hand.

Can a user fix the 5.7.64 TenantAttribution error?

No. Microsoft says only an email admin in the Microsoft 365 organization can fix it, because the fix is in the connector configuration. Forward the bounce, including its diagnostic section, to your admin.

Sources

  1. 550 5.7.64 TenantAttribution when users send mails externally (Microsoft Learn)
  2. Fix NDR error 5.7.64 in Exchange Online (Microsoft Learn)
  3. Email nondelivery reports (NDRs) and SMTP errors in Exchange Online (Microsoft Learn)

Provider messages are quoted as the provider publishes them. Servers can change their wording, so the bounce you received may differ slightly.

Related codes

Related guides

Setup guides

Microsoft 365 connectors explained: when you need them and how they work

When Exchange Online needs inbound or outbound connectors: Partner vs on-premises types, TLS certificate and IP matching, smart hosts, validation and mistakes.

9 min read Email security basics

What is a smart host, and when do you need an SMTP relay?

What a smart host (SMTP relay) is, how it differs from an open relay, when apps, printers and servers need one, how to authenticate, and the SPF and DKIM impact.

9 min read Setup guides

How do you set up scan to email and app SMTP with Microsoft 365?

Set up a printer, scanner or app to send through Microsoft 365: SMTP AUTH on port 587, a relay connector, Direct Send or HVE, and the Basic auth retirement.

11 min read