Zilch Mail is built around a bring-your-own-provider model. You connect the SMTP accounts or supported provider APIs you already control, and the desktop client sends through those connections instead of putting a third-party relay between you and the recipient mail server.
Choose the right connection type
| Connection | Best for | What to prepare |
|---|---|---|
| SMTP account | Mailbox-based sending and custom domains | Host, port, username, password or app password, and encryption mode |
| Provider API | Transactional or high-volume provider workflows | Provider API key, sender identity, and provider-side limits |
| Custom HTTP provider | A compatible internal or specialist sending service | Endpoint, authentication, payload requirements, and webhook details |
Prepare the sender before adding it
- Use an account and domain you are authorized to send from.
- Confirm that the provider allows the type and volume of mail you plan to send.
- Use an app password or provider token when the provider does not allow the normal account password for SMTP.
- Make sure the From address, Reply-To address, and authenticated sender identity are consistent.
- Complete SPF, DKIM, and DMARC setup before scaling beyond small test sends.
Add and test the account
- 1Open SMTP Accounts and create a new account.
- 2Select the provider or custom SMTP path and enter the connection details.
- 3Set a conservative per-account throttle and save the account.
- 4Run a test send to an inbox you control and verify the From, Reply-To, links, and headers.
- 5Only add the account to a live campaign after the test succeeds and the provider reports no policy errors.
Do not use rotation to hide poor sender health
Account rotation is for distributing legitimate workload across accounts with appropriate limits. It is not a substitute for consent, domain authentication, warm-up, or provider policy compliance.
Use rotation and throttling deliberately
Zilch Mail can rotate across multiple accounts and apply per-account throttles. Start with one or two senders, observe bounce and complaint signals, and increase volume gradually. If one provider reports a temporary failure, reduce its load instead of immediately shifting all traffic to the remaining accounts.
Troubleshoot the common failures
- Authentication failed: recheck the username, app password, API key, or provider-side permission.
- TLS or connection failed: confirm the host, port, encryption mode, and local firewall rules.
- Sender rejected: verify the From identity and domain authentication in the provider dashboard.
- Messages are delayed: lower the throttle and check provider rate limits or temporary deferrals.
- Bounces are rising: pause the campaign, inspect the bounce classification, and clean the recipient segment before resuming.
Start with a controlled test cohort
A small internal test list catches authentication, rendering, tracking, and unsubscribe problems before they affect a full campaign.