550 5.7.64 TenantAttribution: fix the connector, not SPF
550 5.7.64 TenantAttribution; Relay Access Denied means Exchange Online cannot match your sending server to an inbound connector. Fix the certificate or IP.
On this page(9 sections)
550 5.7.64 TenantAttribution; Relay Access Denied is an Exchange Online rejection. It means Microsoft 365 could not match the server that submitted a message to an inbound connector in your tenant, so it refused to relay the mail. The fix is in the connector settings (a certificate name or an IP address), not in SPF or your sender reputation.
A connector is a Microsoft 365 mail flow setting that tells Exchange Online which servers it should trust to hand it mail. This guide covers what Microsoft documents about the error, how to find the mismatch, and how to avoid the wrong turns many vendor blog posts suggest.
What does 550 5.7.64 mean?
It means the submitting server failed the connector check. Microsoft's page 550 5.7.64 TenantAttribution when users send mails externally gives the symptom as users getting 550 5.7.64 TenantAttribution; Relay Access Denied SMTP when mail is relayed out through Microsoft 365.
"Relay" here means a server of yours (often an on-premises Exchange server) hands the message to Microsoft 365 and asks it to deliver to the outside world. Microsoft 365 only does that for servers it can attribute to your tenant. "TenantAttribution" is that attribution step failing.
Microsoft's NDR reference lists the usual setup behind it: an inbound connector that receives mail from your on-premises environment, where something changed on premises and the connector's configuration is now wrong.
Why is it not an SPF or reputation problem?
Because the rejection happens before any recipient server sees the message. The bounce is generated inside Microsoft 365 when your submitting server is not recognized. SPF is checked by receiving servers against the sending IP, and reputation is judged by the receiver. Neither has been reached yet.
That is the main difference from the codes people confuse it with:
| Code | Who rejects | What was wrong | First place to look |
|---|---|---|---|
| 5.7.64 | Your own Exchange Online tenant | Submitting server does not match an inbound connector | Inbound connector certificate name or IP |
| 5.7.750 | Your own tenant | High volume from a domain that is not accepted | Accepted domains list (guide) |
| 5.7.705 / 5.7.708 | Your tenant or Microsoft's edge | Tenant ban or low-reputation IP (guide) | Compromise review, source IP |
| 5.7.509 / 5.7.515 | The receiving side | DMARC or authentication failure (guide) | Your DNS records |
If you changed DNS and the error did not move, that fits: DNS was never the problem.
What are the two documented causes?
Microsoft names two causes. Both come down to the connector describing a server that no longer exists in that form.
- The certificate no longer matches. The inbound connector verifies the submitting server by certificate (Microsoft calls this the recommended method). The on-premises certificate changed or was renewed under a different name, so it no longer matches the certificate name on the connector.
- The IP address no longer matches. The connector identifies the server by IP address, and the server now sends from a different one.
Both usually follow a change someone made on purpose: a certificate renewal, a new send connector, a server move, a new firewall or NAT address. Ask what changed on the day the first bounce appeared.
How do you fix it?
You need a correctly configured connector in Microsoft 365 that matches the submitting server. Microsoft gives two routes.
Option 1: rerun the Hybrid Configuration Wizard. Microsoft recommends this for hybrid customers. Run the wizard from the Exchange admin center and make sure the new certificate is selected on the transport certificate page. Microsoft warns that any manual customization of the hybrid configuration may need to be redone afterward, and says changes may take some time to take effect.
Option 2: fix the connector by hand. Confirm which certificate your on-premises server actually presents, then make the connector say the same thing.
- Find the send connector that routes external mail to Microsoft 365 and turn on protocol logging for it.
- Read the send protocol log for the certificate subject and thumbprint sent to Exchange Online. Microsoft's example log shows a line such as
CN=*.contoso.comas the certificate subject. - Open the matching inbound connector in Microsoft 365 and compare. In Microsoft's example, the
TlsSenderCertificateNamevalue must be*.contoso.com. - If the connector uses IP addresses instead, check that the IP in the connector is the address your server now uses to reach Microsoft 365.
Microsoft adds one more requirement. To relay through Microsoft 365, the sender's domain, or the certificate's domain, must be verified in the tenant. Otherwise you can see the same error plus an explicit ATT36 error.
Checklist before you change anything
- I have the full bounce, including the "Diagnostic information for administrators" section.
- I know the date the first message failed and what changed on premises around then.
- I know whether the connector identifies the server by certificate name or by IP.
- I read the send connector log and know which certificate subject was actually sent.
- The domain in that certificate, or the sender's domain, is verified in Microsoft 365.
- I will change one thing, wait, and send a test, instead of changing several settings at once.
What if your app sends through Microsoft 365?
The documented scenario is mail relayed from an on-premises Exchange environment. If instead an application or device submits to Microsoft 365 over SMTP, the same idea applies: Microsoft 365 must be able to tell which tenant that submission belongs to, using a connector or authenticated sign-in. Microsoft documents other codes for authenticated submission problems, such as 5.7.57 for the smtp.office365.com endpoint, so check the exact code before assuming it is this one.
The simplest way to debug any of these is to reproduce one submission by hand with a tool such as swaks, so you can see exactly what the server offered and how it answered. For the trade-offs between relaying through a mailbox provider and using a sending service, see SMTP relay vs HTTP API.
What should you avoid?
- Do not edit SPF first. Microsoft's documented causes do not include SPF for this code. Extra
include:entries can push you toward the 10-lookup limit and fix nothing. - Do not open the connector to a wide IP range to make the error go away. A connector that trusts too much is the opposite of a fix, and Microsoft warns elsewhere that attackers create connectors to send spam.
- Do not ignore expiry. Certificate renewals are the most predictable cause. Put the renewal date on a calendar and add "check the Microsoft 365 connector" to the renewal steps.
- Do not guess when the NDR shows a different code. Match the exact code to Microsoft's NDR table before acting.
How do you keep it from recurring?
- Write down which servers, apps and devices submit mail to your tenant, and which connector or login each uses.
- Record the certificate name and IP each connector expects next to the certificate's renewal date.
- After any certificate, firewall or server change, send a test message to an outside address and read the result.
- If your application mail does not need to travel through your Microsoft tenant at all, a transactional service on its own verified domain removes this dependency. Koltrix's API and SMTP relay (see docs.koltrix.com) send from custom domains you verify with SPF, DKIM and DMARC records, and our post on domain verification flows shows how a clear verified or not verified state helps. That is a design choice, not a fix for an error already happening.
Bottom line
550 5.7.64 TenantAttribution; Relay Access Denied means Exchange Online could not match the server that submitted your message to an inbound connector. Microsoft documents two causes: the connector's certificate name no longer matches the server's certificate, or the connector's IP address no longer matches the server's IP. Rerun the Hybrid Configuration Wizard or correct the connector by hand, make sure the domain is verified in the tenant, and leave SPF alone.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
