Support mailbox setup, done in the right order.
Setting up a shared support address well is five steps in one safe order: prove you own the domain, allow sending with DKIM and a custom Return-Path, forward incoming mail into your queue, send a test reply, then go live. Do it forwarding-first and never change your root MX blindly, and you can move onto owned tickets without a single dropped message.
Forwarding-first · No root MX change · Live sending gated on green checks
The short answer
The support mailbox setup checklist
To set up a support mailbox safely, work through five steps in this order: prove the domain, allow sending, forward incoming mail, send a test, then go live. Each step has a clear check, and the next one is easier once the last has passed. The golden rule is forwarding-first: layer the queue on top of your inbox rather than re-pointing your mail server, and never change your root MX records blindly.
- Prove the domain. Confirm you control the domain your support address lives on, so only you can send as it.
- Allow sending. Add a DKIM record so messages are signed, and a custom Return-Path so bounces and SPF alignment are handled on your own domain.
- Forward incoming mail. Point a forwarding rule at your Solves address so a copy of every support email lands in the queue.
- Send a test. Reply to a real or test message and confirm it arrives, looks right, and passes authentication.
- Go live. Once the checks are green, switch the mailbox on and start owning tickets.
The rest of this guide explains each step, why the order matters, and the two records people most often get wrong. If you would rather be walked through it on screen, the guided setup in Solves does the same five steps with the exact records to copy and a live check after each one.
Do not change your root MX blindly
Your MX records decide where all mail for your domain is delivered. Changing them re-points your entire inbox, not just support, and a mistake can bounce everything. Forwarding-first means you do not touch MX at all: you add sending records and one forwarding rule, and your normal mail keeps flowing exactly as it does today.
Step by step
The five steps, and the check at the end of each
Prove the domain
Confirm you control the domain behind your support address, so nobody else can send as your brand. This is the foundation: everything after it relies on the domain being yours and verified. In Solves this is the first thing the guided setup asks you to do.
Allow sending: DKIM and Return-Path
Add a DKIM record so outbound replies are cryptographically signed, and a custom Return-Path (a CNAME on your domain) so bounces come back to you and SPF aligns cleanly. These two records are what let your replies land in inboxes rather than spam folders.
Forward incoming mail
Create a forwarding rule from your support address to the address Solves gives you. Incoming customer mail keeps arriving where it always has, and a copy flows into the queue as owned tickets. No MX change, no cutover.
Send a test
Reply to a test or real message from inside Solves and confirm it arrives, shows the right brand name and signature, and passes authentication. A test now catches a typo in a DNS record before any customer sees it.
Go live
When every check is green, switch the mailbox on. Solves keeps live sending blocked until verification passes, or until a founder records an explicit, logged override in a supervised pilot, so you cannot go live half-configured by accident.
The two records people get wrong
DKIM and Return-Path, in plain English
Most support mailbox problems trace back to one of two sending records. Get these right and the rest tends to follow. Here is what each one does and why it matters.
DKIM: signing your replies
DKIM (DomainKeys Identified Mail) adds a digital signature to every reply, so receiving servers can confirm the message really came from your domain and was not tampered with in transit. Without it, your carefully written replies are far more likely to be filtered or flagged. You add one DNS record, supplied by your sending provider, and signing happens automatically from then on.
Return-Path: where bounces go
The Return-Path is the behind-the-scenes address that handles bounce notifications and is checked for SPF alignment. Using a custom Return-Path on your own domain, rather than the provider default, keeps bounce handling tidy and helps your mail align cleanly. In practice this is one CNAME record to copy and paste.
Why SPF, DKIM and DMARC are worth understanding
SPF, DKIM and DMARC are the three records that prove a message is genuinely from you. SPF lists who may send for your domain, DKIM signs the message, and DMARC tells receivers what to do when a message fails those checks. You do not need to become an expert to set up a support mailbox, but a working knowledge helps you read the verification results with confidence. The companion guide on setting up SPF, DKIM and DMARC for support email goes deeper if you want it.
How Solves helps
What the guided setup does for you
The same five-step checklist, on screen, with a live check after each step.
Copyable DNS
Each record is shown ready to copy, with the host and value spelled out, so you paste rather than translate jargon from a provider help page.
Forwarding-first
Setup is built around forwarding, so your existing inbox keeps working and there is no risky re-point of your mail server.
Gated go-live
Live sending stays blocked until the checks pass, or until a founder records an explicit, logged override in a supervised pilot.
Send a real test
Fire a test reply and confirm it lands and looks right before any customer is involved, so a typo never reaches a real inbox.
Per-brand mailboxes
Run the same checklist for each brand you support, so every brand sends from its own verified address with its own identity.
Saved progress
Stop after adding records and come back once DNS has propagated. Nothing is lost, and you do not start the setup over.
In practice
A worked example, start to finish
Say your support address is [email protected] and your mail lives with a typical provider. You start in Solves, which asks you to prove the domain. You add the verification record it shows you, wait for it to propagate, and the check goes green.
Next, Solves shows the sending records: a DKIM record and a custom Return-Path CNAME. You copy both into your DNS provider exactly as shown. While they propagate you move on, because the order is forgiving: you can keep going and let the checks catch up.
Then you add one forwarding rule in your mail provider, sending a copy of mail for [email protected] to the Solves address. The first forwarded message appears in your queue as an owned ticket. At this point your team can already triage and add private notes, even before sending is fully green.
Finally you send a test reply. It arrives signed, with the right brand name and signature, and passes authentication. The mailbox checks are all green, so you switch it on and go live. Nothing about your day-to-day mail flow changed: you simply added an owned, timed support queue on top of it.
Common snags and how to avoid them
- Pasting a DNS record with a trailing space or the wrong host name. Copy the value exactly and check it against what the setup shows.
- Expecting records to verify instantly. DNS propagation can take a few hours; come back rather than assuming the record is wrong.
- Reaching for an MX change to "make it work faster". You do not need it, and it risks your whole inbox. Stay forwarding-first.
- Skipping the test send. A thirty-second test catches a misconfigured record before a customer ever sees a problem.
FAQ
Support mailbox setup questions
What is the safest order for support mailbox setup?
Prove the domain first, then allow sending with DKIM and a custom Return-Path, then forward incoming mail to your support address, then send a test reply, and only then go live. Doing the steps in that order means nothing is announced to the world until the checks behind it have passed. Solves walks you through them in exactly this sequence and keeps live sending blocked until each one is verified.
Do I have to change my MX records?
No, and we would not advise changing your root MX blindly. The forwarding-first approach leaves your existing mail flow untouched: incoming messages still arrive where they do today, and a forwarding rule sends a copy of support mail into Solves. You add a DKIM record and a Return-Path (CNAME) record for sending, which do not affect where your normal mail is delivered. Changing MX is a bigger, riskier step that you do not need for this.
How long does support mailbox setup take?
The hands-on part is usually minutes: copy two or three DNS records, add one forwarding rule, send a test. The wait is DNS propagation, which can be near-instant or take a few hours depending on your provider and time-to-live settings. You can start adding records, then come back and finish the verification once they have propagated. Solves saves your progress so you do not have to redo anything.
What is a Return-Path and why does it matter?
The Return-Path is the hidden address that receives bounce notifications and is checked for SPF alignment. Using a custom Return-Path on your own domain, rather than the provider default, helps replies align cleanly and keeps bounce handling tidy. Solves gives you the exact CNAME record to add so this is one copy-and-paste step, not a research project.
Can I go live before the DNS checks pass?
Live sending stays blocked until the mailbox is verified. In a supervised pilot a founder can record an explicit override to unblock sending early, and that action is logged, but the default and the safe path is to wait for green checks. Forwarding incoming mail and reading tickets works straight away, so your team can start triaging while sending is still being verified.
Will moving to Solves disrupt the mail my customers already send?
No. Because setup is forwarding-first, your customers keep emailing the same address and their messages keep arriving as they always have. A copy flows into Solves so your team can own and reply to it. You are layering a support queue on top of your inbox, not cutting over your mail server, so there is no risky big-bang switch.
Set up your support mailbox the safe way
Follow the same five-step checklist on screen, with copyable DNS and a live check at every step.