Manage iRedMail mailboxes and application SMTP access

iRedMail assembles several services around the account backend selected at installation. Manage users through the documented interface or backend-specific procedure rather than inventing a universal SQL update for every deployment.

Create the intended account boundary

1. Follow account/alias and client guidance in the official docs for your open-source edition and selected backend.
2. Provision a controlled mailbox with the intended quota and aliases, and confirm postmaster/administrative destinations exist.
3. Configure clients with the documented full email address as login username and the actual host/TLS settings.
4. For application SMTP, use a permitted mailbox/submission credential and restrict the allowed sender identity where supported.

Do not put an administrator/database credential into an application’s SMTP password field. Authentication, alias ownership, sender authorization, and account-administration access are separate permissions.

Test the user and application paths

Verify correct/incorrect login, controlled receipt, mailbox retrieval, and one approved outgoing send. Inspect logs and signing headers rather than treating connection success as final delivery.

Check that unknown recipients and unauthorized relay are rejected appropriately. If feeding an application through forwarding, use an approved destination and avoid loops. MailKite’s incoming webhook or sending SDK is a separate provider contract, not an undocumented iRedMail management extension. Record account/backend changes so the recovery set can reconstruct them.