Email you operate, with realistic delivery expectations.

Check the prerequisites first

Verify that outbound SMTP, reverse DNS and the required ports are actually supported. KoalaVPS does not yet guarantee port 25 policy or IP reputation. Choose the hostname and verify its forward and reverse records.

Publish the authentication records

Configure SPF for authorised senders, DKIM for message signing and DMARC for policy and reports. Review TLS transport protections supported by your stack. Avoid copying a policy you do not understand, since a wrong record can block legitimate mail.

Run a complete mail stack

A suite such as Mailcow can bring several services together, but it still needs updates, storage monitoring, spam controls and protected administration. Keep an alternate contact channel for outages.

Expect deliverability work

A technically valid server can still face filtering by recipients. Send wanted mail, handle bounces and complaints and monitor reputation. Keep consistent mailbox backups and test restoring messages and configuration.

Start with the PTR and an external test

Ask about reverse DNS before deploying the stack. The PTR, hostname and forward lookup should form a coherent configuration. Test incoming and outgoing delivery with more than one external provider, inspect authentication results and monitor bounces. A mail test score is diagnostic information, not a guarantee of future inbox placement.

Keep a second route for recovery

Store registrar, DNS and server recovery information outside the mail system itself. If account resets all arrive at the failed server, a minor outage can prevent its repair. Back up mailboxes and configuration consistently and document how users regain access after a rebuild.

Make SMTP eligibility a deployment gate

Before installing a mail suite, confirm inbound and outbound SMTP policy, control of reverse DNS, a stable hostname and an IP suitable for mail. KoalaVPS has not verified those operational capabilities for launch. A domain with a clean DNS zone does not repair a blocked outbound port or guarantee recipient trust. Choose a separate recovery mailbox outside this server and decide whether delivery uses your own MTA or a properly configured external relay.

• Check TCP25 policy and the submission/IMAP ports required by the selected stack.
• Check whether the host and its container network are compatible with the suite.
• Reserve room for mailboxes, indexes, spam/virus tools and backup copies.

Official documentation: Mailcow system prerequisites

Choose the suite, then publish coherent DNS

Mailcow, Mail-in-a-Box and iRedMail have different installation and maintenance models; follow the chosen project’s supported OS and port requirements instead of combining their recipes. Set the mail hostname’s A/AAAA records, domain MX, matching PTR where applicable and the actual stack-generated DKIM public record. Publish SPF for every legitimate sender and introduce a DMARC policy after validating those sources. An unused or untested AAAA record can create a broken IPv6 delivery path.

# Substitute your domain and the actual server address:
dig MX example.com
dig A mail.example.com
dig TXT example.com
dig TXT _dmarc.example.com
dig -x 192.0.2.10

Official documentation: Mailcow DNS requirements

Test delivery and relay restrictions separately

Create a disposable mailbox and send a wanted test message to more than one external provider. Inspect the received authentication headers, send a reply and check queue/bounce behaviour. From an unauthenticated external client, verify that your MTA refuses to relay mail between unrelated third-party addresses. Check authenticated submission, IMAP TLS, password recovery and certificate renewal. A successful webmail login says little about outbound SMTP or inbox placement.

• Keep postmaster and abuse contacts monitored through an independent recovery path.
• Watch queues and rejection reasons rather than repeatedly resending failures.
• Do not treat a diagnostic score as a promise of inbox delivery.

Recover messages without losing the control plane

Back up mailbox contents, database, configuration, DKIM keys and the suite’s other required secrets using its consistent procedure. Test restoring a small mailbox and a user account on an isolated host. If inbound mail fails, work through MX, address reachability, firewall and queue logs. If outbound mail fails, inspect port policy, authentication, reputation and destination rejection. Keep updates and mailbox growth checks scheduled; deliverability is an ongoing responsibility rather than an installation milestone.