Email deliverability reference for IT teams
Sending domains, envelope-from, authentication and gateway guidance for allowing UptimeTwin alerts.
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.
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 | [email protected] | The one that matters. Allow this if you allow nothing else. |
| Auth, security | [email protected] | Password resets, verification, sign-in notices. |
| Billing | [email protected] | Invoices and payment problems. |
| Announcements | [email protected] | Product news and periodic reports. Unsubscribable; never carries alerts. |
| Support replies | [email protected] | 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:
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
[email protected]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.
Related
- Making sure alert emails reach you
- Allowing our checkers through your firewall
- Notification channels
Last updated 2026-09-05