TL;DR: A mail server needs more than an inexpensive VPS. Evaluate SMTP policy, reverse DNS, address reputation, authentication, storage growth, backups and the person responsible for delivery failures. Hostinger VPS is one candidate to assess against those requirements. Managed business email or a hybrid setup can be a better operating choice when the team cannot maintain mail infrastructure.
VPS email server vs a web-hosting mailbox
A VPS mail server gives you system-level responsibility for transport and mailbox services. A mailbox included with web hosting is a provider-managed email product with its own limits. Uploading PHP files or adding an MX record does not install an SMTP and IMAP stack on a shared website plan.
If the real question is whether to host your own email server at all, start with the self-hosted email cost and feasibility guide. Use this article when you have already decided to evaluate a VPS and need to compare network policy, DNS, storage and operations.
Define the email service you actually need
Business email includes several distinct workloads. Staff mailboxes need reliable inbound delivery, search, device access and account recovery. Transactional application email needs timely receipts, password resets and bounce handling. Marketing email requires consent, unsubscribe processing and a sending platform designed for bulk communication.
Do not put all three on one small server merely because they use SMTP. A problem with a campaign can damage the reputation of the address used for staff mail or password resets. Separate workloads according to their reliability and reputation requirements.
Start with mailbox count, expected storage growth, inbound and outbound volume, attachment patterns and support hours. Identify whether the organization needs calendar and collaboration features, retention rules, legal holds or centralized identity. Those requirements may make a managed business-email product more appropriate than assembling a basic mail stack.
Understand the components of a self-hosted stack
An SMTP server accepts and transfers messages. An IMAP service provides mailbox access. A webmail application is an interface, not the mail transport itself. Spam filtering, malware scanning, TLS, authentication and backups complete the system users depend on.
A typical Linux stack may use Postfix for SMTP, Dovecot for mailbox access and a separate signing and filtering layer. There are also integrated distributions and commercial control panels. Each choice adds its own update, configuration and recovery requirements.
The operating model matters more than the package names. Someone must investigate a queued message, a full mailbox, a compromised account or a recipient rejecting mail. If nobody can own that work, a self-hosted stack is unlikely to deliver the convenience expected from a business mailbox service.
Evaluate VPS candidates against mail requirements
| Requirement | Why it matters | What to verify |
|---|---|---|
| SMTP network policy | Mail transfer needs permitted connectivity | Current inbound and outbound rules and sending limits |
| Reverse DNS control | Receiving systems evaluate sender identity | Ability to set PTR and align hostname |
| Address reputation | Poor history can impair delivery | Assigned IP checks and remediation options |
| Storage and recovery | Mailboxes grow and contain business records | Capacity, backup consistency and restore time |
| Administrative access | Mail packages require system configuration | OS support, console access and patch ownership |
| Operational support | Delivery problems need diagnosis | Who owns transport, filtering and user support |
Use this checklist with Hostinger or another provider. Do not call a VPS the best simply because its memory specification is attractive. A small hardware saving can be outweighed by hours of undiagnosed delivery failures.
For general application-hosting considerations, read the Hostinger VPS evaluation. Mail adds reputation and interoperability requirements that a normal HTTP application does not have.
Check Hostinger's current SMTP policy
Hostinger currently documents that SMTP port 25 is not blocked on its VPS service, while also describing a sending limit. Verify the current policy and your own firewall rules before building the service. An open port is not permission to send arbitrary volumes or unsolicited mail.
Inspect both host and provider firewall layers. Distinguish server-to-server SMTP from authenticated client submission and mailbox access. Opening a client submission port does not replace the need for inbound SMTP if you are receiving mail directly from other mail systems.
Do not infer successful delivery from network connectivity. A receiving service may accept the TCP connection and then reject the message based on authentication, reputation or policy. Keep SMTP response codes and timestamps so you can distinguish transport failure, temporary deferral and final rejection.
Choose a hostname and DNS plan
Use a stable mail hostname such as mail.example.com. Create the required address record and configure the domain's MX record to reference that hostname. Ensure forward and reverse DNS describe a coherent sender identity, and avoid publishing an IPv6 mail path unless it is configured and tested end to end.
; Illustrative zone entries: replace domain and documentation IP
mail.example.com. IN A 203.0.113.10
example.com. IN MX 10 mail.example.com.
The address above is reserved for documentation and will not operate a real mail server. Configure PTR through the provider's reverse-DNS workflow for the actual assigned address. Check that the hostname resolves back to the intended server.
Keep existing records while planning a migration. Website, email and verification records serve different purposes. A nameserver change that omits the old mail records can interrupt business communication even when the new website works perfectly.
Configure sender authentication deliberately
SPF declares authorized sending paths for the envelope domain. DKIM signs messages so receivers can verify the signing domain. DMARC defines alignment and policy for messages using the visible From domain. These mechanisms complement each other; none guarantees inbox placement.
Start from a complete inventory of legitimate senders. Staff mail, an invoicing tool and an application email provider may all send using related domains. Publishing an overly restrictive policy before identifying them can block the organization's own messages.
; Examples only: merge with your actual authorized senders
example.com. IN TXT "v=spf1 ip4:203.0.113.10 -all"
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
; Publish the DKIM public key generated by your chosen mail stack
; at selector._domainkey.example.com, using its exact output.
Use a reporting mailbox you control and understand the volume and data involved. Review legitimate traffic before moving DMARC toward enforcement. Keep one coherent SPF record for a domain rather than adding several competing records. Verify DKIM from actual received message headers after deployment, not only from a DNS lookup.
The DMARC overview explains alignment and policy terminology. Configure the mail stack using its own current documentation; copying an unrelated signing configuration can produce apparently valid DNS with no correctly signed outgoing messages.
Size for stored mail and filtering work
Mailbox storage grows independently of website traffic. Estimate active users, average retained mail, attachments, retention periods and expected growth. Include database indexes, spam quarantine, logs, temporary queues and a restore workspace. A server with enough room for today's mail may have no space left to recover a backup safely.
Memory requirements depend on filtering and scanning as well as transport. Antivirus and indexing can dominate a small server's footprint. Test the full selected stack with realistic mailbox sizes and concurrency rather than sizing only an SMTP daemon at idle.
Avoid promising unlimited email as if it meant unlimited storage, throughput or deliverability. You can choose a licensing model without per-mailbox fees while still operating within hardware, network and support limits. Communicate those limits clearly to the business users who will depend on the service.
Secure submission, mailbox access and administration
Require authentication for client submission and encryption for user credentials. Keep administrative interfaces restricted and patched. Use strong per-user credentials or the identity integration supported by the selected stack, and provide a controlled account-recovery process.
Confirm that the server is not an open relay. It should not accept unauthenticated arbitrary mail for delivery to unrelated external recipients. Use the mail software's documented tests in a controlled environment; do not send unsolicited test messages to random addresses.
Set sensible account-level limits, monitor unusual outbound patterns and protect webmail against brute-force attempts. A single compromised mailbox can create a large spam queue and harm sending reputation. The response should include credential rotation, access review and investigation of the entry point, not only deletion of queued messages.
Verify connectivity and TLS from outside the server
Check the relevant services from a separate authorized machine. A local service can be healthy while an external firewall blocks it. Validate the certificate hostname, chain and expiry for both submission and mailbox access.
# Replace the example hostname; these inspect protocol negotiation
openssl s_client -starttls smtp \
-connect mail.example.com:587 -servername mail.example.com
openssl s_client -connect mail.example.com:993 \
-servername mail.example.com
Do not type real passwords into recorded terminal sessions or paste full protocol transcripts into public tickets. Check the server's logs and use a dedicated test mailbox for functional tests. Separate certificate verification from message-delivery verification so each failure has a clear diagnostic boundary.
Test inbound mail from more than one external service and outbound mail to your own controlled test accounts. Inspect authentication results and SMTP responses. Passing one test recipient is useful evidence, but it does not prove every destination will accept the same sender under all conditions.
Design queues and retries around mail behavior
Temporary SMTP failures should remain queued for a controlled retry according to the stack's policy. Permanent failures need a visible bounce or operator action. Distinguish accepted-by-server from delivered-to-recipient in application reporting; the first is not proof of inbox arrival.
Monitor queue age as well as queue length. A handful of messages stuck for hours may matter more than a large short-lived queue during normal activity. Keep enough metadata to identify destination patterns without collecting unnecessary message content into general application logs.
For transactional email, use idempotent application events and a clear retry policy. A password-reset request that times out should not produce an uncontrolled burst of repeated mail. A purchase receipt should have a recorded business event so operators can determine whether it was attempted, accepted or failed.
Plan mailbox migration without losing messages
Inventory accounts, aliases, shared addresses, forwarding rules and client settings. Back up the source and test the destination before changing MX records. Explain the cutover to users, including any password or device configuration changes.
Use a synchronization procedure that accounts for messages arriving during migration. An initial mailbox copy followed by a final sync is often necessary. Keep the old system available for a defined period and monitor delivery to both sides while DNS caches expire.
Verify message counts and representative folders, but do not rely only on totals. Check timestamps, attachments and user access. If calendar, contacts or collaboration features exist, treat them as separate migration data rather than assuming an IMAP copy transfers them.
Back up data and configuration together
A recoverable mail service includes mailbox data, user records, aliases, filtering settings, signing keys, certificates or their renewal method, and the configuration needed to rebuild the stack. Protect these backups according to the sensitivity of business correspondence.
Choose a backup method appropriate to the selected mail stack. A raw copy of files changing during delivery may not provide the consistency you expect. Use documented application-aware procedures and test the result on a separate environment.
Record how long it takes to restore one deleted mailbox and the whole service. Those are different support scenarios. Keep an independent copy and recovery access outside the VPS. Provider snapshots can help with a machine-level problem, but they should not be the only answer to accidental deletion or compromised accounts.
Establish useful operational checks
# Examples for a Postfix and Dovecot deployment, after installation
sudo postfix check
sudo postqueue -p
sudo doveadm service status
sudo journalctl -u postfix -u dovecot --since '1 hour ago' --no-pager
Commands vary by distribution and service layout. Learn the chosen stack's diagnostic tools and record them in a runbook. A control panel should make operations easier without becoming the only undocumented way to inspect the system.
Monitor disk space, queue age, delivery rejections, authentication failures, certificate expiry and backup completion. Use an external check for service reachability and a controlled functional mailbox test where appropriate. Alerts need a named responder and an escalation path when mail is business-critical outside normal office hours.
Compare self-hosted, managed and hybrid approaches
| Approach | Operational benefit | Ongoing responsibility |
|---|---|---|
| Self-hosted mailbox stack | Direct control over storage and configuration | Security, delivery, upgrades, recovery and user support |
| Managed business email | Provider-managed mailbox platform | Account administration, access and retention choices |
| VPS application with external transactional sending | Separates application hosting from outbound delivery | Integration, authentication, bounces and event tracking |
| Managed staff mail with separate campaign platform | Separates collaboration from bulk sending | Identity, consent and cross-service configuration |
A hybrid setup is often sensible. Your website and API can run on Hostinger while mailboxes or transactional delivery use a specialized service. Sharing a provider for everything is not a requirement for a coherent architecture.
Calculate the full cost, including administration time and recovery effort. A self-hosted system can be appropriate for a team with specific control requirements and relevant skills. It is a poor bargain when the business expects a fully managed collaboration service from an unattended Linux installation.
Create a controlled acceptance matrix for mail
A mail launch needs several independent tests because transport, authentication, mailbox access and client behavior can fail separately. Use accounts and domains you control. Keep test messages clearly identified and avoid sending personal or customer information during diagnostics.
Verify inbound delivery from an external account to a normal mailbox, then to an alias and any shared address you support. Test an invalid recipient and confirm the behavior matches the intended policy. Check that a forwarding rule does not create a loop or silently discard an expected message. These are business functions, not merely server-port checks.
For outbound tests, send to controlled accounts on representative destinations and inspect the received headers. Record the envelope domain, visible From domain, signing result and alignment outcome. A message in the spam folder is different evidence from a rejected message, and both differ from a message accepted but still queued elsewhere.
Test device configuration using the actual supported client settings. Verify server names, authentication, TLS and certificate validation. Do not work around a certificate mismatch by telling every user to disable verification. Correct the hostname and certificate arrangement so a new device can connect safely without special exceptions.
Document the result with timestamps, software versions and sanitized response codes. This acceptance record is useful later when a recipient changes its policy or an update alters the stack. It provides a known baseline rather than a vague memory that email worked on launch day.
Prepare a response to a compromised mailbox
Decide who can disable an account, rotate credentials and inspect the outbound queue. A compromised user can continue generating mail faster than an operator can delete it, so stop unauthorized access before treating the queue as the whole problem.
Preserve relevant evidence and distinguish legitimate messages from abuse before deleting or retrying queued mail. Review login activity, forwarding rules and application passwords. Investigate whether the attacker accessed stored correspondence or changed account-recovery information, not only whether spam was sent.
After containment, restore normal access through a controlled process and monitor outbound behavior. Review how the credential was exposed and whether other accounts share the same weakness. A runbook that includes these decisions reduces both downtime and the risk of repeating the incident.
Diagnose common failures methodically
If inbound mail fails, check MX resolution, destination hostname, network reachability and the SMTP response. If outbound mail is rejected, inspect the exact rejection, sender authentication and address reputation. If users cannot log in, check submission or IMAP separately from mail transfer.
A growing queue may indicate destination throttling, DNS trouble, authentication failure or a compromised sender. Read representative queue entries and logs before deleting anything. Deleting the queue can discard legitimate business mail without fixing the root cause.
If storage fills, identify mailbox growth, quarantine, logs and temporary files. Apply a documented retention decision rather than deleting unfamiliar mail directories. If a certificate expires, restore service through the supported renewal process and then fix the failed renewal monitoring that allowed the incident.
Production readiness and next steps
- Verify current provider policy, network rules and sending constraints.
- Configure forward DNS, MX and reverse DNS coherently.
- Test SPF, DKIM and DMARC using real received headers.
- Require authenticated encrypted submission and rule out open relay.
- Test controlled inbound and outbound delivery.
- Monitor queue age, storage, certificate expiry and abuse signals.
- Restore a mailbox and the full stack outside production.
- Assign user support, security updates and incident ownership.
Use this assessment before selecting a mail VPS or promising mailbox operations to a client. SoftwareCrafting's mail-server setup service can help configure a suitable stack and document its maintenance. Discuss your email requirements with mailbox counts, expected volume and recovery needs, including whether managed or hybrid email would be simpler.
Frequently Asked Questions
Is open SMTP connectivity enough to guarantee delivery?
No. Delivery also depends on recipient policy, address reputation, authentication, message quality and sending behavior. Keep SMTP responses and inspect real message headers when testing.
Can I offer unlimited mailboxes on a VPS?
You may avoid a per-mailbox software charge, but storage, CPU, network policy and support capacity remain finite. Define practical limits and monitor growth rather than promising unlimited capacity.
Should my application send password resets through its own mail server?
It can, but a specialized transactional service may simplify delivery operations. Compare reliability, integration, bounce handling, authentication and the team's ability to investigate failures.
Is this a complete installation manual for Postfix and Dovecot?
No. It is a VPS selection and production-readiness guide. Use the current documentation for your chosen mail stack for package installation and configuration, then validate the operational requirements described here.