Mailu and SMTP relay: setup and DNS guide

Run mailboxes and application mail on your own domain, keep the two traffic types apart and publish the DNS records that decide whether messages arrive.

Mail hosting

Two kinds of mail, two tools

A company sends two very different kinds of e-mail: conversations written by people and messages generated by software. They differ in volume, in the way they fail and in their effect on your sending reputation, so we treat them separately.

  • Mailu runs the mailboxes, aliases and webmail your team uses every day.
  • An SMTP relay carries what applications send: invoices, order confirmations, password resets and system alerts.
  • If a script sends thousands of messages from the same address space as your staff mailboxes, a spam complaint on one stream can damage delivery of the other.
  • Publish the DNS records before the first message goes out, not after the first bounce.
SMTP relay

Mailu for people

Mailu is an open-source mail server that runs in containers. Choose it when you want your mailboxes on infrastructure you control, under your own domain.

  • Mailboxes, aliases and forwarding for every domain you own, managed from one admin interface.
  • Webmail plus IMAP and SMTP submission, so staff can use Outlook, Thunderbird or a phone.
  • Spam filtering and per-mailbox quotas, with the password policy set centrally.
  • A practical destination when you leave cPanel or Google Workspace: mailboxes are copied over IMAP, one at a time, while the old system keeps receiving until DNS changes.
DNS

DNS checklist

Mail providers judge a message largely by what your DNS says about the sender. Check each record before go-live.

  • MX: points the domain to the Mailu host, with a priority value and a hostname that resolves.
  • SPF: lists exactly the servers allowed to send, usually the Mailu host and the relay, and ends in -all once you have verified the list. Stay under ten DNS lookups.
  • DKIM: use a 2048-bit key and publish the public key under the selector name; separate selectors for Mailu and the relay keep the two streams independent.
  • DMARC: start with p=none and an rua address, read the aggregate reports for a couple of weeks, then move to quarantine and finally reject.
  • Reverse DNS: each sending IP resolves to a hostname that resolves back to the same IP.
Example zone for corp.example
corp.example.                  MX   10 mail.corp.example.
mail.corp.example.             A    198.51.100.10
relay.corp.example.            A    198.51.100.20
corp.example.                  TXT  "v=spf1 ip4:198.51.100.10 ip4:198.51.100.20 -all"
mail._domainkey.corp.example.  TXT  "v=DKIM1; k=rsa; p=..."
relay._domainkey.corp.example. TXT  "v=DKIM1; k=rsa; p=..."
_dmarc.corp.example.           TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

When to use what

A simple rule: Mailu for people, relay for software.

  • Mailu alone suits a small team with nothing automated.
  • A relay alone suits a company whose staff mail lives elsewhere but whose applications need dependable delivery.
  • Both together replace external e-mail providers end to end.
  • The initial setup of DNS, DKIM and the relay is a good use of your included DevOps hours.

Two kinds of mail, two tools

A company sends two very different kinds of e-mail: conversations written by people and messages generated by software. They differ in volume, in the way they fail and in their effect on your sending reputation, so we treat them separately.

  • Mailu runs the mailboxes, aliases and webmail your team uses every day.
  • An SMTP relay carries what applications send: invoices, order confirmations, password resets and system alerts.
  • If a script sends thousands of messages from the same address space as your staff mailboxes, a spam complaint on one stream can damage delivery of the other.
  • Publish the DNS records before the first message goes out, not after the first bounce.

SMTP relay for software

A relay is the single exit point for mail your applications generate, kept apart from staff mailboxes.

  • Submission on port 587 with STARTTLS, or port 465 with implicit TLS; require TLS in production.
  • One credential per application (ERP, shop, monitoring), so a leaked password can be revoked without touching the others.
  • A dedicated sending IP or a tightly controlled pool, with reverse DNS that matches the hostname, keeps the reputation your own.
  • Typical traffic: electronic invoices, order and shipping notices, password resets and monitoring alerts.

Moving from cPanel or Google Workspace

Migration is the moment most mail problems are created, so run it as a sequence.

  • Lower the TTL on the MX and A records a day or two before the move.
  • Create the mailboxes and aliases in Mailu first, then copy existing mail over IMAP while the old system still receives.
  • Switch the MX records, keep the old system running for a few days and run a final sync.
  • Remove the old provider from SPF only after the last message has arrived. Mailu and relay migration is one of our DevOps services, so your included hours can cover it.

When mail does not arrive

Work from the outside in.

  • Read the bounce message first; the status code and the text usually name the cause.
  • Check the SPF, DKIM and DMARC results in the headers of a message that landed in spam.
  • Confirm that the sending IP has reverse DNS and is not on a public block list.
  • Send low volumes from a new IP for the first days instead of everything at once.

Before you go live

Five checks that prevent most first-week incidents.

  • TLS is required on the submission ports and the certificate matches the mail hostname.
  • SPF, DKIM and DMARC are published and verified with a test message.
  • Each application has its own relay credential.
  • A test restore of the mailbox backups has been done at least once.
  • Someone receives the DMARC reports and actually reads them.

Run mailboxes and application mail on your own domain, keep the two traffic types apart and publish the DNS records that decide whether messages arrive.