Configure mailcow domains, mailboxes, and application submission
Use suite-managed domain/account settings and verify aliases, sender permissions, signing, and client access independently.
Reviewed
Use mailcow’s administration model to create domains, mailboxes, aliases, and quotas. Postfix and Dovecot configuration is generated as part of the suite; standalone tutorials can conflict with the stored administrative state.
Create a bounded test domain
- Follow domain/mailbox and client-configuration guidance in mailcow’s documentation.
- Add the domain and a mailbox with an appropriate quota and restricted credential. Create aliases only for intended destinations.
- Publish the exact signing/authentication DNS for that domain and verify the actual host certificate.
- Configure an application using the documented authenticated SMTP listener, not the administrative API credential as an SMTP password.
Check sender permissions, forwarding, and any send-as aliases. A login working for a mailbox should not automatically let an application impersonate every address on the host.
Verify mailbox and submission outcomes
Use controlled messages to test receipt, IMAP/webmail access, and an approved outgoing send. Inspect activity and headers for DKIM/alignment and check negative authentication/relay cases.
If forwarding application mail to MailKite, set an explicit destination and prevent loops; MailKite’s later webhook authentication is separate. Do not migrate staff MX to an application receiver merely to add one automation. Keep administrative API access behind its documented authentication/network controls and retain the configuration in backups.