Skip to article
BITTUMailPOWERED BY BITTU ICLOUD
The Mail BlogMail delivery

How to Recognise a Forwarding Loop from Delivery Notices

Learn to spot repeated forwarding hops in delivery notices, distinguish a likely loop from other failures, and work with the right administrator to break the cycle.

Diagram of the email path: sender, authentication and recipient.
Original BITTU Mail editorial artwork. Illustrative image.

A delivery notice can be more than a simple “message not delivered.” If it describes repeated routing attempts or names several addresses the message passed through, forwarding may be sending the message around in a circle. That can happen when one address forwards to another, and a later address forwards back to the first. The notice alone may not show who controls each step, so look for a repeated route rather than changing settings at random. This guide explains what clues to check, how to map the path, and how to confirm the forwarding chain has been corrected.

The useful bits

  • Look for addresses or routing hops that recur in the diagnostic text.
  • Write down the forwarding path before changing any settings.
  • Ask the administrator responsible for the affected addresses to break the cycle and verify the route.

What a forwarding loop looks like

Forwarding is meant to pass a message from one destination to another. A loop occurs when the route eventually points back to an address the message has already visited. For example, address A forwards to address B, while B forwards to A. Depending on the systems involved, the message may be retried or rejected after repeated routing attempts.

A delivery notice might describe too many forwarding steps, repeated delivery attempts, or a route involving multiple recipients. Exact wording varies by mail system, and a long list of addresses does not by itself prove a loop. The useful clue is a route that repeats or returns to an earlier address.

Read the notice for a repeating hop

Start with the diagnostic text in the notice, not just its subject line. Find any listed recipients, forwarding destinations, or routing steps. Copy the addresses in order as they appear. Then compare the later entries with the earlier ones: does the route return to an address already listed, or does the same pair of addresses appear more than once?

Keep the original notice intact while you investigate. It may include separate information about the failed recipient and the reason delivery stopped. A notice naming several addresses can also describe ordinary forwarding or a different delivery problem; repeated hops are stronger evidence than the number of addresses alone. If the text is unclear, share the relevant diagnostic portion with the administrator, while avoiding unnecessary exposure of message contents.

Map the route before changing anything

Make a simple sequence from the notice and any forwarding arrangements you already know about. Mark which addresses belong to your organisation, which are outside it, and which address appears more than once. This turns a confusing notice into a specific question: which forwarding rule sends the message back into a route it has already taken?

For example, a shared address might forward to a personal mailbox, while that mailbox—or another address it forwards to—returns mail to the shared address. The forward may be configured in a different account or managed by a different person. Do not assume that the mailbox receiving the notice controls every address in the route.

EXAMPLE / ADAPT TO YOUR SITUATION
Illustrative route from diagnostic text:
[help@example.com] → [archive@example.com] → [help@example.com]

Question for the administrator: Does the forwarding from [archive@example.com] send this message back to [help@example.com]?

Ask the right administrator to break the cycle

Contact the administrator responsible for the affected forwarding addresses. Provide the notice’s relevant diagnostic text, the ordered route you recorded, and the time the notice arrived. Identify the addresses that recur, but do not send passwords or one-time codes. If different people manage different addresses, the administrators may need to coordinate rather than changing only the first visible forwarding setting.

The correction is to change the forwarding path so it no longer returns to an address already in that path. The administrator can decide which destination should receive the message and which forwarding rule should be adjusted or removed. Avoid making several unrelated changes at once: that makes it harder to tell which change resolved the routing problem.

Confirm the route no longer repeats

After the administrator changes the relevant forwarding arrangement, send a controlled test message to the original address, if you are authorised to do so. Check whether it reaches the intended destination and whether a new delivery notice appears. If it fails again, compare the new diagnostic text with the old route: a changed route may reveal a remaining forwarding step, while the same repeated addresses suggest the cycle is still present.

A successful test is useful confirmation for that route, but it does not establish that every message or every forwarding path is working. If the test produces a different failure, share the new notice with the administrator; it may point to a separate delivery issue rather than the original loop.

A short checklist for the next notice

Before closing the issue, make sure the person who owns or administers each affected forwarding address knows what was changed. Keep a note of the route before and after the change, especially when multiple addresses or teams are involved. That gives the administrator a clear starting point if a similar notice returns.

  • Record the recipient and the diagnostic text from the notice.
  • List routing addresses in order and mark any that recur.
  • Ask the responsible administrator to review the forwarding path.
  • Test the original route and check for a new notice or a repeated hop.

About this guide

Prepared with AI assistance for the BITTU Mail editorial library. Check important details against your original messages and current account settings. Product access depends on your role, plan and provisioning state. Provider interfaces and requirements can change.

View current plans · Security information · Suggest a correction