Prepare a VPS for private, deliverable email

01Separate mailbox control from message delivery

Self-hosting gives you control of the mail store, accounts, retention and software configuration. It also makes you responsible for availability, patching, spam filtering and backups. That trade can suit a personal domain or small team, but it is a continuing service rather than a one-time installation.

Delivery to other providers is a separate challenge. Receivers evaluate the sending IP, domain history, authentication, message behaviour and their own policies. A mail application that works locally can still have its messages delayed, rejected or placed in spam.

02Investigate the address before deploying

An allocated IP may carry history from earlier users. Check relevant reputation and blocklist information, then investigate findings before committing your mail service. No known blocklist entry is a useful starting point, not proof that the address has never been used or a guarantee of inbox placement.

Ask the host about outbound port 25, dedicated addressing and the ability to set reverse DNS. Root access alone does not grant permission to send SMTP or control the provider's PTR zone. Confirm the rules and technical capabilities first, including any IPv6-specific restrictions.

03Use authentication to establish domain authority

SPF publishes the systems authorised to send for the envelope domain. List all legitimate senders, respect the mechanism lookup limit and test before enforcing a hard-fail ending such as -all. Receivers make their own handling decisions; SPF is not an instruction that automatically guarantees acceptance or rejection.

DKIM signs selected message headers and content with a domain-controlled key. Publish the corresponding public key under a selector and protect the signing key on the server. A valid signature demonstrates authorised signing and integrity of covered content, rather than proving that a message is desirable or harmless.

04Align the visible sender with DMARC

DMARC relates the visible From domain to authentication. Passing requires an aligned SPF result or an aligned DKIM signature, not merely that an unrelated domain authenticated somewhere in the message. Publish the appropriate policy and examine aggregate reports to discover legitimate senders you may have missed.

Begin with monitoring if the domain's sending paths are uncertain, then move toward quarantine or rejection when legitimate traffic is correctly aligned. Handle reporting addresses and stored reports deliberately because they contain operational information. Use the current DMARC documentation, not a copied historical configuration.

The DNS examples use a reserved domain and documentation address. Replace all values with your actual sending domain, address and reporting mailbox; do not publish them unchanged.

example.invalid. TXT "v=spf1 ip4:203.0.113.45 -all"
_dmarc.example.invalid. TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

05Make reverse DNS and the server identity agree

The mail IP should have a PTR pointing to an appropriate hostname, and that hostname should resolve forward to the same address. Configure the server's EHLO name consistently. The provider normally controls PTR records, so arrange the setting through its supported process.

Publish MX and address records, configure TLS and test certificate renewal. If you send over IPv6, evaluate its address reputation and reverse DNS separately. Do not publish or use an IPv6 sending path simply because the VPS includes one if you cannot maintain that path correctly.

06Build a safe mail service before sending volume

Choose a maintained mail stack and expose only the necessary services. Require authentication for submission, prevent open relaying and use appropriate TLS for client access. Test with independent recipients and inspect message authentication results and delivery responses.

Send modest, expected traffic while establishing a history. Protect accounts against compromise, process bounces and avoid unsolicited bulk mail. Authentication records and an unlisted address cannot compensate for abusive traffic, a stolen mailbox or a domain that receivers distrust.

• Confirm SMTP permissions and PTR support before installing.
• Test SPF, DKIM and DMARC alignment from real delivered messages.
• Verify the server is not an open relay.
• Check client TLS and certificate renewal.
• Review bounce responses instead of repeatedly resending.
• Maintain consistent, legitimate sending patterns.

07Understand what hosting privacy does and does not cover

Minimal signup data and a private payment method can reduce billing links between the server and its operator. DNS registration information, contact addresses, mail headers and account recovery can create other links. Review those layers rather than assuming the hosting account defines the whole privacy boundary.

Self-hosting does not make ordinary email end-to-end encrypted. TLS protects particular transport connections; message contents can still be readable at endpoints and intermediate mail stores. Use suitable end-to-end tools when correspondents require content confidentiality, and account for the metadata email necessarily exposes.

08Plan ongoing operation and recovery

Keep the operating system and mail software updated, monitor queue growth and resource use, and choose sensible retention for diagnostics. Encrypt backups and include mailbox data, configuration and signing keys. Test restoration without accidentally sending duplicate queued mail.

Be realistic about the workload. A low-volume personal domain may be manageable, while a large sender needs more monitoring and careful operational processes. Address quality, root control and DNS support establish the foundation; regular maintenance earns and preserves the service's usefulness.