ActiveManage Docs ← Back to activemanage.co.uk

E-mail Relay Clients

What is an Email Relay Client

An email relay client is the outbound counterpart to an inbox: it's the configured connection ActiveManage uses to send messages. While the email accounts settings tell the platform which mailbox to send from, the relay client determines how the message reaches the wider internet.

Relay clients list showing entries: Default SMTP (port 587), SendGrid (API), AWS SES (API), Postmark (API) with status indicators and 'Set as default' actions

Why Use a Relay

Plain SMTP from your application server works, but production-grade email needs a relay for three reasons:

  • Deliverability: Big relays (SendGrid, SES, Postmark, Mailgun) maintain warm IP pools, handle SPF/DKIM signing, and have established sender reputation.
  • Volume: Application servers throttle outbound SMTP; relays handle thousands per minute without blocking your web threads.
  • Tracking: Relays provide open, click and bounce webhooks that feed back into the email log.

Supported Providers

  • SMTP (any provider): Universal — works with Office 365 (Direct Send / SMTP AUTH), Google Workspace, Mailtrap (for dev), etc.
  • SendGrid: API-based, great free tier and analytics.
  • AWS SES: Lowest cost per message at scale, requires DNS validation per sender domain.
  • Postmark: Premium transactional delivery, excellent for receipts and password reset emails.
  • Mailgun, SparkPost, Resend: Other supported API endpoints.

Example Configurations

  • Small org: One Office 365 SMTP relay handling everything.
  • SaaS platform: Postmark for transactional (signup, password reset) where deliverability matters; SES for marketing where cost matters; both configured as separate relays.
  • Per-tenant relays: White-label customers configure their own SendGrid keys so messages route via their domain reputation, not yours.

Configuring an Email Relay

This article walks through adding a new relay client. The exact fields vary by provider, but the pattern is the same: pick a provider, supply credentials, validate, set defaults.

Relay configuration form for SendGrid showing API Key field, daily send limit, allowed sender domains list and a 'Send Test Email' action

Step-by-Step

  1. Go to Architect Panel → Email Relay Clients and click Add Relay.
  2. Select the provider type from the dropdown.
  3. Enter the credentials:
    • SMTP: host, port, encryption (TLS / STARTTLS), username, password.
    • SendGrid / Postmark / SES API: API key (and AWS region for SES).
  4. List the sender domains this relay is authorised for (e.g. yourcompany.com). Outgoing mail from other domains will route via a different relay if available.
  5. Set the daily and per-minute send limits if you want a safety cap.
  6. Click Send Test Email — choose a recipient and observe delivery.
  7. If everything looks good, tick Make default for the relevant scope (global, tenant or per-template).

DNS Records to Set

For reliable deliverability, regardless of provider, publish:

  • SPF: Authorises the relay's IPs to send for your domain.
  • DKIM: Cryptographic signing — the relay gives you a public key to publish.
  • DMARC: Tells receiving servers what to do with unauthorised mail. Start with p=none and graduate to p=quarantine once you've verified all traffic.

Examples

  • Office 365 SMTP relay: host smtp.office365.com, port 587, STARTTLS, mailbox credentials. Limited to 30 messages/minute.
  • SendGrid API: API key, supports tagged events for marketing dashboards.
  • AWS SES sandbox: Only sends to verified recipients until production access is granted by AWS Support.
Warning: Test the relay before setting it as default for production. A misconfigured relay can dump every outbound notification into spam folders for days while the IP reputation recovers.