Sending modes
Bizzkit Mail runs in one of three sending modes, and the mode decides what actually happens when a mail is dispatched: whether it reaches the recipient, is only simulated, or is restricted to a list of approved domains. The mode applies to the entire environment, no matter which mail policy or SMTP server a mail uses.
The mode is read at the moment each mail is dispatched, so a change takes effect on the next dispatch attempt without restarting anything.
The three modes
The setting is called operationMode in the API, and it accepts one of three values. Each value changes both the outcome of a dispatch and the resulting status of the mail.
Production
Mails are handed to your SMTP server and delivered to their recipients. A mail the server accepts ends up as Sent. Anything it rejects is recorded in the mail's error history and retried according to the mail policy.
This is the mode a live solution runs in, and it is the mode a newly provisioned environment starts in.
Test
Mails are handed to your SMTP server exactly as in Production, but only when every email address on the mail belongs to a whitelisted domain. If a single address does not, the mail is not sent at all. See Whitelisted domains below.
Test mode never rewrites or redirects a mail. A mail that fails the check is treated as a failed dispatch attempt, not quietly dropped.
Simulation
Nothing is sent. Bizzkit Mail skips the SMTP server entirely and marks the mail as Sent.
Warning
A simulated mail is discarded, not delivered and not stored as an outgoing message. The Sent status only means Bizzkit Mail finished processing it. The mail record itself, including its content and addresses, is still available in the admin site, so you can verify what would have been sent.
Choosing a mode
The mode is set per environment, so which one fits depends both on the environment and on how far along your integration is.
Bizzkit recommends
Leave your staging environment in Test permanently, with only the domains you control whitelisted. Nothing produced in staging, whether it is a draft template, a test order, or an imported address list, should reach anyone outside your own organization, and Test mode is what enforces that. Your integration still exercises the real SMTP server, credentials, and encryption.
Run the production environment in Test as well while you build and verify the integration, and switch it to Production as part of going live. Confirm the change before the first real order confirmation is enqueued.
Use Simulation for load and throughput testing, where the volume of mails matters and delivery does not.
Changing the sending mode
The sending mode has no screen in the admin site. It is read and changed through the API, which you can call from the Scalar OpenAPI explorer at https://<MAIL_API_DOMAIN>/scalar or from any HTTP client. See the Mail API reference for the full contract.
Read the current mode with GET /api/settings/mail-sending, and change it with PUT /api/settings/mail-sending:
Both endpoints are covered by the mail settings permissions, which the admin role holds by default.
Warning
A newly provisioned Bizzkit Mail environment starts in Production. It therefore delivers mail to real recipients as soon as an SMTP server and a mail policy are configured. Set the mode you intend to use before you enqueue your first mail.
Whitelisted domains
Whitelisted domains restrict which domains Bizzkit Mail is allowed to send to and from while running in Test mode. They are ignored in Production and in Simulation.
Before dispatching a mail, Bizzkit Mail collects the domain part of every address on it: From, To, Reply-to, CC, and BCC. All of them must be whitelisted. This includes your own sender domain, so remember to whitelist it alongside the recipient domains you want to test with.
Matching is exact and case-insensitive. A parent domain does not cover its subdomains, so whitelisting example.com does not permit mail.example.com, which needs an entry of its own.
Add a domain with POST /api/whitelisted-domains:
List the current entries with GET /api/whitelisted-domains, and update or delete a single entry at /api/whitelisted-domains/{id}. Note that a response describes the domain in a field called name, while the request bodies for creating and updating expect domain.
When a mail carries a domain that is not whitelisted, dispatch fails before the SMTP server is contacted. The mail gets an entry in its error history explaining which domain was rejected, is retried on later batches, and ends as Failed permanently once it reaches the maxNumberOfAttempts of its mail policy.