How to Configure HestiaCP Email Without Guesswork

A mailbox can exist in HestiaCP and still be useless. If DNS points somewhere else, TLS is broken, or the server has no valid reverse DNS, messages will land in spam or fail outright. To configure HestiaCP email properly, treat the mailbox, mail server, and DNS records as one job.

This is not a managed-email setup with someone else fixing the missing pieces. HestiaCP gives you the controls. You still need to use them correctly.

What HestiaCP Email Actually Configures

A standard HestiaCP installation uses Exim to send mail and Dovecot to receive it through IMAP or POP3. When you add a mail domain and mailbox, Hestia creates the local account and applies the server’s mail configuration.

That part is easy. Deliverability is the harder part.

Your domain needs a mail destination, the sending server needs permission to send for that domain, and receiving servers need proof that the connection and sender are legitimate. Missing one record does not always stop email immediately. It often creates the worse outcome: mail that appears sent but quietly goes to junk.

Before changing anything, decide what role the domain will have. A small site may only need one address such as [email protected]. A business using Google Workspace, Microsoft 365, or another external provider should not add the same domain as a local mail domain in HestiaCP unless it has a specific reason. Two systems trying to receive email for one domain is how mail gets lost.

Configure HestiaCP Email in the Right Order

Start with the hostname. The server should identify itself with a fully qualified hostname, usually something like mail.example.com or server1.example.com. That hostname needs an A record pointing to the server IP address, and its TLS certificate should be valid.

Do not use a bare hostname such as mail. Do not use an IP address as the mail server name. Receiving servers check this stuff.

In HestiaCP, review the server hostname under the server settings before creating mailboxes. If your hosting account does not allow server-level changes, use the hostname provided by the host. On shared hosting, the provider may control the outbound mail server and reverse DNS. That is normal. It also means you cannot solve every deliverability problem from the user panel.

Next, open MAIL in HestiaCP and choose Add Mail Domain. Enter the domain you want to receive mail for. Enable DKIM support if the option is available. HestiaCP will generate the DKIM key and show the DNS record you need to publish.

After adding the mail domain, create a mailbox. Use a real password, not a recycled WordPress password. Mailboxes are frequent brute-force targets, especially addresses such as admin, info, and support.

For a basic setup, create only the addresses you will use. Forwarders and catch-all addresses sound convenient, but they create spam problems fast. A catch-all accepts mail sent to any random address on your domain, including junk sent to addresses that do not exist.

Set the mailbox connection details

For email apps, use IMAP unless you have a specific reason to use POP3. IMAP keeps mail synchronized between your phone, desktop app, and webmail.

Use the full email address as the username. The incoming server is usually your mail hostname, with IMAP over port 993 and SSL/TLS enabled. The outgoing SMTP server is normally the same hostname, using port 465 with SSL/TLS or port 587 with STARTTLS. SMTP authentication should be enabled.

Exact ports can vary by host policy. If the provided account details differ, use those. Guessing is not configuration.

DNS Records That Make Mail Work

If HestiaCP manages your DNS zone, you can add records in the DNS section. If your DNS is handled by Cloudflare, a registrar, or another provider, add them there instead. Do not maintain competing DNS zones and expect consistent results.

At minimum, check these records:

• A record: Point `mail.example.com` to the server’s IPv4 address. Add an AAAA record only if IPv6 is configured correctly for mail.
• MX record: Point `example.com` to `mail.example.com`. The target must be a hostname, not an IP address.
• SPF TXT record: Authorize the system that sends mail for the domain.
• DKIM TXT record: Publish the key generated by HestiaCP for the mail domain.
• DMARC TXT record: Tell receiving servers what to do when SPF and DKIM checks fail.

A simple SPF record for mail sent only through your server may look like this:

v=spf1 a mx -all

This says the domain’s A record and MX server are allowed to send mail, while all other senders should fail. It is clean, but only use it if those are truly the only senders. If your website sends through a transactional mail service, newsletter platform, or external support tool, SPF needs to authorize that service too. SPF has a DNS lookup limit, so stacking random includes from five vendors is not a long-term plan.

HestiaCP’s DKIM record will have a selector, often something similar to default._domainkey. Copy it exactly. A missing quote, a broken line, or publishing it under the wrong hostname will fail validation.

For DMARC, start in monitoring mode if you are unsure:

v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r

The p=none policy asks receivers to report failures without telling them to reject mail. Once legitimate mail passes SPF and DKIM consistently, move to p=quarantine or p=reject. Do not publish p=reject on day one if you have no idea which services send as your domain.

Reverse DNS Is Not Optional for Serious Sending

Forward DNS proves that mail.example.com points to an IP address. Reverse DNS, also called PTR, proves that the IP address points back to a hostname.

For a clean setup, the server’s outbound IP should have a PTR record that resolves to its mail hostname, and that hostname should resolve back to the same IP. This is called forward-confirmed reverse DNS. Large mailbox providers care about it.

PTR records are controlled by whoever owns the IP range, usually the VPS provider or hosting company. HestiaCP cannot create them. If you are on shared hosting, this is generally handled at the server level. If you run your own VPS, set it in the provider dashboard or ask the provider to set it.

A valid PTR does not guarantee inbox placement. A bad IP reputation, high complaint rate, hacked website, or spammy content can still hurt delivery. But no PTR is an avoidable problem.

Add SSL Before Connecting Mail Apps

Mail clients should not connect with unencrypted credentials. Get a valid certificate for the mail hostname and make sure Exim and Dovecot are configured to use it.

HestiaCP can request Let’s Encrypt certificates for domains, but the mail hostname must resolve publicly before validation can work. If you use a DNS proxy service, do not proxy the mail hostname. Mail protocols are not ordinary web traffic, and proxying an A record meant for IMAP or SMTP will break client connections.

After the certificate is active, test webmail or connect with a mail app using the hostname, not the server IP. A certificate warning usually means the hostname, DNS record, and certificate names do not match.

Test Sending and Receiving Before You Trust It

Send a message from the new mailbox to an address at Gmail, Outlook, or another external provider. Then reply back. This verifies both directions.

Inspect the received message headers. Look for SPF, DKIM, and DMARC results. You want passes, not soft fails, neutral results, or missing signatures. Also check that the visible From address matches the domain authenticated by SPF and DKIM. Alignment matters for DMARC.

If outgoing mail fails, check the obvious causes first: incorrect SMTP credentials, blocked outbound port 25, a missing or invalid PTR record, or a server IP with poor reputation. If incoming mail fails, confirm the MX record, the mail A record, firewall access to SMTP port 25, and whether another provider still has MX records for the domain.

For websites, do not assume PHP mail is configured well just because the mailbox works. Set your application to send through authenticated SMTP when possible. WordPress plugins, Laravel apps, and other software are less likely to spoof local senders or create malformed headers when SMTP is explicit.

Keep the Setup Small and Maintainable

Email is one of the few parts of web hosting where adding more settings often makes things worse. Use one clear mail hostname, one authoritative DNS zone, a short SPF policy, DKIM, and a DMARC policy you understand. Avoid catch-alls, unnecessary forwarders, and mystery records copied from old tutorials.

If you are using a low-cost hosting account for a small site, local email can be perfectly practical. If your business depends on high-volume sending, complex compliance requirements, or guaranteed inbox placement, use a dedicated email provider and keep HestiaCP focused on hosting the site.

Set it up cleanly, send a few real tests, and read the headers. Email does not reward optimism. It rewards proof.