Email infrastructure

Email that you own, configured the way it should have been.

Running your own mail is a reasonable choice when you need control over data, aliases and volume — and a bad choice if nobody is going to maintain it. We build either path honestly: a properly configured self-hosted stack with backups and monitoring, or a hosted provider set up correctly with the DNS and migration handled.

You might need this if

  • You are paying per mailbox for accounts that only receive forwarded mail.
  • Your application sends mail directly from the web server and it mostly does not arrive.
  • A previous Mailcow or Postfix install exists, but nobody knows how it was configured or whether it is backed up.
  • You need mailboxes on a domain you control, with data in a jurisdiction you choose.
  • Migration from an old provider has stalled because nobody wants to risk losing mail.
  • Transactional and marketing mail share a single domain and a single reputation.

What the work covers

Not every engagement includes all of this. The scope is agreed in writing before anything starts.

  • Self-hosted mail server deployment

    Mailcow on a dedicated VPS: Postfix, Dovecot, Rspamd, SOGo and ClamAV behind a reverse proxy, with valid certificates, automatic renewal, DKIM keys generated per domain, and the full DNS set published and verified.

  • Hosted mailbox setup

    Where self-hosting is the wrong answer, we configure Google Workspace or Microsoft 365 properly instead — authentication, routing, aliases, groups and shared mailboxes — and say so rather than selling you a server.

  • Transactional sending path

    A separate subdomain and sending identity for application mail, relayed through a provider or your own MTA, so a marketing reputation problem never takes down password resets.

  • Migration

    IMAP-level mailbox migration with a dual-delivery window, so mail keeps arriving at the old system until the cutover is verified and nothing is lost in between.

  • Backups and restore

    Scheduled off-server backups of mail data and configuration, with a documented restore procedure that we test once in front of you rather than assume works.

  • Monitoring and maintenance

    Queue depth, disk, certificate expiry and blocklist status monitored, with an agreed patching cadence. Offered as an ongoing engagement — we do not claim round-the-clock staffed support.

How we approach it

  1. 01

    Decide hosted or self-hosted

    We work through volume, mailbox count, compliance needs and who will own maintenance. Self-hosting is only recommended when the ongoing cost of care is understood and accepted.

  2. 02

    Build on a staging domain

    The stack is built and authenticated on a test subdomain first, so the configuration is proven before any production MX record changes.

  3. 03

    Publish DNS with short TTLs

    MX, SPF, DKIM, DMARC, MTA-STS and the PTR record are set up and verified while TTLs are low enough to roll back within minutes.

  4. 04

    Cut over with dual delivery

    Mail is delivered to both systems during the switch. The old system stays reachable until every mailbox is confirmed complete.

  5. 05

    Document and hand over

    You receive the runbook: where everything lives, how to add a mailbox, how backups run, how to restore, and what to do when the certificate or disk alert fires.

What you end up with

  • A working mail system with every mailbox migrated and verified
  • Complete DNS record set, published and validated from an external resolver
  • Backup schedule with a restore procedure demonstrated at least once
  • Monitoring for queue depth, disk usage, certificate expiry and blocklist listings
  • A written runbook covering routine administration and recovery
  • Credentials handed over through a channel you control, never by plain email

Technologies involved

Tools and standards this work is carried out with — listed because they are what the job uses, not as a claim of vendor partnership.

  • Mailcow
  • Postfix
  • Dovecot
  • Rspamd
  • OpenDKIM
  • Docker
  • Nginx
  • Google Workspace
  • Microsoft 365
  • Let’s Encrypt

What this will not do

A self-hosted mail server is a long-term commitment, not a one-off project. If nobody will patch it, watch the queue and respond to a blocklist listing, a hosted provider is the better engineering decision — and we will tell you so.

On client examples: we do not publish case studies, logos or testimonials without written permission from the client, and we have none cleared for publication yet. If you need evidence of relevant work before engaging, ask — we will share what we can, appropriately redacted, and say plainly where something was a lab build rather than a client engagement.

Questions about this service

Is self-hosted email actually cheaper than Google Workspace?

On licence cost, usually. On total cost, only if your time is free. A VPS able to run Mailcow comfortably is a modest monthly figure for unlimited mailboxes, but someone has to patch it, watch the queue, renew certificates and respond when a blocklist listing appears. Below roughly ten to fifteen mailboxes, hosted is normally the better decision and we will say so.

Will we lose mail during a migration?

That is what the dual-delivery window is for. Mail is delivered to both the old and new systems during the cutover, so the old mailbox keeps receiving until every message is confirmed copied across. We do not decommission anything until you have verified the new system yourself.

Can a self-hosted server get the same deliverability as Google?

It can get close, with correct authentication, a clean IP, a valid PTR record and sensible sending volume — but it starts from no reputation at all, so the first weeks need a gradual ramp. If you send high-volume marketing mail, a dedicated sending provider is usually the better choice for that specific stream even when your mailboxes are self-hosted.

What happens if the server goes down and we are not on a support arrangement?

Sending mail queues at the far end and is retried for several days by most senders, so a short outage is rarely a loss of mail. That said, a self-hosted server with nobody watching it is a real risk, which is why we only recommend self-hosting where either you have someone internally or an ongoing arrangement is in place.

Planning a mail migration or a new mail server?

Tell us your mailbox count, current provider and what is driving the change. We will tell you whether self-hosting actually makes sense for you before quoting anything.

Related services