Choose the address
Use a role address such as support@ or help@, not a person's name. It survives staff changes and sets the right expectation. If you already have one, keep it: customers and old emails already point to it.
Forward a copy to the help desk
Your help desk gives you an inbound address. In your mail system, forward a copy of everything sent to support@ to it. Keep a copy in the original mailbox while you test, so nothing is lost if forwarding is wrong.
- Google Workspace: add the address as a forwarding address in the mailbox settings, then confirm with the code Google sends. If support@ is a Google Group, add the address as a member instead.
- Microsoft 365: set forwarding in the mailbox settings. If external forwarding is blocked, an admin has to allow it for that mailbox.
- Other providers: look for forwarding or a catch-all rule in the mail control panel.
Send replies from your own domain
Replies should come from support@yourcompany.com, not from a shared address of the help desk. For mail providers to trust that, add the DNS records your help desk shows: SPF, which lists who may send for your domain, and DKIM, which signs each message. Add a DMARC record too, starting with a policy that only monitors.
Wrong or missing records are the most common reason replies end up in spam, so don't skip this step.
Test the whole path
Send a test message from a personal address to support@. Check that a ticket appears, reply to it, and check how the reply looks in the inbox, including the sender name and that it isn't in spam. Then reply from the customer side and make sure the answer joins the same ticket.
Handle the awkward cases
Out-of-office replies and bounces shouldn't create tickets forever, so make sure the help desk recognises them. Add a block for known spam senders, and set an auto-reply that confirms the message arrived and says when to expect an answer.