> ## Documentation Index > Fetch the complete documentation index at: https://docs.shipways.dev/llms.txt > Use this file to discover all available pages before exploring further. # Mail > Real mailboxes on a server you own, and the one thing this cannot promise. Shipways puts Postfix, Dovecot and Rspamd on an **application** server or a **mail** server, and manages every configuration file on it. You get mailboxes with IMAP, aliases, catch-alls and per-mailbox limits, on storage you own, instead of a seat you rent per person. A mail server type exists for machines that carry nothing else. It gets Nginx and no PHP, because Let's Encrypt proves control of the mail hostname by fetching a file over HTTP and the certificate is what the mail services refuse to start without. Install it from a server's **Mail** tab. ## What you are actually getting Mail is two halves, and they behave completely differently. **Receiving** works essentially everywhere. Once an MX record points at your server, mail arrives, is filtered, and lands in a maildir. Nothing about that depends on your hosting provider's goodwill. **Sending** is the hard half, and Shipways does not pretend otherwise. Most cloud providers block outbound port 25 by default, several block it permanently, and a fresh address is often already on a blocklist from whoever had it before you. So mail goes out through a sending provider you already have an account with, configured under **Sending** on the Mail tab. Postmark, Amazon SES, Mailgun and anything else that speaks SMTP with a username and a password all work. This split is the point rather than a limitation we are working around. The expensive, lock-in-heavy part of hosted mail is the mailboxes, the storage and the addresses, and those stay on your server. Delivery is a commodity, and the providers who do it have spent years building the sending reputation a single machine cannot. ### Sending directly You can send straight from the server, but only once Shipways has proved the machine is able to. Press **Check** under Sending and it asks three questions that cannot be answered from the configuration: 1. **Does anything get out of port 25?** It opens a connection to several large mail exchangers. One getting through is enough, because any single one may be refusing your address for its own reasons on the day you ask. 2. **Is this address on a blocklist?** Looked up from the server rather than from Shipways, because the big lists refuse queries from public resolvers and a refusal looks exactly like a clean result. If the server's own resolver will not answer either, the panel says *unknown* rather than *clean*. 3. **Does reverse DNS match the mail hostname?** Resolving is not enough. An address whose PTR is your provider's generated name resolves perfectly well and is exactly what the large receivers refuse mail from. All three have to pass before the switch is offered, and there is no override. That is deliberate. A server set to send directly on a provider that blocks port 25 does not report an error: it accepts the message, queues it, retries for ten days, and bounces it to somebody who stopped waiting a week ago. There is no configuration mistake to find afterwards, because there is none. Passing the check means your server can reach other mail servers. It does not mean they will accept what it sends. The large receivers weigh an address's history and a new address has none; Microsoft in particular is hard to reach from a small IP whatever your records say. Watch the queue for the first few days, and keep relay mode in mind as the answer if it does not settle. ## The mail hostname One name for the machine, chosen when you install. Every domain you carry mail for points its MX record at this single name, and it is the name the certificate is issued for. Use a subdomain such as `mail.example.com`, never your bare domain. It has to keep pointing at this one machine for as long as you host mail here, and your bare domain is the record you change when your website moves. Postfix and Dovecot will not start until the mail hostname has a certificate, and getting one needs the name to already resolve to the server. Add its `A` record first. ## DNS Shipways has no credential for your domain and never will, so publishing these is the one part of setting mail up that you do yourself. Each domain's page lists exactly what to add, with a copy button on every value, and checks them for you. | Record | What it does | | -------------------------- | ------------------------------------------------------------------------- | | `A` on the mail hostname | Points the name at the server. Add this one first. | | `MX` on the domain | Sends the domain's mail here. Must be the lowest preference in the zone. | | `TXT` on the domain | SPF: who may send as you. | | `TXT` on the DKIM selector | The signing key's public half. | | `TXT` on `_dmarc` | What receivers should do with mail that fails. Recommended, not required. | | `PTR` on the address | Reverse DNS. Set at your **hosting provider**, not in your zone. | Add your sending provider's include mechanism to the SPF record as well. Shipways renders `v=spf1 mx ~all`, which covers the server, and your mail goes out through somebody else. Postmark uses `spf.mtasv.net`, Amazon SES uses `amazonses.com`, Mailgun uses `mailgun.org`; your provider's setup page names theirs. A check that disagrees is not proof of a mistake. A record published five minutes ago and one never published look identical from outside, and DNS takes a while to spread. Press **Check again**. ### The DKIM key Shipways generates the keypair and holds the private half encrypted, rather than making it on the server. The public half lives in your zone until you go and change it, so a key that only existed on a disk would leave every signature failing the day you rebuilt the machine. ## Mailboxes Each mailbox is an address, a password and a directory of mail. They are virtual, so creating one never creates a login on the server: a mailbox password cannot be used to reach anything but mail. The password is shown **once**, when the mailbox is made. Only a digest is stored, so Shipways cannot show it to you again and nor can anybody who reaches the database. Set a limit in megabytes, or zero for no limit. The server's default is copied onto each mailbox when it is created, so raising the default later does not silently raise a mailbox you deliberately held down. ### Changing one, and resetting a password **Edit** on a mailbox row changes its name, its address and its limit, and can give it a new password. Tick **Give it a new password** and save: the new one is shown once, the same as when the mailbox was made. A reset takes effect on the server immediately. Whoever uses that mailbox stops collecting mail until they put the new password into their mail client, on every device they read it on. Renaming changes where **new** mail is delivered. What is already in the mailbox stays on disk under the old name, so a rename is not a way to move somebody's archive. ### How full a mailbox is Sizes are measured rather than known. Nothing on the machine keeps a running total worth trusting, so Shipways walks the maildirs: once a night, and whenever you press **Measure**. That walk stats every message file on the server, which is why it is not done while a page is drawing. Every size on screen therefore has a date on it, and a mailbox nobody has delivered to yet reads as not measured rather than as empty. You get an alert at 90% and a louder one when a mailbox is full. That matters more than it sounds: a full mailbox does not slow down or warn anybody, it just stops accepting mail, and the person whose mailbox it is usually finds out when somebody phones to say an email bounced. ### Suspending rather than deleting Suspending stops a mailbox accepting mail and logins, and keeps every message that is already in it. Senders are told during the SMTP conversation rather than getting a bounce afterwards. It is reversible. Deleting removes the address. **The mail stays on the disk**, under the domain's directory, because removing years of somebody's mail should be a thing you do deliberately with a shell rather than a consequence of pressing delete. The same is true of removing a whole domain. ## Aliases An address that delivers somewhere else, on this server or anywhere. Add the same address twice with different destinations to fan it out to several people. Leave the address blank to make a **catch-all**, which takes everything nobody else claimed. A domain has at most one. An alias cannot share a name with a mailbox. Postfix consults the alias table first, so it would take the mailbox's mail entirely rather than sitting beside it. ## Filtering Rspamd sees every message before it is accepted, and the **Filtering** panel on the Mail tab says what it has been doing with them: how much was scanned, how much was spam, how much was turned away at the door, greylisted, or delivered with a mark on it so a mail client files it as junk. These counters are cumulative since Rspamd last started, which is why the panel says the window they cover. Twelve thousand messages means one thing over a fortnight and quite another over an afternoon. Beside them is **how many messages are waiting to go out**. That is the number worth watching. A few for a few minutes is ordinary; a number that keeps climbing means mail cannot leave, and the usual cause is the sending provider refusing the credentials under Sending. Nothing is lost while it climbs — Postfix holds a message for ten days before giving up — but nothing is arriving either. Read every few hours, and on demand with **Read now**. Rspamd answers these questions on a port bound to loopback and nothing else. The same interface can be told to retrain the filter and move its thresholds, so it is not something to expose, and Shipways never opens it. ## When the machine disagrees Every mail file on the server belongs to Shipways outright, so **Check** under the mail configuration reads them all back and says which ones no longer say what the panel holds. Unlike the other drift checks, this one can tell you a file was *edited* rather than merely present or missing, because there is a right answer for its contents. It only ever looks. Applying the configuration again is what puts things back, and that is a button somebody presses: a check that silently undid an edit made to keep mail flowing during an incident would be the worst possible time to be clever. Maildirs are not part of this. A mailbox with no directory yet is the ordinary state of one nobody has written to, since Dovecot creates it on first delivery, and mail on disk for a deleted mailbox is deliberate. ## Logs A server carrying mail gets three more sources on its **Logs** tab. **Mail** is Postfix and Dovecot together, because both write to syslog's mail facility and that is the distribution's arrangement rather than something Shipways imposes. It is also what you want: a message's journey is spread across the two, and "where did this message go" is answerable from the pair in order and from neither alone. **Mail errors** is the same stream narrowed to what went wrong. **Rspamd** is what each message scored on the way past. ## Ports Installing mail opens these as ordinary firewall rules, so they appear on the **Network** tab like everything else. | Port | What connects | | ---- | ------------------------------------------------------------- | | 25 | Other mail servers. No authentication is offered here at all. | | 465 | Mail clients, encrypted from the start. | | 587 | Mail clients, upgrading to encryption. | | 993 | IMAP. | Ports 465 and 587 behave identically. Mail clients have disagreed for twenty years about which to use, so both are open. ## What Shipways owns Every mail configuration file on the machine is written whole from what Shipways holds, and rewritten on every change. Editing one on the server is undone by the next ordinary change, so make the change in the panel instead. Adding a mailbox, suspending one, changing a limit, adding a domain and switching sending provider are all the same operation underneath: render every file, compare it against the machine, write the ones that differ, reload what changed. ## Backups Set a destination and a schedule under **Backups** on the Mail tab. The destinations are the same ones the Backups page uses, so if you already back up databases there is nothing new to set up. One archive per domain, holding every mailbox on it. Each one is read back after it is uploaded — the checksum recorded, the gzip tested, the tar listed — so an archive that cannot be opened is a failure now rather than a surprise in six months. Shipways also says when an archive holds fewer mailboxes than the domain has, which is the shape a backup takes when it technically succeeded. Each archive is a **full copy**, not a sync of what changed. That is a deliberate trade: what lands in your bucket is one file you can fetch, verify and open, rather than a directory tree that has to be reassembled. It also means the storage and the time both scale with how much mail you hold, so pick the schedule and the number to keep with that in mind. Backups that stop running raise the same alert database backups do, so if you have that one ticked you are already covered. ### Restoring Restoring **never replaces a mailbox**. It cannot sensibly: the mailbox has gone on receiving since the archive was taken, and putting one back over the top would delete everything that arrived in between in order to recover something that arrived before. So pick an archive, pick which mailbox to restore into, and the archived mail arrives as a **new folder beside the inbox**, named for the date the archive was taken. It shows up in the person's mail client like any other folder. They open it, take what they came for, and you delete the folder afterwards. The folders the mailbox had at the time come back nested underneath, so an archive of a mailbox with a Sent folder restores as a folder with a Sent folder in it. Only the one mailbox is pulled out of the domain's archive. Everything else in that file is somebody else's mail and has no business being written back to recover one person's.