A printable support mailbox setup checklist

This is a working checklist, not a sales page. It takes a shared support address such as support@, info@ or accounts@ and connects it to a helpdesk so incoming email becomes owned tickets and your replies land in customer inboxes rather than spam folders. Print it, or copy it into your own document, and tick each item as you go.

The order matters. You set up sender authentication first (DKIM, Return-Path, DMARC) so that when you do start replying, those replies are signed and trusted. Then you forward incoming mail to your helpdesk. Then you test with a real message in each direction. Only when both directions behave do you go live and tell the team. Skipping ahead to live replies before the DNS is in place is the usual reason early replies land in spam.

Everything here is forwarding-first on purpose. You keep your existing mailbox delivering mail exactly as it does now, and a copy is forwarded to the helpdesk. You do not change your domain's MX record, so there is nothing large to roll back if you change your mind. If a step needs access you do not have, hand that single step to whoever manages your domain and carry on with the rest.

What you will need to hand

• Sign-in for your domain or DNS host (your registrar or DNS provider), so you can add DKIM, Return-Path and DMARC records.
• Admin access to the mailbox you are connecting, so you can set up a forwarding rule.
• The verification values your helpdesk gives you (the exact host names and values to paste in are shown in its mailbox setup screen).
• A second email address you control, to send a real test message from outside the mailbox.
• About twenty to forty minutes, plus up to a day for DNS to fully apply before you confirm go-live.

Work through these in order. Each step is one task with a short note. Do not move to the next step until the current one is confirmed, especially the DNS steps, which can take time to apply.

1. Domain and address

1. Confirm the support address you are connecting, for example [email protected], [email protected] or [email protected]. Note: pick the address customers already write to, not a brand new one, so you inherit existing history rather than starting cold.
2. Confirm you control the domain that address sits on and can sign in to its DNS host. Note: if the domain is managed by an agency or IT supplier, agree now who adds the DNS records so the later steps are not blocked.
3. Decide which brand this mailbox belongs to if you run more than one. Note: keep one address per customer-facing identity so replies always go out as the brand the customer wrote to.

2. DKIM (sign your outgoing replies)

1. Open your helpdesk's mailbox setup screen and copy the DKIM record it shows (a host name and a long text value). Note: this is the public half of a signing key; it is safe to publish in DNS.
2. In your DNS host, add the DKIM record exactly as given, usually as a TXT or CNAME record at the host name shown. Note: copy and paste rather than retype, since a single wrong character breaks the signature.
3. Save the record and wait for it to apply, then return to the helpdesk and let it re-check DKIM. Note: do not assume it is live the moment you save; wait for a verified tick.

3. Return-Path (align the bounce address)

1. Copy the Return-Path (also called envelope sender or custom MAIL FROM) record from your helpdesk, again a host name and a value. Note: this sets where delivery failures go and helps SPF and DMARC line up with your domain.
2. Add the Return-Path record at your DNS host exactly as shown. Note: it is usually a CNAME pointing a sub-domain of yours at the sending service.
3. Save and wait, then re-check Return-Path in the helpdesk until it verifies. Note: an aligned Return-Path is what lets DMARC pass on the SPF side, so do not skip it.

4. DMARC (set the policy and reports)

1. Check whether your domain already has a DMARC record (a TXT record at _dmarc.yourdomain.co.uk). Note: if one exists, edit it rather than adding a second, since two DMARC records cancel each other out.
2. If none exists, add a starter DMARC record in monitoring mode, for example a policy of none with a reporting address you can read. Note: monitoring mode watches and reports without affecting delivery, so it is safe to begin with.
3. Save the DMARC record and confirm it resolves. Note: leave the policy at none until you have watched a week or two of reports, then tighten it towards quarantine or reject once your legitimate mail is passing cleanly.

5. Forwarding (route incoming mail in, no MX change)

1. In the mailbox itself, create a rule that forwards incoming mail to the helpdesk address shown in its setup screen. Note: this is the forwarding-first approach; your mailbox keeps delivering as normal and simply passes a copy on.
2. Choose to keep a copy in the original mailbox while you settle in, rather than delete-on-forward. Note: keeping a copy gives you a safety net until you trust the new flow.
3. Do not change your domain's MX record. Note: an MX change moves all delivery and is hard to undo quickly; this checklist avoids it entirely so there is nothing large to roll back.
4. If your helpdesk offers a way to confirm the forwarding address (for instance a one-time code it emails you), complete that confirmation. Note: this proves the forward is wired to the right place before real customers rely on it.

6. Test (send and receive a real message)

1. From a separate address you control, send a normal test email to the support address. Note: use real wording, not just the word test, so you see how a genuine message arrives.
2. Confirm the test message appears as a ticket in the helpdesk within a minute or two. Note: if it does not arrive, re-check the forwarding rule before touching anything else.
3. Reply to that ticket from the helpdesk and confirm the reply reaches your test inbox. Note: check it lands in the inbox, not spam, and that the from-name and signature look right.
4. Open the received reply and check it is signed (most mail apps will show the sending domain as the one you authenticated). Note: a reply that is signed and aligned is the sign your DKIM, Return-Path and DMARC work together.
5. Send one more test from a different provider if you can (for example a personal account on a major free webmail). Note: testing across providers catches a setup that pleases one mail system but not another.

7. Go live (turn it on for the team)

