Email Delivery Connections

Supported providers

Mailrith does not send email itself — instead, it connects to your existing email delivery service and handles the campaign workflow, audience targeting, and engagement tracking on top of it. This bring-your-own-delivery model means you keep full control over your sending infrastructure, reputation, and costs.

Mailrith supports the following providers out of the box:

• Amazon SES — AWS-native sending with dedicated identities, regional control, and SNS-based bounce tracking.
• Postmark — transactional-style sending with stream-specific routing and a simple webhook setup.
• SendGrid — flexible sending infrastructure with a unified Event Webhook for all delivery events.
• Mailgun — domain-based sending with US and EU region support and direct domain control.
• Resend — lightweight API-driven sender with straightforward domain verification.
• Brevo — useful when you already manage sender identities in Brevo and want Mailrith to handle the campaign logic.
• Custom SMTP — any SMTP server not on the list above that supports standard SMTP authentication.

You can have multiple active connections — for example, one Amazon SES connection for transactional mail and a Postmark connection for marketing broadcasts — and choose which connection to use per send.

Provider setup guides

Each provider has a dedicated setup guide with the specific steps required to connect it to Mailrith, including credential locations, webhook configuration, and test send verification:

• Set up Amazon SES
• Set up Postmark
• Set up SendGrid
• Set up Mailgun
• Set up Resend
• Set up Brevo
• Set up Custom SMTP

Create and test a connection

To add a new connection, open the Email Delivery Connections page and click Add connection. Select the provider type and fill in the required credentials. Every connection stores:

• From name and From email: the sender identity that appears in the "From" field of every email sent through this connection. Make sure this matches a verified sender identity in your provider account.
• Provider credentials: API keys, tokens, SMTP details, or other authentication required by the provider.
• Workspace assignment: which workspaces are allowed to use this connection for sends. A single connection can be shared across multiple workspaces.

After saving a connection, always use the Send test email action to verify that credentials are correct and email actually reaches an inbox before using the connection in a live broadcast or sequence. A failed test send reveals credential issues or sender verification problems before they affect a real campaign.

Webhooks

Mailrith exposes webhook endpoints for each connection so your email provider can send bounce and spam complaint events back to Mailrith. When these events arrive, Mailrith automatically updates the affected subscriber's status — setting them to Bounced or Complained — and excludes them from future sends.

To find the webhook URLs for a connection, click View webhooks on the connection row. The drawer shows the exact endpoint URLs to configure in your provider dashboard. Note that providers differ in how they deliver events:

• Amazon SES: uses separate SNS topics for bounces and complaints — configure both endpoints.
• Postmark, Resend, Brevo: use a single unified endpoint for all event types.
• SendGrid: uses a single Event Webhook stream that includes both bounce and spam report events.
• Mailgun: uses a single webhook endpoint; configure it in Mailgun's Webhooks section.

Setting up webhooks correctly is important for list hygiene. Without them, bounced addresses and complaint events will not update subscriber statuses in Mailrith, and those contacts will continue to receive emails — damaging your sender reputation over time.

Using connections in sends

When creating a broadcast or setting up a sequence, you select which delivery connection to use for that send. Mailrith only shows enabled connections in the send configuration — if you have disabled a connection, it will not appear as a send option for new campaigns.

Historical sends retain their original connection reference for audit purposes, even if that connection is later disabled or deleted. This means you can review past campaign delivery details without losing context.