---
title: Email deliverability reference for IT teams
description: Sending domains, envelope-from, authentication and gateway guidance for allowing UptimeTwin alerts.
category: advanced
updated: 2026-09-05
tags: [email, deliverability, allowlist, spf, dkim, dmarc, security]
---

This page is for whoever administers mail security for your organisation. It has
the details a gateway rule needs. If you're an end user, start with
[making sure alert emails reach you](/docs/alerts/email-deliverability).

## Why a mailbox-level rule usually isn't enough

Asking a user to add a safe sender doesn't solve this in most enterprise
environments, for three separate reasons:

- **Safe Senders is a preference layer.** A malware or high-confidence phishing
  verdict quarantines the message regardless of any allowlist entry.
- **Gateway decisions happen first.** Proofpoint, Mimecast, Barracuda and most
  Microsoft 365 tenants apply policy before the mailbox is reached. That needs an
  admin action.
- **Connection-layer rejections happen earlier still.** IP reputation, DMARC
  failure and rate limiting are decided before any content filter runs. No
  allowlist entry rescues a 5xx.

So the reliable fix is a gateway-level rule on the sending identity below.

## What we send from

Each kind of mail has its own subdomain, so you can allow outage alerts without
allowing anything else, and a problem with one stream can't affect another.

| Purpose | From address | Notes |
|---|---|---|
| Outage alerts | `monitor@alerts.uptimetwin.com` | The one that matters. Allow this if you allow nothing else. |
| Auth, security | `security@account.uptimetwin.com` | Password resets, verification, sign-in notices. |
| Billing | `billing@account.uptimetwin.com` | Invoices and payment problems. |
| Announcements | `updates@news.uptimetwin.com` | Product news and periodic reports. Unsubscribable; never carries alerts. |
| Support replies | `support@uptimetwin.com` | Monitored inbox; replies reach a person. |

**Allow by address, not by domain.** Microsoft 365 honors address entries in
situations where it will not honor a domain entry, and a narrower rule is easier to
justify in review.

We do **not** use plus-addressing or VERP in the From header, so an exact-address
match is stable. Per-message correlation data is in the Return-Path, which varies —
don't build rules against it.

## Authentication

Alert mail is authenticated with **SPF and DKIM**, and we publish **DMARC** at
`p=quarantine` (with `sp=quarantine`, so subdomains are covered explicitly rather
than by inheritance).

| Record | Where it lives |
|---|---|
| SPF | Published per sending subdomain — `alerts.`, `account.`, `news.` — and on the apex. Ends in `-all` (hard fail). |
| DKIM | Signed on **every** message. Selectors are published per sending subdomain, and differ by provider. |
| DMARC | `_dmarc.uptimetwin.com` — `p=quarantine; sp=quarantine; adkim=r; aspf=r` |

We deliberately **do not reproduce the literal record values on this page.** They
change when we add or rotate a sending provider, and a copy here would silently go
stale and start contradicting DNS — which is exactly what happened to an earlier
version of this page. Query the records directly; DNS is the only authoritative
source, and it is public:

```bash
dig TXT alerts.uptimetwin.com
dig TXT _dmarc.uptimetwin.com
```

Each sending subdomain publishes its **own** SPF and DKIM records — they do not
inherit from `uptimetwin.com`, so check the subdomain in the From address rather
than the parent.

The `-all` is a hard fail: anything not listed is not us, and you should treat it
accordingly.

**The envelope sender is not the From address.** Each provider signs and bounces on
its own Return-Path subdomain, so the domain SPF that gets evaluated is the one
belonging to whichever provider carried that message. This is normal, it is why
alignment is relaxed (`aspf=r`), and it is the main reason to write rules against
the From address rather than the Return-Path.

## Sending infrastructure

Customer alert mail is carried by two independent commercial providers:

| Provider | Role |
|---|---|
| **Postmark** | Primary. Carries alert, account and announcement mail on separate message streams, so a reputation problem in one stream cannot affect another. |
| **SMTP2GO** | Automatic fallback. Used when Postmark fails, on the same sending identities. |

Both are established senders that manage IP reputation, complaint feedback loops
and suppression handling. Alerts are the mail we least want delayed, so they run on
providers whose entire business is deliverability rather than on anything we host
ourselves.

Failover is automatic and needs no action from you. **The visible sender does not
change between providers** — same From address, same display name, same subject
format. Only the DKIM selector and the bounce domain differ, which is precisely why
a rule written against the From address keeps working across a failover and one
written against the Return-Path does not.

If your policy needs literal sending IP ranges rather than SPF terms, ask support
and we'll send a point-in-time list. We'd rather not publish a copy here that goes
stale — for the same reason the record values above aren't reproduced.

## Suggested gateway rules

- **Microsoft 365 / Defender** — add `monitor@alerts.uptimetwin.com` to the Tenant
  Allow/Block List as an allowed sender, or an anti-spam policy allowed-sender entry.
  A mail-flow rule that sets SCL to −1 for this sender also works; scope it to the
  address, not the domain.
- **Proofpoint** — Safe Sender entry on the address at the org level.
- **Mimecast** — a Permitted Senders policy on the address. Note that Mimecast's URL
  Protection rewrites and pre-fetches links; see below.
- **Barracuda** — allowed sender on the address.

## A note on link scanning

Some of our email contains links — notably the one that confirms a notification
address works. Gateways that pre-fetch URLs, such as Microsoft Safe Links,
Proofpoint URL Defense and Mimecast URL Protection, can follow those links before a
human ever opens the message.

Where that matters is confirmation: a scanner following the link can register as a
confirmation nobody made. We're changing those flows so confirming takes a
deliberate action — a button press or a short code typed into the dashboard —
rather than a link visit. Until that ships, treat a confirmation from a scanned
mailbox with the same suspicion you'd apply to any pre-fetched URL.

You don't need to change anything for this, and we're not asking you to disable
link protection.

## Please don't make email the only path

We tell customers the same thing. Email has more failure points between us and the
mailbox than any other channel we support. If outage alerts matter to your
organisation, pair email with a Microsoft Teams, Google Chat or webhook channel — a
webhook is also the route into Slack, Discord, Telegram or your own tooling. See
[notification channels](/docs/alerts/notification-channels).

## Related

- [Making sure alert emails reach you](/docs/alerts/email-deliverability)
- [Allowing our checkers through your firewall](/docs/advanced/firewall-allowlist)
- [Notification channels](/docs/alerts/notification-channels)