Corporate Email
Corporate Email
Email on your own domain, with spam filtering, mobile setup and migration of the mailboxes you already have.
An address that says your company, not your provider
A free mailbox on a public domain quietly costs you credibility on every quote you send. It also costs you control: the address belongs to the platform, not to your business, and it leaves with whoever set it up.
We set up email on your own domain, configure the authentication records that decide whether your mail is trusted, and move your existing mailboxes across — folders, contacts and history included.
What we set up
- Mailboxes on your domain, with aliases and shared addresses where the team needs them.
- SPF, DKIM and DMARC records, configured and verified rather than pasted in and hoped over.
- Spam and virus filtering in front of the mailbox, so the junk is stopped before it reaches anyone's phone.
- Device setup on phones, laptops and the mail clients you already use — done with you, not by sending you a PDF.
- Shared calendars and contacts where the way you work needs them.
- Migration of existing mail, including the folder structure people have built up over years.
Why authentication is no longer optional
Since February 2024, Google and Yahoo have required senders of bulk email — the commonly cited threshold is 5,000 messages a day to their users — to authenticate with SPF, DKIM and a published DMARC policy. Microsoft introduced equivalent requirements for Outlook.com in 2025. Non-compliant mail is filtered or rejected outright.
The bulk thresholds are what made the news, but the practical effect reaches further down: receiving systems now treat unauthenticated mail with more suspicion regardless of volume. A small company that sends fifty quotes a month is not a bulk sender, and still benefits from the same three records being correct.
Two other requirements travel with them. Senders must offer one-click unsubscribe on commercial mail and honour it within two days, and Google asks that spam complaints stay below 0.1%, with 0.3% treated as a hard problem. Both are worth knowing before you start sending campaigns from a new domain.
These are the receiving platforms' rules, not ours. Our part is making sure your records satisfy them and that the ones you already have — often left behind by a previous provider — do not contradict each other.
Own domain, shared inbox or a public address
| Free public mailbox | Email on your domain | |
|---|---|---|
| Address | name@publicprovider.com | name@yourcompany.com |
| Who controls it | The platform | You, through your domain |
| If an employee leaves | The address goes with them | You reassign or forward it |
| Authentication records | Not yours to set | Configured for your domain |
| Moving provider | Start over | Point the MX records elsewhere |
The last row is the one people underestimate. When email runs on your own domain, changing providers is a DNS change. When it runs on someone else's domain, it is a change of address announced to every customer you have.
When we are not the right fit
- You need a full collaboration suite — documents, meetings, chat, device management — under one licence. That is a different product, and we will help you connect the mail side of it rather than pretend otherwise.
- You are running a marketing platform and want deliverability consulting at campaign scale. We set the foundation correctly; sustained campaign reputation work is a specialty of its own.
- Your mail is already on your domain, authenticated and migrated. There is nothing here worth paying for.
How the migration runs
Moving a mailbox is not copying a folder. People are still receiving mail while it happens, and a message that arrives during the switch has to land somewhere it will be found. The sequence below is built around that.
- Inventory. How many mailboxes, how large, which ones are shared, what aliases exist, and which devices are connected to each.
- Create in parallel. New mailboxes are set up on the new platform while the old ones keep receiving. Nothing is switched off yet.
- First sync. Existing mail, folders and contacts are copied across. On a large mailbox this takes hours, and it happens in the background while people keep working.
- Lower the DNS TTL on the MX records, a day or two ahead, so the cutover propagates in minutes.
- Cut over, then run a final delta sync to pick up everything that arrived during the switch.
- Reconnect devices — phones, laptops, the mail clients people actually use — with someone available while they do it.
- Keep the old mailboxes readable for a while, so anything missed can still be retrieved.
The old platform is not cancelled on the day of the switch. That is not caution for its own sake: a mailbox nobody checked for two weeks is exactly where somebody notices a missing folder.
Records we check before and after
Email problems usually come down to DNS records that contradict each other, often because two providers have both been configured at some point and neither was fully removed.
- MX — which server receives mail for the domain. More than one active set is a classic cause of mail arriving in the wrong place.
- SPF — which servers may send on your behalf. A single domain may only publish one SPF record; two is a configuration error, not a belt-and-braces approach.
- DKIM — the signing key. Left-behind keys from an old provider do not break anything on their own, but they make an audit confusing.
- DMARC — the policy telling receivers what to do with mail that fails, plus the reporting address that tells you it is happening.
We check these before the move, set them correctly during it, and verify them afterwards from outside your network — because a record that resolves on your machine is not evidence that the rest of the world sees it.
Frequently asked questions
Will I lose old emails when we switch?
No. Existing mail, contacts and the folder structure are copied across before the switch, so nothing has to be forwarded by hand and no conversation loses its history mid-thread. The old mailbox stays available until you confirm everything arrived.
What are SPF, DKIM and DMARC, in plain terms?
SPF lists which servers are allowed to send mail for your domain. DKIM signs each message so the receiver can verify it was not altered. DMARC tells receivers what to do when a message fails those checks, and asks them to report back. Together they are how a receiving system decides your mail is genuinely from you.
Why does my mail keep landing in spam?
Missing or contradictory authentication records are the most common cause — often an SPF record left behind by a previous provider that no longer lists the server actually sending. Content and sending reputation matter too, but the records are where to look first because they are verifiable.
Can we keep using Outlook or the mail app on our phones?
Yes. Email on your own domain works with standard mail clients over IMAP and SMTP. We set the accounts up on the devices your team already uses rather than asking anyone to change how they work.
How many mailboxes do we need?
One per person who needs their own identity, plus shared addresses like info@ or accounts@ that several people read. Shared addresses are usually aliases rather than separate mailboxes, which keeps the count — and the cost — down.
Does this work if our website is hosted somewhere else?
Yes. Mail and web hosting are separate records on the same domain. We set the mail records without touching where the site is served from, and if the site moves later the mail records travel intact.