1. Confirm every DNS record reads as verified in the helpdesk, with no warnings outstanding. Note: do not go live on amber; a half-verified mailbox is the classic cause of early replies in spam.
2. Set the correct from-name and signature for this mailbox or brand. Note: customers should see the name they expect, not a generic system address.
3. Tell the team the address is live, who owns first response, and where to find it. Note: a shared address only stays tidy if everyone knows it is now a queue, not a free-for-all.
4. Keep the forwarding rule and the original mailbox in place for a week or two as a safety net. Note: once you have watched it work and DMARC reports look clean, you can tidy up the old setup.
5. Save your completed checklist with the date. Note: a dated record of what was set helps the next person, and helps you when you connect a second address or brand.

It is tempting to skip the DNS steps and just forward mail, but the DNS work is what makes your replies trusted. DKIM signs each reply so the receiver can confirm it genuinely came from your domain. The Return-Path makes the bounce address line up with that domain, which is what lets the SPF side of DMARC pass. DMARC then tells receiving servers what to do with anything that fails, and sends you reports so you can see how your mail is treated in the wild.

Doing these before you forward and test means your very first live reply is already signed and aligned. Teams that rush to live replies first, then add DNS later, often spend their opening week explaining why answers landed in spam. A little patience at the start saves that.

DKIM	A signature on every outgoing reply that proves it came from your domain and was not altered. Add the record your helpdesk gives you to DNS.
Return-Path	The bounce or envelope-sender address. Aligning it with your domain helps SPF and DMARC pass on your replies.
DMARC	The policy that tells receivers what to do with mail that fails checks, and where to send reports. Start in monitoring mode.
Forwarding	A rule that sends a copy of incoming mail to the helpdesk. Lower risk than an MX change and easy to switch off.
MX record	Controls where all of your domain's mail is delivered. This checklist does not touch it, so there is nothing large to roll back.
TTL	Time-to-live: how long servers may cache a DNS record. It is why a change can take up to a day to apply everywhere.

Most setups are smooth, but a few snags come up often enough to name. Work these before assuming anything deeper is wrong.

• A record will not verify: re-open the value at your DNS host and check for a stray space, a missing dot, or a typed character that should have been pasted. The host name often needs your domain appended automatically, so confirm the full record reads as you expect.
• It verified an hour ago but now warns: a DNS host can apply a change slowly, or a second conflicting record may exist. Look for a duplicate, especially with DMARC, where two records cancel out.
• The test ticket never arrives: the forwarding rule is the first suspect. Confirm it points at the exact helpdesk address and that any one-time confirmation step was completed.
• The reply arrives but lands in spam: usually DKIM or the Return-Path has not finished verifying. Wait for both to read as verified, then send a fresh test rather than reusing the old thread.
• It works from one provider but not another: this is normal mid-setup and almost always resolves once DMARC and DKIM are fully live. Give it time to apply, then re-test across providers.

These two emails save you writing from scratch. Paste either into a reply, fill in the square-bracket fields with your own details, delete any line that does not apply, and read it back before you send. The square brackets are writing prompts to show where your specifics go; they are not a feature you switch on.

A. Ask whoever manages your domain to add the DNS records

Subject: Please add three DNS records for our support email

Hi [name of domain or IT contact],

We are connecting our support address [your support address] to a helpdesk so customer email becomes tracked tickets and our replies are properly signed. To finish the setup, we need three DNS records added to [your domain, for example yourdomain.co.uk]. None of them change where mail is delivered, so there is no risk to our existing email.

Please add the following at our DNS host, exactly as written (copy and paste rather than retype, as a single wrong character breaks them):

1. A DKIM record. Host: [DKIM host name from the helpdesk]. Type: [TXT or CNAME]. Value: [DKIM value from the helpdesk].
2. A Return-Path record. Host: [Return-Path host name]. Type: CNAME. Value: [Return-Path value from the helpdesk].
3. A DMARC record at _dmarc.[your domain]. Type: TXT. Value: [DMARC value, starting in monitoring mode]. If a DMARC record already exists, please edit it rather than add a second one, as two cancel each other out.

Once they are saved, could you let me know so I can confirm each one reads as verified in the helpdesk? Changes can take anywhere from a few minutes to a day to apply. Thank you for sorting this out.

[your name]

B. Tell the team the support address is now live

Subject: [your support address] is now a shared ticket queue

Hi all,

From today, [your support address] is connected to our helpdesk. Email sent to it now arrives as a ticket rather than landing in a shared inbox, so please work it there rather than replying from the old mailbox.

A few things to know:

1. Each incoming email becomes a ticket with an owner and a status, so we answer it once between us, not three times or not at all.
2. First response on new tickets is owned by [name or rota]. If you pick up a ticket, assign it to yourself so nobody else doubles up.
3. Replies go out as [brand or from-name], so customers see the name they expect. Please keep to that signature.
4. You can find the queue at [where to sign in or link]. Ask [name] if you need access.

The old mailbox stays in place as a safety net for a week or two while we settle in, then we will tidy it up. Shout if anything looks off.

Thanks,

[your name]

You can follow this checklist with any email helpdesk. With Solves, the same steps are guided on screen: the mailbox setup shows the exact DKIM, Return-Path and DMARC values to paste, re-checks each record for you, and keeps live sending blocked until a mailbox is verified, so a half-set mailbox cannot quietly send into spam. Incoming mail is forwarded, not MX-switched, which keeps the change reversible.

Once connected, the forwarded email becomes owned tickets with states, owners, priorities, tags, saved replies, public replies and private notes, saved views and wall-clock first-response and resolution timers, with a breaching view that sorts the worst first. Customer content is encrypted at rest, access is authorised only, and logs hold metadata rather than message bodies or addresses. It is email-first by design: no live chat, phone or social channels, just the support inbox done properly.