Email Routing Checklist After Switching Help Desks

By the end of this tutorial you will have every customer-facing email address delivering into your new help desk, replies going out from the right address, and a way to confirm that nothing is slipping through. Moving tickets is only half of a migration. If email still points at the old tool, customers keep writing into a system nobody is watching.

Before you start, have these ready:

• Admin access to your email provider (and your domain's DNS settings, if you manage them)
• Login access to both the old and new help desk
• A list of every address customers use to reach you
• A personal email account outside your company domain for testing
• An hour or two when support volume is normally low

Step 1: List every address that feeds your old help desk

Start with an inventory. Open the old help desk's email or channel settings and write down each address it receives mail from. Then check your email provider for aliases and forwarding rules that point at it.

Your list will usually include support@, help@, billing@ or orders@, plus any older addresses still printed on invoices, packaging, or website footers. Also look for contact form notifications and system emails that create tickets, such as notices from your store or app.

Why it matters: addresses you forget about are the ones that quietly stop working. A customer who writes to an old address from a year-old receipt gets no answer, and you never know it happened.

For each address, note three things: where it goes today, which team or queue should handle it, and who owns the decision if something goes wrong.

Step 2: Choose how each address will reach the new help desk

There are generally two ways email gets into a help desk:

1. Forwarding. Your email provider forwards messages from support@yourcompany.com to an inbound address the new help desk gives you. This is the simplest option and easy to reverse.
2. Connecting the mailbox or changing DNS records. Some tools connect to a mailbox directly, and some setups involve changing MX records so mail is delivered elsewhere. This is more involved, and a mistake can affect all email on the domain, not just support mail.

For most small teams, forwarding is the safer starting point. If your new tool asks for DNS changes, read its setup instructions carefully and confirm the details for your email provider. Lowering the TTL (the caching time) on any record you plan to change, a day or so ahead, makes it quicker to roll back.

Why it matters: forwarding can be switched off in a minute. DNS changes can take time to spread, which makes them harder to undo if something looks wrong.

Step 3: Set up the new inbound path while the old one still runs

Do not turn anything off yet. In the new help desk, configure the inbound address or connection for one low-risk address first, such as a secondary alias.

Then send it a test message and confirm that:

• A ticket is created automatically from the email
• The subject, body, sender name and sender address are intact
• Attachments arrive and open
• The ticket shows up in the shared inbox where your team will actually look

NeuraDesk converts incoming email into tickets automatically and shows them in a shared inbox, and it is free to start with no credit card, so you can run this kind of test before you commit your main address. Whatever tool you use, the principle is the same: prove the path with a low-stakes address before touching your main one.

Why it matters: you want to find a problem while the old system is still catching everything.

Step 4: Check the reply path, not just the inbound path

Receiving email is only half of routing. Open a test ticket, reply to it, and read what arrives at your external test account.

Check these points:

• The From address. Does it show your support address or something unfamiliar?
• The reply thread. When you answer the reply from your test account, does it attach to the same ticket rather than creating a new one?
• Spam placement. Did the message reach the inbox, or the spam folder?

If your replies go out under your own domain, your domain's email authentication records (SPF, DKIM and DMARC) may need updating so the new tool is allowed to send on your behalf. The exact steps depend on your email provider and help desk, so follow the new tool's documentation and confirm with whoever manages your DNS.

Why it matters: a customer who receives a reply from an odd address, or finds it in spam, may assume you never answered.

Step 5: Run a full test matrix

Before cutting over, test each address on your list from Step 1. A simple grid is enough: address, test sent, ticket created, reply sent, reply received, thread correct.

Include a few awkward cases:

• An email with a large attachment
• A message with a CC to a colleague
• A reply to an old ticket thread from before the migration
• An email from a different provider (Gmail and Outlook behave differently in small ways)

Why it matters: the happy path almost always works. Problems tend to hide in attachments, CCs and old threads.

Step 6: Cut over one address at a time

Now switch the real addresses. Begin with the lowest-volume one, watch it for a few hours, then move the rest. Leave your highest-volume address (usually support@) until you have seen the others behave.

For each address:

1. Change the forwarding rule or connection so it points to the new help desk.
2. Send a fresh test email immediately.
3. Confirm the ticket appears in the new shared inbox.
4. Tell your team the address is live, and who is covering it.

If you can, do the switch at a quiet time and avoid Fridays or the day before a sale or launch.

Why it matters: moving one address at a time limits the damage if something is wrong, and it makes the cause obvious.

Step 7: Keep the old help desk watched, not abandoned

For at least a couple of weeks, keep the old system accessible. Customers will reply to older conversations, and some of those replies may still land there.

Set a routine: check the old inbox once or twice a day, and move any stragglers into the new one manually. Once a week passes with nothing new arriving, you can plan to retire it.

Step 8: Monitor the first week

After cutover, compare your expectations with reality. If you normally get a rough number of emails a day and the new inbox is much quieter, something is probably misrouted.

Check daily for:

• Addresses that have gone silent
• Tickets with no assignee or status
• Bounce messages or delivery failure notices
• Customers writing in to ask whether you received their email

Ticket status tracking helps here: anything sitting in a new or unassigned state for too long is a sign that routing or ownership is off.

Common mistakes to avoid

• Switching everything at once. If it fails, you will not know which address caused it.
• Forgetting old and secondary addresses. Printed materials outlive your plans.
• Creating a forwarding loop. If the help desk sends mail to an address that forwards back to the help desk, tickets can multiply. Test with one message and watch for repeats.
• Testing only from inside your company. Internal mail sometimes behaves differently from mail sent by customers.
• Skipping the reply test. Inbound working does not mean outbound works.
• Not assigning ownership. If every address lands in a shared inbox but nobody is responsible for checking it, messages sit. A shared inbox works best with clear coverage.
• Shutting down the old tool too early. Keep it available until you are confident nothing is still arriving.

A quick checklist to finish

• Every customer-facing address is listed and mapped
• Each one creates a ticket in the new help desk
• Replies come from the right address and thread correctly
• Authentication records are confirmed with your provider
• The old help desk is being watched for stragglers
• Someone owns the first week of monitoring

If all six are true, your routing is in good shape. If one is shaky, fix it before you retire the old system. If you want a free help desk that handles email routing out of the box, try NeuraDesk free.