Mailboxes and Forwarders
CorePanel runs a full mail stack — Postfix, Dovecot and Rspamd — and manages it per domain. This page covers the day-to-day: the addresses themselves. For how the stack fits together, see Mail System.
Which domains can have mail
Section titled “Which domains can have mail”| Primary domain | Yes — its own mailboxes and DKIM identity |
| Addon domain | Yes — its own mailboxes and DKIM identity |
| Alias (parked) domain | No mailboxes of its own; its mail is redirected to the primary |
| Subdomain | No. Mail belongs to domains, not to subdomains |
Mailboxes
Section titled “Mailboxes”Email accounts in the panel lists mailboxes per domain. Creating one asks for the
local part, a password and a quota in MB (0 = unlimited).
You can afterwards:
- change the password;
- resize the quota;
- enable or disable the account without deleting it;
- delete it.
Mailbox creation is capped by the account’s Email accounts limit (0 = unlimited).
Connecting a mail client
Section titled “Connecting a mail client”Use the server’s hostname, the full email address as the username, and TLS:
| IMAP | 993, SSL/TLS |
| SMTP | 587, STARTTLS (authentication required) |
| Username | The full address, info@example.com |
Webmail is available at webmail.<domain> — provisioned automatically for every domain,
which is why webmail is a reserved subdomain label.
Webmail sign-in
Section titled “Webmail sign-in”Three things about signing in are worth knowing, because they are enforced by default and you cannot miss their effects:
- HTTPS is forced. A plaintext request to
webmail.<domain>is redirected to HTTPS, so the password never travels in the clear. The redirect only happens while that hostname has a valid certificate — otherwise you would be sent to a connection that cannot complete, and the webmail would be unreachable on both ports instead of merely unencrypted. - A session is bound to the address that signed in. A stolen session cookie is useless from anywhere else. The cost is real: a client whose address changes mid-session — a phone moving between mobile data and Wi-Fi, some ISP proxies — is signed out and has to log in again.
- Every attempt is logged, successful or failed, with the client’s real address.
Webmail is reachable from the whole internet for every domain on the server, so mailbox passwords are what stands between an attacker and the mail. Set strong ones — the panel generates them for you when you create or edit a mailbox.
Forwarders
Section titled “Forwarders”A forwarder (alias) sends mail arriving at one address on to one or more other addresses. It is not a mailbox: nothing is stored, the message is passed along.
Use them for role addresses (sales@, billing@) that should land in a person’s
existing mailbox, or to deliver one address to a whole team.
You can forward to any address, inside or outside the server. Every destination is validated as a real email address.
Catch-all
Section titled “Catch-all”A catch-all delivers everything sent to an address that does not exist at the domain to one mailbox of your choice.
Convenient — nothing is ever lost to a typo — and expensive: spammers enumerate addresses, and a catch-all accepts every one of them. Prefer explicit addresses and forwarders, and use a catch-all only temporarily, for example just after a migration while you find out which addresses people actually use.
Whole-domain redirect
Section titled “Whole-domain redirect”A domain redirect sends every address at one domain to the same local part at
another: anything@olddomain.com → anything@newdomain.com.
This is what CorePanel sets up automatically when you add a domain alias, so that mail to the alias never bounces. You can also configure one by hand after a rename, so the old domain’s mail keeps arriving without recreating every mailbox.
A domain has one route: a catch-all and a redirect are mutually exclusive.
Per-mailbox: autoresponder and filters
Section titled “Per-mailbox: autoresponder and filters”Opening a mailbox gives you its own workspace.
Autoresponder
Section titled “Autoresponder”An out-of-office reply with a subject, a body, a start and end date, and a minimum interval between replies to the same sender (so one correspondent does not receive twenty identical answers).
Filters
Section titled “Filters”Rules applied at delivery: match on sender, recipient, subject or body, and file the message into a folder, forward it, or discard it. Filters are compiled to Sieve and run in Dovecot, so they apply no matter which client you read the mail with — including webmail and your phone.
Email authentication
Section titled “Email authentication”The Email authentication page shows, per domain, the state of the records that decide whether your mail is trusted:
| Record | Role |
|---|---|
| SPF | Lists which servers may send for the domain |
| DKIM | Signs outgoing mail with the domain’s key |
| DMARC | Tells receivers what to do when SPF and DKIM fail, and where to send reports |
For a domain whose DNS CorePanel serves, SPF and DKIM are published automatically when the domain is created. For a domain on external DNS, the page gives you the exact record values to paste into your provider, and Verify re-checks what is actually visible in DNS.
Publishing a DMARC record is the step most often skipped, and it is the one that turns
SPF and DKIM into an enforceable policy. Start with p=none and reports, then tighten.
From the CLI
Section titled “From the CLI”corepanel mail list example.comcorepanel mail quota sales@example.com 1024corepanel mail suspend sales@example.comcorepanel mail forwarder set sales@example.com owner@example.comcorepanel mail catchall set example.com bucket@example.comcorepanel mail redirect set old-example.com example.comcorepanel mail vacation set sales@example.com --subject "Away" --message "Back on Monday"Mailboxes are created from the panel; the CLI covers listing, quotas, suspension, deletion, forwarders, catch-alls, redirects, autoresponders and filters. The full command list is in the CLI reference.