What to Do About an Email Forwarding Loop in 2026? Find the Addresses Forwarding to Each Other First

A message keeps arriving more than once, or a delivery failure notice appears after you changed a forwarding rule.

Fastest fix: Pause new forwarding changes, map each address-to-address route, then remove one confirmed link in the loop. If the message is duplicated, first check whether separate routes deliver it to the same inbox.

This guide is for people who forward mail between personal accounts and aliases, and for freelancers routing messages by client or project.
It’s also for anyone maintaining long-term addresses who wants a repair they can verify without losing an important message.

Repeated messages and failed delivery point to different problems

A forwarding loop is only one explanation for mail that behaves unexpectedly. Start with the observable result, not the assumption that a rule must be looping. A loop means that a message can travel through forwarding rules and eventually return to an address or system it already passed through. A duplicate can instead come from two independent routes that happen to end at the same inbox.

Does a forwarding loop cause duplicate mail or a bounce? Either outcome is possible, but neither proves a loop on its own. A service may stop a route and send a non-delivery report; another service may handle the situation differently. Repeated copies can also result from parallel delivery, without any address forwarding back to itself.

Before changing a setting, record one test message’s results:

• Which address received the original message?
• Which inboxes received copies, and how many copies appeared?
• Did any copy arrive through a forwarding rule, alias, filter, or group?
• Did a bounce arrive? If so, save the full notice and its diagnostic text.
• Was the message delivered to spam, another folder, or quarantine rather than missing entirely?

That record gives you a baseline to compare with the result after a change. Use a noncritical test message, not a password reset, invoice, client request, or account recovery message.

A message that appears in spam or a filtered folder is a classification issue until evidence shows that forwarding caused it. A message that never reaches the intended inbox may have a source-side, destination-side, routing, or forwarding problem. Treat these as separate symptoms; adding another rule before identifying the failure can make the route harder to understand.

A route map reveals a loop better than one inbox setting

Look across every system in the route, not just the account where the symptom appeared. A path can include a mailbox, an alias, a group, a hosted domain, and an automatic forwarding rule. One inbox’s settings may look correct while a rule farther along sends the message back toward the starting point.

Use a simple route notation. Write the source on the left and the destination on the right:

client@sample.test → project@sample.test → personal@sample.test → client@sample.test

The final arrow returns to the starting address, so the path contains a loop. These are illustrative addresses, not real accounts. A route that ends at the intended destination without returning to an earlier address is not a loop just because it crosses several mailboxes.

How can you tell whether two mailboxes forward to each other? Record every active rule as a separate arrow, then follow the arrows from the address that first receives the message. If the route returns to an address already visited, you have evidence of a loop. If two arrows lead independently to the same destination, investigate parallel delivery instead.

For each arrow, note the address that receives the message, the target address, and where the rule is configured. Include aliases, group membership, and rules managed by an administrator. This matters because an alias may deliver to a mailbox without behaving like a separate mailbox, while an automatic forwarding rule actively sends a message onward. Filters and automatic replies can also affect processing, but they are not the same thing as forwarding.

A route table makes gaps and duplicate destinations easier to spot:

If you manage several aliases for different projects, keep the route map with the address records. A basic alias and forwarding path planner can help you decide which address should receive a message and which mailbox should remain the final destination. Don’t assume the name of a setting tells you the whole route; check what it actually delivers to.

Delivery evidence is stronger than a guess from the inbox

A bounce and a full message header can help you identify which system handled a message. Save the complete non-delivery report, including its diagnostic details, rather than relying on a short notification such as “message not delivered.” Some services include the affected address, a status code, or an explanation of the route failure. The information available varies by service, so treat a code as a clue within that service’s documented behavior, not a universal rule.

For example, the documentation for one hosted mail system covers routing-related non-delivery codes in the 5.4.6 through 5.4.20 range. That range describes codes addressed in that product’s troubleshooting guidance; it does not establish that every provider uses the same detection method or error wording. Compare the bounce with the service-specific explanation of routing and delivery error codes before deciding which rule to change.

The SMTP standard also separates reply codes by their first digit: 4 indicates a transient negative completion, while 5 indicates a permanent negative completion. This is useful when reading a diagnostic, but it doesn’t identify a loop by itself. The SMTP reply-code definitions explain what the code class means; the server’s accompanying text and the addresses in the route provide the context.

Headers offer another trace. The standard describes the Received field as part of the information added as a message passes through SMTP servers. These entries can reveal handling systems and the sequence in which they appear, but not every provider exposes the same amount of detail, and forwarding can alter what is visible. Use the standard’s explanation of message trace fields as a guide, then inspect the full header using the receiving service’s instructions. A provider’s guide to viewing full message headers shows one example of that process.

What should you check after receiving a forwarding bounce? First compare the sender, recipient, diagnostic text, and any listed routing details with your route map. Then check the forwarding rule at the address named in the notice and the destination’s ability to receive mail. If the report names a managed group or hosted address, ask its administrator to verify that setting. Don’t create a replacement rule until you understand which existing route failed.

One loop is not the same as two routes to one inbox

When copies arrive more than once, compare the delivery paths before removing anything. Two separate addresses might both forward a newsletter to the same personal inbox. A mailbox alias may also deliver to that inbox while a separate rule forwards the original message there. The destination sees duplicates, but neither route necessarily returns to its starting point.

