What's the difference between 554 5.4.14 and 554 5.4.6?

They're the same underlying failure — a mail loop that blew past the hop limit — but they tell you *where* the loop lives. Microsoft maps 5.4.6 to a loop involving on-premises Exchange and 5.4.14 to a loop detected inside Exchange Online. So 5.4.14 with 'possible mail loop ATTR34' means Exchange Online Protection kept handing the same message back to itself within your tenant until it hit the ceiling. That distinction matters because it points your investigation at different config: 5.4.6 sends you to the on-prem send connectors and the hybrid routing, while 5.4.14 sends you to your Microsoft 365 accepted domains, connectors, and mail-flow rules. Both are configuration problems, not transient errors — the message will loop again on every retry until you break the circle.

What does ATTR34 mean in the bounce, and how is it different from ATTR1?

Those are Exchange Online's own loop counters, and they're more useful than the generic 'hop count' because they say which limit you tripped. Exchange Online stamps attribution headers that record how many times Exchange Online Protection has processed a message inside a tenancy; that counter resets when the message is forwarded into a different tenant. Microsoft currently permits a total of seven hops, or three within a single tenant's environment. Exceed the overall total and you get ATTR1; exceed the within-a-tenancy limit and you get ATTR34. So 'ATTR34' is specifically 'this message bounced around inside one tenant too many times' — which almost always means a forwarding rule, connector, or unverified domain in *that* tenant is feeding the message back to itself. It's a strong hint to look at your own mail-flow config rather than the sender's.

The sender's address and our SPF and DKIM are all fine. Why is mail still bouncing with 5.4.14?

Because 5.4.14 isn't an authentication verdict — it never looks at SPF, DKIM, or DMARC. It's a *routing* failure: the message is structurally deliverable and correctly signed, but the path it's taking never terminates at a final mailbox. The message leaves a server, arrives somewhere that forwards it right back, leaves again, and repeats until the hop counter caps out. That's why fixing your email authentication does nothing here — the loop is in how mail is routed, not in who's allowed to send it. The usual culprits are an unverified domain in Microsoft 365, a hybrid connector pointing back to the cloud that sends it back on-prem, or a forwarding rule where A forwards to B and B forwards to A. Read the Received headers in the bounce: a loop shows the same hosts repeating, and that repetition is your map.

Views: 23

554 5.4.14 Hop Count Exceeded (Mail Loop): Fix

554 5.4.14 Hop count exceeded means your mail is looping. Trace the loop via Received headers and MX routing, then fix it. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

A message bounces with 554 5.4.14 Hop count exceeded - possible mail loop ATTR34 and never reaches the recipient. The instinct is to treat it like a sender-reputation or authentication problem and start checking SPF and DKIM. Wrong tree. This code has nothing to do with who’s allowed to send. It means the message got stuck in a loop — leaving a server, arriving somewhere that sends it straight back, over and over — until it crossed the hop limit and Exchange Online killed it. The fix is in your mail routing, and until you break the loop, every retry does the exact same lap.

Symptoms

Senders get a non-delivery report reading 554 5.4.14 Hop count exceeded - possible mail loop ATTR34 (sometimes ATTR1).
It affects specific domains or recipients, not everyone — usually ones tied to a recent DNS, connector, or forwarding change.
The message headers show the same host or hop repeating many times.
The related code 554 5.4.6 appears when the loop involves on-premises Exchange instead of Exchange Online.
Retrying, resending, or waiting changes nothing — the message loops again every time.

What This Error Actually Means

SMTP has counted its own footsteps since the beginning. RFC 5321 §6.3 defines loop detection by counting Received: header fields — every server that handles a message adds one, so a message that keeps circling accumulates them. The spec’s own advice is to use a large threshold (“normally at least 100 Received entries”) precisely so legitimate long paths aren’t mistaken for loops. That’s the universal mechanism underneath every “too many hops” bounce.

