Your support mailbox setup checklist, in plain English.
Connecting your support address to a helpdesk should not mean rewriting your DNS and hoping for the best. Solves walks you through it: forward your incoming mail, prove your domain with copyable records, send a test, then go live. Real replies stay blocked until the checks pass, so nothing you send lands in spam.
See it in Solves
Plain-English DNS, with sending gated until verified
Solves shows you the exact DKIM, Return-Path and DMARC records to paste at your provider, each explained in a line. Live sending stays blocked until the checks pass, then unlocks on its own.
- Copyable DKIM, Return-Path and DMARC records, with a one-line explanation of each
- Solves rechecks your DNS for you, so you are never left guessing whether it worked
- No real reply leaves Solves until the domain is verified
The short answer
What support mailbox setup actually involves
Setting up a support mailbox is two jobs, not one. First, get incoming email into your helpdesk, which is the easy part. Second, prove to the rest of the internet that replies sent from your address are genuinely yours, which is where SPF, DKIM, DMARC and a verified Return-Path come in. Solves guides both, and deliberately keeps live sending switched off until the second job is done.
The receiving side is simple. You keep your support address (support@, info@, accounts@ and the like) wherever it lives today, and forward it into Solves, or point an alias at the inbound address Solves gives you. From that moment, new email becomes owned, assignable tickets. You have not changed any root mailbox, so your existing business email, calendars and aliases keep working exactly as before.
The sending side is the part worth doing carefully. When Solves sends a reply on your behalf, receiving servers ask three questions: is this server allowed to send for the domain, has the message been signed and left untouched, and does the domain owner vouch for it. Those questions map to SPF, DKIM and DMARC. Get them right and your replies arrive in the inbox; get them wrong and they sit in spam or bounce. Solves gives you the exact records and confirms them for you.
Forwarding-first, so you never change root MX blindly
A common mistake is to repoint a domain's MX records (the records that decide where all email for that domain is delivered) just to try a new helpdesk. Do that blindly and you can divert every message, including invoices and password resets, away from where staff expect them. Solves avoids this entirely. Forwarding leaves your delivery untouched and routes only your support address, so you can pilot the desk with zero risk to the rest of your email. Changing MX is a separate, much bigger decision you do not need to make to get going.
SPF, DKIM, DMARC and Return-Path, without the jargon
SPF is a public list of the servers allowed to send for your domain. DKIM is a cryptographic signature added to each message so a receiver can confirm it was not altered or forged. DMARC ties the two together and states your policy: what an inbox should do if a message fails. The Return-Path is the hidden address that catches bounces and feeds the SPF and DMARC checks; verifying it on your own domain means your replies align fully under DMARC rather than looking like mail sent on someone else's behalf. You do not need to memorise any of this. Solves shows the precise records to add and explains each one in a sentence.
Until those records check out, Solves will not send a live reply to a customer. That is by design: it is far better to hold a reply for a few minutes than to send one from an unverified domain and have it filed as spam. A recorded founder override exists for pilots and demos, but it is logged rather than silent, so the rule is never quietly broken.
The checklist
Five steps from inbox to live support desk
Work through these in order. Solves rechecks each one for you, so you are never guessing whether it worked.
Prove the domain
Add your support domain in Solves. It generates the records you need, including DKIM and a verified Return-Path, ready to copy. You add them once at your DNS provider.
Allow Solves to send
Paste in the copyable SPF, DKIM and Return-Path records. Solves rechecks them and tells you exactly which are passing, so there is no ambiguity about whether sending is authorised.
Forward incoming mail
Forward your support address into Solves, or point an alias at the inbound address it gives you. Your existing business email stays where it is; only support mail is routed.
Send a test
Send a test reply to confirm the whole path works end to end: forwarding in, ticket created, reply out from the right address with the records aligned. You see it land, not just a green tick.
Go live
Once the checks pass, live sending unlocks automatically and your team can reply to real customers. Add more brands or mailboxes later, each with the same guided checks before it can send.
What the setup gives you
Guided, checked and safe to undo
Forwarding-first
Keep receiving email where you do today and forward only your support address, so your existing business email is never disrupted by the trial.
Copyable DNS records
Exact SPF, DKIM and Return-Path values to paste into your DNS provider, each with a one-line explanation of what it does and why.
Built on Postmark
Outbound sending runs through Postmark, a sending provider focused on transactional and reply email, so your support replies are treated as the genuine mail they are.
Automatic rechecks
Solves rechecks your records rather than making you guess. Live sending stays blocked until they pass, then unlocks on its own, no support ticket required.
Per-brand mailboxes
Each brand gets its own mailbox and sender identity, and each runs the same checks, so deliverability stays correct as you add more brands.
Recorded overrides
For pilots and demos a founder override can unlock sending early, but it is recorded in the audit history, never a silent exception to the rule.
Never change root-domain MX records blindly
MX records control where all email for a domain is delivered, including invoices, password resets and staff mail. Repointing them just to try a helpdesk can divert messages you cannot afford to lose. Forwarding your support address into Solves is the safer route: it leaves your delivery untouched and routes only the mail you mean to move.
Switching in
Setting up when you are moving from another helpdesk
If you are coming from another tool, the mailbox checklist is the same, with one addition: bring your history and saved wording across before you flip the switch. Solves can import from Freshdesk, including contacts, saved replies, open tickets and their conversations into a brand you choose, with a preview before anything is committed and credentials kept encrypted. You set up the mailbox, import what you need, send a test, and only then forward live traffic, so customers never notice the move.
Doing it in this order means there is no gap. Incoming mail keeps flowing to your old tool until your Solves mailbox is verified and tested. When you are ready, you change the forwarding and the queue moves over cleanly, with your existing tickets and replies already in place.
FAQ
Mailbox setup questions
What is SPF, DKIM and DMARC in plain English?
They are three small DNS records that tell receiving mail servers your replies are genuine. SPF lists which servers are allowed to send for your domain. DKIM adds a cryptographic signature so a message cannot be altered or forged in transit. DMARC ties the two together and tells inboxes what to do if a message fails the checks. Set up correctly, they keep your support replies out of spam and stop other people sending email that looks like it came from you.
Do I need to change my MX records to use Solves?
No, and you should not change root-domain MX records blindly. Solves is forwarding-first: you keep receiving email where you do today and simply forward your support address into Solves, or point an alias at it. Your existing business email, calendars and mailboxes keep working untouched. You only add a few sending records (SPF, DKIM and a verified Return-Path) so replies go out correctly. MX changes are a separate, much larger decision that you do not need to make to get started.
How long do DNS changes take to work?
Usually minutes, sometimes longer. DNS records have a time-to-live (TTL) that controls how long servers cache the old value, so a change can take anywhere from a few minutes to a day to apply everywhere. Most providers update within an hour. Solves rechecks the records for you, so you do not have to guess: live sending stays blocked until the checks pass, then unlocks automatically once they do.
What is a Return-Path and why does it need verifying?
The Return-Path is the hidden address that receives bounce notices and feeds the SPF and DMARC checks. Verifying it on your own domain (rather than borrowing the sending provider's) means your replies align under DMARC and look fully legitimate, not forwarded on someone else's behalf. Solves gives you the exact record to add and confirms it for you before allowing live sends.
What happens if I have not finished the DNS checks yet?
You can still receive and work tickets straight away through forwarding, so nothing is blocked while you wait. What stays blocked is live outbound sending: Solves will not send a real reply to a customer until the domain is proven, so you cannot accidentally send from an unverified domain and land in spam. The only exception is a recorded founder override, used for pilots and demos, which is logged rather than silent.
Can I set up more than one support mailbox?
Yes. Each brand can have its own mailbox and sender identity, and every mailbox runs the same checks before it can send live. That keeps deliverability correct per brand, so a reply for one brand always goes out from the right address. You can add mailboxes one at a time and go live with each as its own checks pass.
Connect your support mailbox the safe way
Start at £29, forward your support address, and go live once the checks pass. We are happy to walk you through the DNS if you would rather have a hand.