How to fix '5.4.14 Hop count exceeded' email delivery errors?
Published 21 May 2025
Updated 12 Oct 2026
12 min read
Summarize with
Updated on 12 Oct 2026: We clarified accepted-domain settings and added recipient checks for Microsoft 365 mail loops.
To fix a "5.4.14 Hop count exceeded" delivery error, find and break the mail loop. The message has crossed the receiving system's loop threshold, so it returns a permanent non-delivery report (NDR). Exchange Online's ATTR codes use service loop counters, so 5.4.14 does not prove that the message crossed a fixed number of Received headers. If you do not control the recipient domain, confirm that your sender path is clean, capture the bounce details, contact the recipient domain admin, and suppress the address until its route is repaired.
Treat this error as a routing problem first, not a sender reputation problem. It can happen when a recipient domain forwards mail to another system and that system sends it back, when Microsoft 365 hybrid routing is misconfigured, when a gateway hands mail to Microsoft and Microsoft routes it back to the gateway, when an unverified Microsoft 365 domain leaves synchronized SMTP addresses incorrect, or when an unknown recipient is relayed back to a previous system instead of rejected.
Typical bounce texttext
554 5.4.14 Hop count exceeded - possible mail loop ATTR34 [CH2PEPF00000146.namprd02.prod.outlook.com 2025-04-16T04:00:51.808Z 08DD7C5B276E3B26]
What the 5.4.14 error means
Every SMTP handoff normally adds a Received header. Those headers help reveal the route, but Exchange Online can also stop a message through its own loop-attribution headers. Microsoft guidance identifies 5.4.6 with mail loops in on-premises Exchange and 5.4.14 with mail loops in Exchange Online. Microsoft's Exchange Team explains that ATTR34 identifies repeated processing within the same tenant, while ATTR1 identifies the overall Exchange Online Protection (EOP) processing limit. These service thresholds can change, so do not diagnose the loop by counting Received headers alone.
The important part is ownership. If the trace shows the loop inside the recipient's routing setup, the recipient admin owns the fix. A rejection during the SMTP handoff still requires checking both sides of the route. Your ESP or sending platform can prove it handed the message off, but it cannot rewrite the recipient's forwarding rules, connectors, tenant settings, or mailbox migration state.
Fast answer
If you are the sender, do not keep retrying the same address at volume. Check whether your own routing is looping, then send the bounce to the recipient admin with the timestamp, final host, ATTR code, and trace ID. Suppress the failing address until the route is repaired; pause a domain segment only if multiple recipients show the same routing failure.
Troubleshooting flow for a 5.4.14 Hop count exceeded mail routing loop.
How to identify the looping hop
Start with the complete NDR and the attached original message headers. Received fields appear newest first, so read them from the bottom upward to reconstruct the route in time order. Compare the from and by hosts against each timestamp. A pair of systems that appears more than once in alternating order usually exposes the loop.
Repeated Received-header patterntext
Received: from gateway.example.net by tenant.mail.protection.outlook.com; Received: from tenant.mail.protection.outlook.com by gateway.example.net; Received: from gateway.example.net by tenant.mail.protection.outlook.com;
- Find the rejecting host: Read the Remote-MTA, Diagnostic-Code, and "Message rejected by" details when present. The Reporting-MTA can be the server that generated the NDR rather than the host that rejected delivery.
- Read the route in order: Follow Received fields from the oldest entry at the bottom toward the newest entry at the top.
- Mark repeated hosts: Look for the same host pair, gateway, tenant, or connector appearing again in the same sequence.
- Correlate the trace: Match the recipient, timestamp, Message-ID, and network message ID with the platform's message trace.
- Assign the fix: The admin who controls the first repeated handoff should inspect that connector, rule, forward, or smart host.
Some NDRs contain only the final diagnostic line. In that case, the recipient admin's message trace is more useful than the visible bounce because it can show repeated RECEIVE, SEND, redirect, or transfer events for the same message. In a hybrid deployment, compare Exchange Online message trace with on-premises message tracking logs and gateway logs at the same UTC timestamp.
Common causes and who owns the fix
Most 5.4.14 cases fall into a few patterns. The route matters more than the sender's content, IP reputation, or DMARC policy. Authentication still matters for deliverability, but a hop count error says the message could not complete its path after SMTP routing began.
|
|
|
|---|---|---|
Forwarding loop | Recipient admin | Mailbox forwarding, inbox rules, and contact targets |
Hybrid connector loop | Tenant admin | Connectors, accepted domains, and recipient objects |
Gateway bounce-back | Gateway admin | MX, smart host, and tenant handoff |
Unknown recipient or stale alias | Recipient admin | Recipient directory, aliases, and unknown-recipient handling |
Domain migration | Domain admin | Old MX paths and inactive mailboxes |
Unverified Microsoft 365 domain | Microsoft 365 admin | Domain verification and synced SMTP addresses |
Common 5.4.14 causes
A common real-world pattern is an acquired or retired domain that still has live MX records. Mail enters a security gateway, goes to Microsoft 365, gets redirected to another target, and then loops back. The sender sees the bounce, but the broken route sits inside the destination's mail setup. Multiple MX records do not create a loop by themselves; the loop comes from systems routing the message back to each other.
Example of a gateway routing looptext
Recipient domain MX -> inbound gateway Inbound gateway -> Microsoft 365 tenant Microsoft 365 routes the recipient domain -> inbound gateway Inbound gateway -> Microsoft 365 tenant (repeated handoff)
Step by step fix for senders
If you are sending a campaign or transactional email, separate a broken recipient route or bad address from a problem in your own sending path. This order stops wasted retries and gives the responsible admin the evidence needed to investigate.
- Capture the bounce: Save the complete NDR and attached headers, including the SMTP status, ATTR code, hostname, timestamp, Message-ID, and recipient address.
- Check your trace: Confirm your platform handed the message to the recipient MX or next hop without looping internally.
- Inspect the recipient: Confirm the recipient address and alias with the owner, then look up the domain's MX records and compare them with the host named in the bounce.
- Run one controlled test: Send a separate message to Suped's email tester to check authentication and headers. Retest the failing recipient only after a routing repair.
- Escalate with evidence: Ask the recipient admin to review connectors, forwarding, aliases, domain verification, and migration state.
- Suppress the failure: Pause the failing address until the owner confirms the route is fixed. Pause a domain segment only when multiple recipients share the failure.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Suped's email tester checks authentication and headers for mail sent to its test address. That message follows a different recipient route, so a clean result does not prove delivery to the failing address or identify the looping connector. Use the affected message's NDR and trace to investigate that route.
For domain-level checks, use Suped's domain health checker before escalating. It catches missing or malformed records, while the NDR and message trace still show where the hop loop happened.
Email tester sample report showing total score, email preview, issue summary, and per-section results
Step by step fix for recipient admins
If you control the destination domain, the fix is inside your routing setup. Start with the exact timestamp, recipient, and Message-ID from the NDR, then run a message trace in your mail platform. Look for repeated handoffs between the same systems, or for the message leaving your tenant and re-entering it.
Sender-side checks
- Trace handoff: Confirm the message left the ESP or MTA once, without internal cycling.
- Address quality: Confirm the address is valid and suppress repeated routing failures until repair; a role address alone does not prove a loop.
- Authentication proof: Document SPF/DKIM authentication and DMARC identifier matching for the test message.
Recipient-side fixes
- Connector routing: Stop connectors from sending the same domain back to the previous hop.
- Forwarding targets: Correct the specific contact target, inbox rule, transport rule, or mailbox forward that returns the message.
- Accepted domain state: Choose Authoritative or Internal relay based on recipient directory coverage and the intended relay route.
In Microsoft 365 hybrid environments, Authoritative works when every valid recipient is listed in Exchange Online's directory, including synchronized mail users whose mailboxes are on-premises. Internal relay is for routing recipients unknown to that directory to another system through a working connector. Also verify every custom domain in Microsoft 365 and check that synchronized users have the expected primary and proxy SMTP addresses.
For a hybrid deployment, Microsoft recommends rerunning the Hybrid Configuration Wizard to rebuild the intended connector settings. If inbound MX points to Exchange Online, the connector to on-premises Exchange should use the hybrid server as a smart host instead of routing the domain back through DNS. If centralized mail transport is enabled, confirm that the dedicated outbound connector has ConnectorType set to OnPremises and is not scoped to accepted domains.
Check centralized mail transportpowershell
Get-OutboundConnector -Identity "<Connector Name>" | Format-List Name,ConnectorType,SmartHosts,UseMXRecord,RouteAllMessagesViaOnPremises,RecipientDomains
- Trace IDs: Use the final host and timestamp from the NDR to pull the exact message trace.
- Transport rules: Use the trace to identify the rule that sends the message back, then temporarily disable only that rule for a controlled test.
- MX and gateway: Confirm the inbound gateway sends accepted mail to the final mailbox system only once.
- Role aliases: Verify postmaster, abuse, and support aliases resolve to valid recipients. For shared-mailbox failures, compare a failing trace with a successful one and inspect mailbox forwarding, inbox rules, and sender-specific transport rules.
Check accepted domains and recipient objects in Microsoft 365
In the Exchange admin center (EAC), open Mail flow > Accepted domains and inspect the affected domain. Microsoft's accepted-domain documentation permits Authoritative in hybrid setups when every valid recipient is listed in Microsoft 365. An obsolete Internal relay setting after a completed migration can send unknown recipients back to a gateway that returns them to Exchange Online.
In an authenticated Exchange Online PowerShell session, replace these example values with the affected domain and address. These commands inspect the current configuration:
Inspect the accepted domain and recipientpowershell
Get-AcceptedDomain -Identity "example.com" | Format-List Name,DomainName,DomainType Get-EXORecipient -Identity "user@example.com" -Properties EmailAddresses | Format-List DisplayName,RecipientTypeDetails,PrimarySmtpAddress,EmailAddresses
If the recipient is absent or the alias is missing, confirm whether it should exist and repair the mailbox, mail user, or directory synchronization. If Internal relay is required, check that its connector reaches the downstream mailbox system without routing back through the same MX. Do not switch domain types until every valid recipient has a delivery route.
For unverified custom domains, add and verify the domain in Microsoft 365, then recheck synchronized primary and proxy SMTP addresses. Verification is a separate check from choosing the accepted-domain type.
Why authentication and reputation do not fix mail loops
A hop count error can look alarming because the NDR has a 554 permanent failure code. That does not mean your domain is on a blocklist (blacklist) or failing authentication. Investigate authentication or reputation when there is separate evidence of a sender-side problem. Increasing a hop limit only delays rejection of a repeating route; it does not repair it.
How to prioritize a 5.4.14 incident
Treat volume and repeat pattern as the signal, not the single error code alone.
Single address
Low
Suppress it and ask the recipient admin to repair the mailbox route.
One recipient domain
Medium
Escalate with trace details because the domain likely has a routing fault.
Many domains
High
Audit your own MTA, gateway, and ESP handoff because the sender route is suspect.
If many unrelated recipient domains return 5.4.14 after the same deployment or gateway change, look inward first. Review outbound connectors, smart host configuration, sender-specific routing rules, and any new security gateway path. If only one domain or address fails, especially a role account or retired brand domain, the recipient side is the stronger suspect.
For normal bounce triage beyond this one error, a broader bounce message workflow helps separate policy rejections, mailbox problems, connection failures, and routing loops.
How Suped helps with evidence
Suped is our DMARC reporting and email authentication platform, and its role here is to document sender-side health. Use aggregate reports to review SPF/DKIM results and DMARC identifier matching for sending sources. Use a test message for individual header checks, and the affected message's NDR and trace to locate the routing loop.
Suped's DMARC monitoring and blocklist (blacklist) alerts help identify separate authentication or reputation issues. Aggregate DMARC reports do not show SMTP delivery paths or prove that a specific bounced message passed authentication. For a 5.4.14 case, pair the full NDR with a matching message trace keyed by Message-ID. The trace remains the evidence that locates the loop.
Practical workflow
- Monitor authentication: Use Suped's aggregate DMARC reports to review SPF/DKIM results and identifier matching for the sending source.
- Clean the sender side: Resolve detected DNS or authentication issues without treating them as the loop cause.
- Escalate clearly: Send the recipient admin the sender-side evidence, complete NDR, and trace details.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Views from the trenches
Best practices
Check the full message trace before blaming the ESP; hop loops usually start downstream.
Suppress repeat-bouncing role accounts when the recipient domain cannot repair routing quickly.
Confirm MX records and forwarding paths before retrying the same failing address repeatedly.
Common pitfalls
Treating every 5.4.14 as sender reputation wastes time when the route itself loops badly.
Keeping postmaster or other role accounts in marketing lists invites low-value bounces later.
Retrying a looping address at volume creates more NDRs without improving delivery at all.
Expert tips
Ask the recipient admin for the trace ID, timestamp, and final accepted handoff host.
Save the full NDR because ATTR codes and hostnames help prove the loop location fast.
After the route is repaired, test the affected recipient and confirm delivery in the trace.
Marketer view
Marketer from Email Geeks says a hop count error means the message is being passed around between servers until the receiving system stops it to prevent an endless loop.
2025-04-16 - Email Geeks
Marketer view
Marketer from Email Geeks says this is usually a destination-side problem, especially when Microsoft 365, forwarding, or hybrid routing is involved.
2025-04-16 - Email Geeks
Verify delivery after fixing the mail loop
After correcting the connector, smart host, rule, or forwarding target, send one controlled message to the affected recipient. Confirm that it reaches the intended mailbox and that the trace no longer repeats the same handoff. For hybrid routes, compare the cloud trace with on-premises tracking logs. A successful connector validation alone does not establish delivery to every recipient.
For a completed cloud migration, confirm that known recipients receive mail and that nonexistent addresses are rejected instead of relayed back to the gateway. Resume sending to previously suppressed addresses after successful delivery is confirmed. If the loop persists, give Microsoft support the full NDR, UTC timestamp, recipient, Message-ID, network message ID if available, and traces for each hop.