Exchange Online layers something sharper on top. Instead of only counting raw Received: lines, it stamps its own attribution counters — the ATTR values in the bounce — recording how many times Exchange Online Protection has processed the message within a tenancy. Microsoft currently allows a total of seven hops, or three inside a single tenant’s environment; blow the overall total and you get ATTR1, blow the within-tenant limit and you get ATTR34. The enhanced status 5.4.14 is Exchange Online’s “routing loop detected,” and its sibling 5.4.6 is the same verdict when on-premises Exchange is in the loop.

The important part: this is a deterministic configuration failure, not a flaky one. The message is well-formed and often perfectly authenticated. It’s the path that’s broken — it has no terminating mailbox, so it revisits the same hop until the counter caps. That’s why “just resend it” never works and why the diagnosis is always “find the two (or three) places that keep handing the message back and forth.”

Top 3 Causes

An unverified domain in Microsoft 365. This is Microsoft’s own most-cited cause, and it happens by design: mail arrives for a domain your tenant handles but that isn’t added and verified as an accepted domain, so Exchange Online can’t attribute it to a real mailbox and keeps re-processing it until the hop limit trips. The fix is boring and exact — add the domain and complete verification.
A hybrid connector pointing the wrong way. In a hybrid on-prem/cloud setup, a send connector on-premises routes a message to Exchange Online, which — because of how the domain’s routing is configured — sends it right back on-premises, which sends it up again. Each side thinks the other owns the mailbox. This is the classic 5.4.6/5.4.14 pair, and the fix is making the connectors and accepted-domain types agree on who delivers.
Circular forwarding or a redirect rule. Mailbox A forwards to B while B forwards back to A; or a transport rule redirects to an address that routes back into the same system; or a third-party filter forwards to Microsoft 365 while the MX (or a stale rule) sends it back to the filter. Two forwards that point at each other are all it takes.

Diagnose with DechoNet

Email Check reads the domain’s MX records and mail routing from outside your infrastructure and shows where inbound mail is actually destined. A loop almost always traces to mail being handed somewhere that forwards it back — so confirm the MX points at the final authoritative host (for Microsoft 365, a *.mail.protection.outlook.com endpoint) and not at an intermediate filter or old server that will bounce it into the cloud and back. If the MX points somewhere that isn’t the real mailbox host, you’ve found one leg of the loop.
DNS Check shows the raw MX priorities and any conflicting or leftover records. A duplicate or stale MX from a migration is a common way a message ends up ping-ponging between the old and new mail hosts.

Resolution Checklist

Read the Received headers in the bounce. The NDR carries the message’s path. A loop shows the same hosts repeating — that repetition is the map of where the message is circling. Start there.
Check the ATTR value. ATTR34 means the loop is inside one tenant — look at your own accepted domains, connectors, and mail-flow rules. ATTR1 means the overall hop total blew — a longer external path is folding back on itself.
Verify every domain in Microsoft 365. For any domain your tenant handles, confirm it’s added and verified as an accepted domain. An unverified domain is Microsoft’s most common cause and loops by design.
Audit hybrid connectors. In an on-prem/cloud setup, make sure the send/receive connectors and the accepted-domain type (authoritative vs. internal relay) agree on who owns the mailbox, so neither side bounces mail back to the other.
Hunt down circular forwarding. Check mailbox forwarding, transport/mail-flow rules, and any third-party filter for A→B→A patterns. Remove the one that points backward.
Confirm the MX with an external check. Run Email Check and verify inbound mail is destined for the real, final mailbox host — not an intermediate that will route it back. Don’t just retry the message; the loop will run again until the config changes.

When to Escalate

If your domains are verified, connectors look correct, and no forwarding rule explains it, escalate to whoever administers the mail platform (Microsoft 365 / Exchange admin) with the full Received-header trace from a bounced message — the repeating hops tell them exactly which two systems are handing the message back and forth.
If the loop involves a third-party gateway or filter in front of Microsoft 365, coordinate with that vendor: the fix is usually aligning their forwarding target and your MX so mail lands at the mailbox host once, not in a circle.