Emails that arrive twice in a shared inbox: find the cause
A duplicate in a shared inbox is usually one message that took two routes, like a group alias plus a direct address. Compare the headers, then remove one route.
On this page(7 sections)
When the same customer email shows up twice in your shared inbox, the sender almost never sent it twice. One message usually reached your mailbox by two routes, and each route delivered its own copy. The fix is to find the two routes and remove one, not to delete the extra copy every morning.
The risk of leaving it is real in a team inbox: two people open the two copies, both start a reply, and the customer gets two answers. This post shows how to prove which kind of duplicate you have and what to change for each.
How do I tell a true duplicate from a customer who sent it twice?
Open the raw headers of both copies and compare the Message-ID line. If the values are identical, it is one message that was delivered twice. If they differ, the sender (or their system) really sent two messages.
A Message-ID is a unique identifier that the sending system stamps on every message. RFC 5322 section 3.6.4 says it should be globally unique for each message, which is why two copies with the same one point to a delivery problem on your side rather than a sender who clicked twice. Our post on Message-ID, In-Reply-To and References explains the header in more detail.
Then compare the Received lines. The path differs between the two copies, and that difference shows you the two routes.
| What you see | What it means | Where to look |
|---|---|---|
| Same Message-ID, different Received path | One message, two delivery routes | Aliases, groups, forwarding rules |
| Same Message-ID, identical Received path | One message stored twice | A sync or import that restarted |
| Different Message-ID, same body | Sender sent twice, or a sender retry | The sender's system, not your inbox |
| Different Message-ID, seconds apart, automated sender | A webhook or job fired twice | Tell the sender, see below |
Why does one message arrive through two routes?
The three common causes are overlapping addresses, forwarding that keeps a copy, and two things syncing the same mailbox.
Overlapping addresses. A customer writes to [email protected] and also puts [email protected] in Cc. If both addresses deliver into the same shared mailbox, you get two copies. The same happens when a group address includes a person who is also a direct recipient.
Forwarding that keeps a copy. A forwarding rule on one mailbox that forwards to another, while a second rule or an alias also delivers to the destination, creates a second path. Our guide to forwarding rules gone wrong covers the loops and lost-mail cases of the same mechanism.
Two things syncing one mailbox. An email client with a broken or restarted IMAP sync, or an old import left running next to a live connection, can re-download a batch and store it again. Here the Received path is identical because nothing was delivered twice; it was stored twice.
How do I find the second route?
Work from the headers of the extra copy.
- Look at the
ToandCclines. Count how many of your own addresses appear. Two of them delivering to one mailbox is the most common answer. - Look for a header such as
X-Original-ToorDelivered-To. Many mail systems add one when a message is expanded from a group or alias, so the two copies show different values. - Read the top two
Receivedlines of each copy. A different last hop means a different route. - Check whether the copies arrived at different times. Seconds apart suggests two deliveries; hours apart suggests a forward or a re-sync.
Write down the two addresses or hops before you change anything. If you remove the wrong one, mail to that address stops arriving.
How do I stop it?
Pick the fix that matches the cause from the table above.
- Overlapping addresses: keep one public address per purpose, and make the others aliases of it instead of separate recipients. Then a message addressed to several of them is still one delivery.
- Group plus direct recipient: remove people from the group when they already receive the mail directly, or the reverse. Each person should be reachable by exactly one path.
- Forwarding: delete the rule that keeps a copy, or change it to forward without also delivering locally. Test with one message after each change.
- Sync restarts: disconnect the old client or import, and let one connection own the mailbox.
For the next few days, check the inbox for a duplicate after each change. One test message sent to every address the customer might use, including a Cc to the group, tells you quickly whether the change worked.
What should the team do while the duplicate is still arriving?
Treat the first copy anyone opens as the live one, and leave a clear mark on it before replying. In a shared inbox that means assigning the conversation to yourself or adding an internal note such as "also arrived as the 09:14 copy, handled here." The no double sends post describes the habit of claiming a thread before writing, and shared inbox ownership rules covers who owns what.
In Koltrix you can assign a conversation and add a note to it, so the second copy shows who already has it. The two copies are still two conversations until you route one of them away, so claim the one you are working in first.
What if the sender is an app that fires twice?
If the Message-ID values differ and the messages come from an automated sender, such as a form or a billing system, the duplication happens at the source. Send the sender both raw headers and the timestamps. Do not add a rule that silently drops the second copy: a rule that matches on subject and sender will eventually hide a real second message from the same customer. If you build the sending side yourself, make the send call idempotent so a retry cannot create a second message; the idempotency guide shows how.
Bottom line
- Identical
Message-IDmeans one message that arrived twice; different ones mean two sends. - Compare
To,Cc,Delivered-ToandReceivedto find the two routes. - Remove one route (an alias, a group member, a forward, a second sync) instead of deleting copies by hand.
- Until it is fixed, claim a thread with an assignment or note before replying.
- Do not auto-delete by subject. It will eventually drop a real message.
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.
