Send through any SMTP server

How-to guide

For:: Workspace admins, Server operators
Needs permission:: providers:managesensitive, domains:managesensitive
In the app:: Sending providers, then Providers

You can send a newsletter via an SMTP server with ReputeCast: your own mail server, a relay, or a provider’s SMTP endpoint. SMTP has no event webhooks, so you also connect a bounce mailbox: ReputeCast reads the delivery failures and spam reports that land there and turns them into the same bounce and complaint events other providers send by webhook.

Kind	SMTP
Bulk marketing	Your own policy
Event webhooks	Bounce mailbox (IMAP/POP3)
Domain setup	Manual DNS
Suppression sync	Local only
Batch size	25 per connection
Notes	SMTP has no webhooks, so bounces are read from a bounce mailbox over IMAP or POP3.

Before you begin

The server’s details: host name, port, encryption and, if it requires one, a login. ReputeCast logs in with AUTH PLAIN or AUTH LOGIN; servers that offer only other methods (such as CRAM-MD5 or XOAUTH2) can’t be used. TLS needs version 1.2 or later and a certificate valid for the host name.
DKIM signing on the server or relay. ReputeCast hands each message over unsigned, so the server must sign it with your domain’s DKIM key.
A dedicated bounce mailbox reachable over IMAP or POP3, whose address will be the return-path (envelope sender) of every message. Don’t read it in a mail client: ReputeCast only fetches unread messages.
For a server on your own network (loopback or private addresses), an instance admin turns on providers.allow_private_networks (REPUTECAST_PROVIDERS__ALLOW_PRIVATE_NETWORKS=true). Cloud metadata addresses are always refused.
Permissions. Connecting needs providers:manage; adding a new sending domain needs domains:manage.

Connect an SMTP server

Open Sending providers, choose Add provider and pick the SMTP card in the catalog. Connect a sending provider explains the steps every provider shares.
In 1. Outgoing server, fill in:
- Host, for example smtp.example.com;
- Port and Encryption: STARTTLS on 587 (the default), implicit TLS on 465, or no TLS (only on a private network);
- Username and Password, if the server requires a login;
- Max rate you're allowed and Daily cap. SMTP servers don’t publish their limits, so ReputeCast throttles to the rate you enter (10 messages per second when you leave it empty) and backs off when the server answers with a 4xx code.
Choose Test connection. ReputeCast connects, says EHLO with your public URL’s host name, starts TLS and logs in, then disconnects; nothing is sent. The result shows what worked, for example “STARTTLS, TLS 1.3 · AUTH PLAIN accepted”, with the server’s replies.
In 2. Bounce mailbox, fill in the Return-path address, the Protocol (IMAP is recommended), the Mail server, port, login and, for IMAP, the Folder (INBOX by default). Choose Test mailbox. ReputeCast reads the mailbox without changing it and says how many messages it found and how many look like delivery reports.
Choose Continue to domain verification; it unlocks once both tests pass. Enter your sending domain. ReputeCast can’t add records on the server, so it lists what to publish: an SPF record with a:<your SMTP host>, merged with your existing SPF record, and DMARC if the domain has none. Publish the DKIM record your server or relay gives you.
In Test send, send a test. Delivery is confirmed by the server’s 250 reply; a bounce for an address that doesn’t exist arrives later through the bounce mailbox.
Finish Streams and Contacts. There is nothing to pull from an SMTP server: the suppression list stays in ReputeCast.

Check that it worked

The SMTP card on Sending providers, then Providers shows Healthy. ReputeCast repeats the connect-and-login check about every 5 minutes.
A bounce to an address that doesn’t exist shows up under Sending providers, then Events & sync within a few minutes, with the original status code.

ReputeCast sends up to 25 messages over one SMTP connection, with Message-ID, List-Unsubscribe, List-Unsubscribe-Post and Feedback-ID headers, and the bounce mailbox address as the envelope sender. SMTP servers report no deliveries: ReputeCast knows that the server accepted a message (its 250 reply) and learns about failures from the bounce mailbox. There, it reads standard delivery status notifications (RFC 3464), spam reports in ARF format (RFC 5965) and the common non-standard bounce formats; out-of-office replies and other mail are ignored. A report counts only when it is about a message ReputeCast sent (found by its X-ReputeCast-Message header or Message-ID) and names that message’s recipient; other reports are kept as events and change nothing. A permanent failure is a hard bounce and suppresses the address across the workspace; temporary ones are soft bounces. Unclear codes count as temporary, so nothing is suppressed on a guess.

Troubleshooting

“ECONNREFUSED · nothing listens on that port”, “ENOTFOUND · the host name doesn’t resolve” or “ETIMEDOUT · no answer within 15 s”. Check the host and port, and whether a firewall blocks outgoing SMTP from the ReputeCast host.
“… doesn’t offer STARTTLS on port …”. Use implicit TLS on 465, or turn encryption off only on a private network.
“… doesn’t offer a login method ReputeCast supports”. The server offers neither PLAIN nor LOGIN. Turn one on for the account, or use another relay.
The test connection fails with 535. The server rejected the user name or password.
“ReputeCast won’t connect to that address”. The host is on a private or loopback address. Turn on providers.allow_private_networks, or use the server’s public name.
“The mailbox rejected the user name or password.” Check the bounce mailbox login; some hosts need an app password for IMAP or POP3.
Bounces never show up. Check that the return-path address is the bounce mailbox, that nobody reads the mailbox in a mail client (read messages are skipped), and that the folder is right.
Gmail or Yahoo report DKIM as missing. ReputeCast doesn’t sign SMTP mail. Turn on DKIM signing on the server or relay and publish its key.