The order here is deliberate. Publish MX before you have verified the gateway and a misconfiguration becomes a mail outage; verify first and the worst case is a test message you can inspect at leisure.
1. Issue the certificate
Run the TLS step of the setup wizard, or go to System → TLS / HTTPS later. The appliance runs certbot with an HTTP-01 challenge served from /var/www/acme, then rewrites the nginx site for HTTPS and reloads it.
Prerequisites, both checked before the attempt:
- The hostname resolves publicly to this host.
- Ports 80 and 443 are reachable from the internet.
On success the console and portal move to HTTPS on one certificate: portal at https://host/, console at https://host/admin. TLS 1.2 and 1.3 only, with HSTS at one year. Renewal is handled by certbot’s own timer plus a deploy hook that reloads nginx — which is why port 80 must stay open.
If it fails, the page shows certbot’s actual output. It is almost always DNS not yet resolving or port 80 unreachable. You can skip and retry later; the appliance keeps working over HTTP in the meantime.
The same certificate is reused for SMTP STARTTLS by default. If you serve mail under a different name, set the mail TLS hostname on the TLS page and it is added to the certificate as an additional name.
2. Generate DKIM keys
Go to Mail flow → DKIM and add a key per domain. The appliance generates a 2048-bit key itself, stores it under /etc/opendkim/keys/, and rebuilds the OpenDKIM tables. It then shows you the DNS record to publish:
securemail._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."The default selector is securemail, and multiple selectors per domain are supported for rotation. Signing happens on the internal reinjection hop, after filtering, so every message the gateway sends is signed with its final content.
Re-apply DKIM after every upgrade. The installer truncates the OpenDKIM signing tables on each run. The keys themselves survive, but signing silently stops until you press Apply again — and unsigned outbound mail is exactly what DMARC will punish.
3. Publish SPF and DMARC
Add the gateway to SPF for every domain it sends for. If you already publish SPF, add the host rather than replacing the record:
example.com. IN TXT "v=spf1 a:secure.example.com include:_spf.example.com ~all"
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"Start DMARC at p=none and read the aggregate reports before tightening to quarantine or reject. The appliance can both evaluate inbound DMARC and send your own aggregate reports; set the reporting address under Mail flow → DMARC.
When DMARC enforcement is enabled and a sender’s policy says reject or quarantine, the gateway quarantines rather than silently dropping — a false positive stays recoverable.
4. Verify before cutover
sudo /opt/securemail/venv/bin/python /opt/securemail/scripts/preflight.pyResolve everything marked as a failure. In particular:
| Check | Why it matters |
|---|---|
| Reverse DNS matches the mail hostname | A mismatch gets legitimate mail rejected by major providers. |
| Outbound port 25 | Blocked by most cloud providers by default. Without it, nothing is delivered. |
| Downstream host reachable | Inbound mail has nowhere to go after filtering. |
| IP not on a public blocklist | A recycled cloud address may arrive already listed. |
Then send a real message through it. Point a test sender at the gateway directly, or lower the TTL on one low-traffic domain’s MX and move that first. Confirm it appears in the mail log with the disposition you expect, and that it arrives on your mail server.
5. Move MX
Only now. Lower the TTL a day ahead so a rollback is fast, then point MX at the gateway:
example.com. IN MX 10 secure.example.com.Leave the old MX in place at a higher preference during the transition if you want a fallback, and remove it once the gateway has been handling all mail cleanly for a few days. Set the gateway as the smart host for outbound relay on your mail server at the same time, so both directions are filtered.
Optional: MTA-STS and TLS reporting
The portal serves an MTA-STS policy at /.well-known/mta-sts.txt once enabled. Start in testing mode, which asks sending servers to report failures without acting on them, and move to enforce only after the reports are clean. The policy returns 404 until you list your real MX hostnames, which prevents publishing a policy that would break your own inbound mail.
_mta-sts.example.com. IN TXT "v=STSv1; id=20260101000000Z"
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"You can also require TLS for delivery to named domains, which refuses to deliver in the clear if the far end will not negotiate it.