Check the message details side by side. If the copies have different recipient or routing information, that may point to independent delivery paths. If the same address appears again as a destination further along a mapped route, investigate a loop. Header details can support this comparison, but they are not guaranteed to show the entire path.

A forwarding rule, a filter, and an automatic reply solve different problems:

• Alias: provides another address that may deliver to an existing mailbox. Its behavior depends on how the address is configured.
• Automatic forwarding: sends a received message onward to a specified destination.
• Filter or inbox rule: sorts, labels, moves, or otherwise handles mail after a service evaluates it. Some rules can also forward or redirect messages, so inspect their actions.
• Automatic reply: sends a response to a sender; it doesn’t by itself route the original message to another inbox.
• Group or distribution address: may deliver a message to several members, each with their own forwarding rules.

The official forwarding setup instructions for one consumer mail service show why you should identify the exact setting involved rather than treating every address, filter, and forwarding action as interchangeable. Another guide to automatic forwarding and mail rules illustrates that forwarding can be managed in different parts of an account interface. These are product-specific examples, not universal instructions.

A staged repair limits the chance of losing mail

Use the smallest change that breaks a confirmed loop. Keep the remaining path intact if it still delivers messages to the intended inbox. If you don’t control one of the systems, pause and ask its administrator to verify the relevant rule rather than guessing.

Step one: Freeze changes and preserve the evidence

Stop adding, copying, or modifying forwarding rules while you investigate. Save the bounce and record where the test message appeared. If an urgent project or client address is involved, keep the current route documented so you can restore it if a change has an unexpected effect.

Step two: List every address and rule in scope

Include the source address, all aliases, forwarding destinations, groups, and any filters with a forward or redirect action. Mark which settings you can edit and which belong to a provider or administrator. If a rule target changed recently, write down both the previous and current destination.

Step three: Draw the arrows and test for a return path

Follow each route from the original recipient. If it reaches an address already encountered, mark that segment as a possible loop. If separate arrows lead to the same inbox, mark them as parallel paths instead. Don’t merge those cases: a duplicate caused by two valid routes needs a different fix from a route that returns to its origin.

Step four: Disable one confirmed loop edge

Choose one forwarding rule that clearly completes the cycle and pause or remove that rule. Avoid changing unrelated aliases and filters at the same time. If the route is managed by an organization, have the administrator confirm the effect before making a change.

Step five: Test the original and destination inboxes

Send a noncritical message through the original path. Check the source inbox, intended destination, spam and filtered folders, and any bounce notices. Compare the result with your baseline. A clean test should show the expected delivery path without a new loop-related failure; it doesn’t need to produce a specific number of copies if your setup intentionally delivers to multiple destinations.

Step six: Record the repaired route

Update the route map with the active destination, the rule’s owner, and the reason for the change. When an address or target changes later, compare the new arrows against the existing route before enabling them. For interface-specific instructions, use the official forwarding and rule settings guide for the account you manage, since menus and available controls vary.

Should you turn off a rule and assume the problem is fixed? No. Verify with a fresh, noncritical message and inspect both the original and destination inboxes. If delivery still fails, compare the new bounce or header evidence with your route map before changing another setting.

Choose the next action from the evidence

Use these conditions to avoid trial-and-error changes:

• If an address returns to an earlier address in the mapped route, pause one rule on that loop and verify delivery. Don’t add another forward.
• If separate routes reach the same inbox without returning to an earlier address, review aliases, group delivery, and duplicate rules. Keep any route that is still needed.
• If you have a bounce with a routing diagnostic, use the named address and the relevant service’s guidance to find the rule owner. Don’t treat a status code as proof without matching route evidence.
• If there is no bounce and the message is absent, check the original inbox, destination, spam, filters, and administrator-managed settings before calling it a loop.
• If an essential account depends on the address, keep a long-term mailbox you can access directly for recovery and important notices. Don’t make a short-lived receiving address the only recovery path.

The last condition matters when simplifying an inbox. A forwarding alias can separate subscriptions or project mail from your primary address, but the recovery address for financial, government, or other critical accounts should remain directly accessible over time. A temporary address is a poor substitute when you must receive future recovery links or reply to messages.

Keep long-term aliases easy to audit

For each continuing alias, record its purpose, current destination, rule owner, and the condition for disabling it. A brief note such as “client project notifications → project mailbox; disable if the contract closes” is more useful than an unexplained list of addresses. Revisit the record whenever an account changes provider, an alias is retired, or a destination mailbox is replaced.

For a freelancer, grouping aliases by client or project can make an accidental route visible before it causes confusion. Keep the final destination clear, and avoid forwarding one project address through another project address unless there’s a specific reason. If you maintain a large set of addresses, an address and routing workspace can be a place to review the options currently available; confirm its live feature descriptions before relying on any particular forwarding setup.

Once the loop is identified, the repair is usually a routing decision: preserve the path you need, remove the single confirmed return edge, and test the result. If you only need a separate address for a short-lived signup or one-time message, Tempsender is another option to assess against its current page and your retention needs. Use a long-term, directly accessible mailbox for accounts that may send recovery mail or require an ongoing reply.