Mail delivery

By default we send subscriber notifications from our own mail domain. There is a reason for that: this domain carries the signature and the sending authorisation that get your mail past the recipients' spam filters, so we cannot simply swap it for yours.

What you can control is on this page — from the reply address to sending entirely through your own server.

Sender name

Your subscribers' inbox shows your status page's name with "Status Page" added, for example Rechnungskit Status Page — "Rechnungskit Statuspage" on a German page. That makes it plain the mail comes from your status page, not from sales or billing. You change it through the name of the status page.

Replies: Reply-To

Notifications are sent from our own mail domain. They have to be — that domain carries the signature and the sending authorisation that get your mail past spam filters in the first place. What it does not carry is a mailbox.

With nothing else configured that means: a subscriber who replies to an incident email gets a bounce, and you never learn that somebody tried to reach you.

So under Settings → Subscribers → Replies there is a Reply-To field. Put the address you want to be reachable at there — usually your support mailbox or your ticketing system. Replies from your subscribers then go straight to it.

We recommend setting it. An incident notice is the moment customers have questions; a sender address that does not answer feels dismissive at exactly the wrong time.

• The sender stays our domain, and the display name remains your status page's (see Sender name). To the recipient the mail looks exactly as it did before.
• Any address works, including one at another provider. It is not verified and does not have to belong to you — so watch for typos, or replies go to a stranger.
• Available on every plan.
• Leaving it empty is a deliberate choice: no Reply-To is set and replies bounce. The footer of every notification then carries the line "Replies to this email are not read." — so a subscriber finds out before writing during an outage rather than from the delivery failure afterwards. Set an address and the line disappears.

Through the API: reply_to_email on PATCH /api/v1/statuspage; null clears it again.

Sending through your own mail server (Business)

By default we send notifications from our own mail domain. On the Business plan you can supply your own SMTP server instead, so the mail carries your sender address and your domain signs it.

Credentials are stored once per workspace, under Account → Mail server. The sender address can still be overridden per status page, which matters if you run several brands.

Only admins set up the mail server, in the dashboard and through the API. It carries the mail of every status page in the workspace, so a member who may see only some pages cannot redirect the mail of the others.

You will need from your mail provider: host name, port, encryption (usually STARTTLS on 587), username, password, and a sender address your server is allowed to send from.

Two ways to check it, and why there are two

At the top of the page sit Test connection and Send test email. They answer different questions, and having both saves you guessing:

Through the API both are at POST /api/v1/mail-settings/test; with send_test_mail: true the test message goes to the token owner's address.

The thinking behind it: a misconfiguration almost always fails at the first step — wrong port, expired password, wrong encryption. Being able to establish that without sending anything means you can try as often as you like without filling your inbox or skewing your sending statistics. If the connection succeeds and the test message still does not arrive, the problem is the sender address or delivery — a different corner entirely.

Test connection works with whatever is in the form, so you do not have to save first. Leave the password field empty and we use the stored one — but only for the same server: if you change host, port, user or encryption, enter the password again. That way nobody with edit rights can point the settings at their own server and have your password sent there. On failure we show your server's reply verbatim, because "authentication failed" and "connection refused" point in completely different directions.

We wait at most ten seconds for your server. If it does not answer, that counts as a failure — a mail server that slow in a test is no basis for an outage notification either.

If your server fails, the notification still goes out. We retry; if your server ultimately refuses it, we send through our own servers instead — with our sender address rather than yours. You get an email about it, and the error appears on the settings page. A delivered outage notice from the wrong domain beats no notice at all.

The Send through this server switch can be turned off at any time without losing the credentials.

Two things we refuse, for security:

• Hosts pointing into private networks (127.0.0.1 and similar internal ranges). Checked when you save and before every send.
• The stored password is never handed back — not in the form, not through the API. The API only reports whether one is set.

In the dashboard the Active switch turns your own server off; the details stay stored. Deleting them entirely is done through the API. Through the API: GET, PATCH and DELETE on /api/v1/mail-settings. The connection is always encrypted (encryption: tls or ssl). Omit password to keep the stored one, as long as host, port, username and encryption stay the same; otherwise the API answers 422.