Services overview

A service is a connection between Frontmail and an email provider. Frontmail never sends email from its own infrastructure on your behalf – it renders your template and hands the message to your provider, so deliverability, sender reputation and provider pricing stay under your control.

Supported providers

Provider	Type	Best for	Delivery webhooks
SMTP (Seznam, Zoho, custom)	smtp	Existing mailboxes, own mail servers	–
Mailgun	mailgun	Transactional email, EU or US region	✓
Amazon SES	ses	High volume at low cost, AWS users	✓ (via SNS)
Postmark	postmark	Fast transactional delivery	✓
SendGrid	sendgrid	Transactional + marketing	✓
Mailjet	mailjet	EU-based transactional	✓
Brevo	brevo	EU-based, generous free tier	✓
Resend	resend	Developer-friendly API	✓
Gmail (OAuth)	gmail	Personal / Google Workspace mailboxes	–
Outlook / Microsoft 365 (OAuth)	outlook	Outlook.com and Microsoft 365 mailboxes	–

Personal services (SMTP mailboxes, Gmail, Outlook) are quick to set up and send from your real mailbox, but have low daily limits and no delivery tracking. Transactional providers need DNS setup but scale, give you delivery/bounce/open events and better deliverability.

Adding a service

Owners, admins and developers manage services in Email services.

1. Click Add service and pick the provider.
2. For Gmail and Outlook click Connect Gmail / Connect Outlook / Microsoft 365 and allow access in the provider’s window. For the others enter the credentials and click Verify & save – Frontmail verifies them with the provider (without sending an email) before saving. Save without verifying is available if you want to check later. Credentials are encrypted with AWS KMS (envelope encryption, AES-256-GCM) and are never shown again – you can only replace them.
3. On the service page, Test connection runs the same check again at any time.
4. Optionally set up the Webhook URL shown on the service page (see below).
5. Your first service becomes the default automatically; use Make default to change it. Templates without an explicit service – and API calls without service_id – use it. Deleting a service that templates use switches them to the default service.

Default sender (From)

Every service can have a Default From email and Default From name (in the add form and on the service page under Settings). The From address of each email is resolved in this order:

1. From email / From name in the template settings (may use parameters),
2. the service’s Default From email / name,
3. for Gmail and Outlook the connected account; for SMTP the username if it is an email address.

The template editor shows which sender will be used while the template’s From email is empty. Changing only the default sender doesn’t re-run the connection test. If no step yields an address, test sends fail with sender_not_configured and real sends fail permanently (the credit is refunded).

Caution

The default sender must be an address your provider lets you send from – a verified identity (domain or address) for Amazon SES, Postmark, SendGrid, Mailgun, Resend, Brevo and Mailjet, the mailbox or an allowed alias for SMTP, Gmail and Outlook.

Fallback service (failover)

Every template has a primary service and an optional fallback service, both chosen in the template editor under Settings → Delivery (Service and Fallback service). The sender tries the primary first. If it fails with an authentication or a permanent error, the same message is immediately sent through the fallback. The message timeline shows a failover event, and History shows which service actually sent it.

Transient errors (timeouts, throttling, 5xx) do not trigger failover – they are retried on the primary service first, because they usually resolve on their own.

Tip

Use two different providers (for example Postmark as primary, SES as fallback) so an outage or a suspended account at one provider doesn’t stop your forms. Both need the From domain verified.

How provider errors are handled

Frontmail classifies every provider error into one of three groups:

Class	Examples	What Frontmail does
Authentication	invalid or revoked API key, expired OAuth token (Google invalid_grant), SMTP 535	Marks the service unhealthy (Not working), emails the owner and admins, shows a dashboard banner. Sends through the fallback if there is one; otherwise refunds the credit and keeps the message as held_service_error.
Permanent	invalid recipient, unverified sender or domain, message rejected by policy	Tries the fallback if there is one; otherwise the message becomes failed and the credit is refunded. Hard bounces add the address to the suppression list.
Transient	timeout, connection reset, provider 5xx, 429 throttling, SMTP 421/450/451	Retries with exponential backoff (respecting the provider’s rate limits). If all retries fail, the message becomes failed and the credit is refunded.

Each provider guide lists its common errors and how they are classified.

Messages held because of a service error

Messages in held_service_error wait in the hold queue together with credit-held messages, marked with the reason service. As soon as the service is healthy again – after you update the credentials, reconnect OAuth or a health check succeeds – they are released automatically: a credit is reserved again and they are sent in the original order. You can also release or discard them manually. They expire like other held messages (Free 3 days, paid plans 14 days) and you get an email before that happens.

Health checks

• Daily: Frontmail verifies every service (the same check as Test connection).
• Immediately after an authentication error during sending.
• On save: whenever you edit credentials or reconnect OAuth.

A service is healthy (Healthy), unhealthy (Not working) or unknown (Not checked). When a service becomes unhealthy, owners and admins get an email and the dashboard shows the banner An email service isn’t working with a Fix service button until it recovers; you get another email when it is healthy again and its held messages have been released.

Delivery webhooks

Transactional providers can report what happened after they accepted the message. Copy the Webhook URL from the service page (it also lists the events to enable) into your provider console:

https://api.frontmail.dev/webhooks/providers/<type>/<token>

<type> is the provider type from the table above (e.g. mailgun), <token> is a random token unique to the service – treat the whole URL as a secret. Frontmail also verifies the provider’s signature where the provider supports it.

Events are mapped to message statuses and statistics:

Provider event	Frontmail
delivered	status delivered
hard bounce	status bounced + address added to suppression list
soft bounce	event only (provider retries)
spam complaint	status complained + address added to suppression list
open / click	opened / clicked events in the timeline and statistics

Without webhooks, a message ends in sent – which means the provider accepted it.

In the dashboard

See Email services for a walkthrough of adding, testing and fixing services.