Saphira Linux MailDragon

A domain is the unit MailDragon routes mail for. You can add a new virtual domain, re-enable a disabled one, or take a domain offline without touching its stored mail. A built-in check inspects the domain across the mail system and DNS at once: the Postfix lookup, virtual users and aliases, the MX record, and the SPF, DMARC and DKIM TXT records that determine whether other systems will trust your mail.

A mailbox is a real login: a person or service that receives and reads mail. Creating one stores the password as a Dovecot hash and sets the Maildir path; you can then verify authentication directly. An administrator can reset a mailbox password without the old one, which is how support restores access when a user is locked out.

An alias redirects one address to another — mail to the source is delivered to the destination instead. Common role addresses (postmaster, abuse, hostmaster, webmaster, dmarc, support) can be staged for a new domain in a single step, so a fresh domain starts with the addresses operators expect.

• Redirect-style aliases forward mail to a real mailbox.
• Standard RFC and operational role aliases are created together for new domains.
• A conflicting mailbox or alias for the same address is resolved automatically when you create the other.

A recipient copy keeps normal delivery and also drops a BCC-style copy into another local mailbox. This is used for local compliance and journaling, never for uncontrolled external forwarding. A domain archive builds an archive mailbox and copies mail for the domain's current addresses from the moment it is enabled.

DKIM proves mail really came from your domain. MailDragon generates a domain key and prints the exact DNS TXT record to publish, then signs outgoing mail with Rspamd. Keys are rotated by generating a new selector that stays inactive until its DNS record is visible, then activating it only after a DNS check confirms the record — so mail is never signed with a key the world cannot verify.

• Create a key and publish the printed DNS TXT record.
• Rotate to a new selector; the old one keeps signing until DNS propagates.
• Activate only after the DNS TXT record is confirmed live.
• Keep old selectors published for 30–90 days so already-sent mail still verifies.

Encrypted mail transport depends on valid certificates. MailDragon issues, renews and revokes the certificates used by the mail services, and certificate rotation is automated so there is no annual scramble to remember what expires when.

Two backup styles cover different needs. A hot Maildir archive copies live mail to mounted backup storage while the server runs — good ongoing protection for received mail. A cold VM backup captures the whole mail VM from the host when it is stopped — good for disaster recovery. The database is backed up after any change to mailboxes, aliases, domains or archive rules.

• Do not delete mail by default — removal is always a deliberate, separate action.
• No catch-all addressing unless there is a specific reason.
• No external forwarding as a server-side default; it breaks SPF and DMARC and is handled separately with policy and SRS when needed.
• Archive and copy behaviour starts from the moment it is enabled, not from history.