Webmail

CorePanel ships a webmail client — Roundcube — so a mailbox owner can read and send mail from a browser, without configuring anything. There is nothing to install and nothing to enable: it is part of the server from the moment CorePanel is installed, and every domain gets its own address for it.

There is nothing to create

Webmail is provisioned with the domain, not separately. When you create a hosting account, add an addon domain or park an alias, CorePanel writes:

• a website for webmail.<domain>, serving the webmail;
• an A record for the webmail host in the domain’s DNS zone, when CorePanel manages the DNS;
• webmail.<domain> into the domain’s certificate request, alongside www, mail, ftp and corepanel — see SSL/TLS Certificates.

This is why webmail is a reserved label: you cannot create a subdomain called webmail, because the domain already has one. The same goes for the account’s subdomains.

	Gets webmail.<domain>
Primary domain	Yes
Addon domain	Yes
Alias (parked) domain	Yes — it serves the same webmail
Subdomain	No

External DNS

If the domain’s DNS is hosted somewhere else, nothing creates the record for you: add an A record for webmail pointing at the server’s IP address, or the address will not resolve and no certificate can be issued for it. See Preparing Your Domain.

All of these addresses are served by one shared Roundcube installation. The hostname decides which certificate is presented and nothing else — it is not a separate copy per domain, and there is no per-domain configuration to maintain.

Signing in

Send the mailbox owner to https://webmail.<their domain> and have them use the full email address as the username.

Address	https://webmail.example.com
Username	The full address — info@example.com
Password	The mailbox password (not the hosting account password)

The webmail is not reached from the panel. It is a service for the people who own the mailboxes, and they do not need a panel login — only the address above.

Under the hood Roundcube reads the mail over IMAP from Dovecot on the same server, and sends through Postfix on port 587 with the same credentials the user typed. Mail read in the webmail is the same mail seen over IMAP on a phone: folders, read state and filters are shared, because they live in the mailbox, not in the client.

Any mailbox on the server can sign in at any webmail.<domain> on that server — the address is not a boundary, the mailbox credentials are. That is occasionally useful: if a newly added domain has no certificate yet, its users can sign in through another domain’s webmail in the meantime.

What the webmail can and cannot do

Roundcube covers reading and writing mail: folders, search, an address book, an Archive button, and downloading several messages or attachments at once as a zip. It is deliberately kept to that.

Anything that changes the mailbox itself is done in the panel, not in the webmail:

	Where
Change the mailbox password	Panel → Email accounts, or the client panel
Autoresponder (out of office)	Panel → the mailbox’s workspace
Filters (Sieve rules)	Panel → the mailbox’s workspace
Quota, enabling and disabling	Panel → Email accounts

Keeping them in one place is the point: a filter written in the panel applies to mail arriving at the server, so it works the same in the webmail, on a phone and over POP3. See Mailboxes and Forwarders.

Attachment size

Roundcube accepts uploads of up to 25 MB per message. The message still has to leave through Postfix, which enforces its own limit (10 MB by default) on the whole encoded message — and attachments grow by roughly a third when encoded for mail. In practice anything much over ~7 MB of actual file is better sent as a link than as an attachment.

Security

The webmail is reachable from the whole internet, for every domain on the server. It is configured accordingly, and these defaults are visible to users, so it is worth knowing what they do:

• HTTPS is forced. A plain HTTP request to webmail.<domain> is answered with a redirect to HTTPS, so no password travels in the clear. The redirect is only issued while that hostname has a currently valid certificate — otherwise users would be bounced to a handshake that cannot complete, which would take the webmail off the air on both ports instead of merely leaving it unencrypted.
• A session is bound to the address that created it. A stolen session cookie is useless from anywhere else. The cost is real: a client whose IP address changes mid-session — a phone moving between mobile data and Wi-Fi, some ISP proxies — is signed out and has to sign in again.
• Every sign-in attempt is recorded, successful or failed, with the client’s real address. Roundcube talks to Dovecot over loopback, so without this record every webmail attempt would appear in the mail logs as coming from 127.0.0.1.
• Only webmail.* hostnames are answered, so the installation cannot be made to generate links pointing at somebody else’s host.

Mailbox passwords are what stands between an attacker and the mail. Set strong ones — the panel generates them when you create or edit a mailbox — and check a mailbox’s Security section, or Access Protection, when something looks wrong.

A suspended account keeps its webmail: mail is still delivered and still readable, which is what you want while a billing issue is sorted out.

How it is isolated

The webmail is a PHP application exposed to the internet, so it does not run as any hosting account and cannot reach one:

• it runs as its own roundcube system user, which has no shell, in its own PHP-FPM pool, separate from every account’s pool;
• its PHP is confined to the Roundcube directory (open_basedir), with the process-execution functions disabled;
• temporary files, including attachments being uploaded, stay in Roundcube’s own directory rather than the shared /tmp, where other accounts could read them;
• its small SQLite database holds preferences, contacts and caches. Messages are never stored there — they stay in the mailbox, on Dovecot.

One operational consequence: Roundcube requires PHP 8.4, so that version cannot be removed from the server while the webmail is in use. Server maintenance never removes a PHP version for exactly this kind of reason.

Troubleshooting

Symptom	Cause
webmail.<domain> does not resolve	The A record is missing — normal when the domain’s DNS is hosted elsewhere
Certificate warning, or no redirect to HTTPS	No valid certificate for that hostname yet. Check the domain’s certificate status; issuance needs the name to resolve to this server
”Invalid username or password” with the right password	The username must be the full address. The hosting account username will not work
Signed out every few minutes	The client’s IP address is changing mid-session (mobile networks, some proxies)
Cannot change the password from the webmail	By design — it is changed in the panel or the client panel
Large attachment refused on send	The message exceeds the server’s mail size limit, not the upload limit