You can have the best monitoring in the world, but if the alerts land nowhere a human reads, you might as well not have configured it. Email remains the most universally-understood notification channel — every team member has an inbox, every inbox speaks SMTP, and every production incident runbook assumes email notification works. This guide walks through setting up reliable email alerts in Uptime Kuma for UK teams, covering Gmail, Microsoft 365 and self-hosted SMTP, plus the deliverability concerns that separate alerts that arrive in seconds from alerts that get quietly filtered into spam. If you are brand new to Uptime Kuma, start with our plain-English introduction.
Why email is still the default channel
Uptime Kuma ships with 91 notification channel types in the current 2.x line. Slack, Microsoft Teams, Discord, Telegram, PagerDuty, Opsgenie — the list is long and well-populated. And yet, for most UK teams just getting started, email is the right first choice. Three reasons.
Universal reach. Everyone on the team has an email address. You do not need to enrol them in a chat workspace, issue tokens, or agree a notification app. A working email address is the lowest common denominator.
Durability. Email messages stay in an inbox until read. Chat notifications scroll past, get silenced during the weekend, or vanish into "do not disturb". An email from 3am Saturday is still sitting at the top of the inbox on Monday morning, which matters if that is when you start dealing with the weekend's incidents.
Forwarding and archival. Email integrates with every escalation process, ticketing system and audit regime known to UK IT. A notification email can be auto-forwarded, filtered, turned into a JIRA ticket, or archived for compliance purposes without any special integration work.
None of this means you should only use email. Chat and paging tools have their place for team-scale urgency. But start with email, get it reliably working, and layer other channels on top. For the broader question of how to route alerts intelligently across channels without drowning the team, see our notification strategy guide.
The SMTP basics you need
SMTP — Simple Mail Transfer Protocol — is the language email servers speak when relaying messages. To send email from Uptime Kuma you need five pieces of information about an SMTP server that is willing to accept your messages.
- Hostname: the SMTP server's address, for example
smtp.gmail.com,smtp.office365.com, or your own mail server. - Port: usually 465 or 587. More on this below.
- Encryption: TLS (also called STARTTLS) or SSL (also called "implicit TLS"). The hostname and port together usually dictate which.
- Username and password: credentials for an account authorised to send mail. For major providers, this is usually an app-specific password rather than the normal account password.
- From address: the envelope sender shown on outgoing messages. This is often — but not always — the same as the account username.
In Uptime Kuma, you configure all of this under Settings → Notifications → Add New Notification, selecting SMTP as the type. The form is straightforward; the difficulty is almost always in obtaining correct values for the five fields above from your email provider.
Setting up Gmail with an app password
Gmail is the most common first choice for small UK teams. Since Google disabled "less secure app access" several years ago, you cannot use your normal Gmail password directly — you need an app password, generated from Google Account security settings.
The sequence:
- Enable two-factor authentication on the Google account if it is not already on. App passwords are only available for accounts with 2FA.
- Go to Google Account → Security → App passwords. Generate a new password, labelling it something memorable like "Uptime Kuma SMTP".
- Copy the 16-character app password immediately; Google will not show it again.
- In Uptime Kuma, add an SMTP notification with hostname
smtp.gmail.com, port 465, encryption SSL, username your full Gmail address, password the 16-character app password, from address your Gmail address. - Send a test notification. A message should arrive in your inbox within seconds.
Common trip-up: Gmail's app-password page only appears if 2FA is enabled. If you cannot find it, enable 2FA first and the option reappears. For teams on Google Workspace, some domains have app passwords disabled as a policy — in that case, use OAuth 2.0 or the Google Workspace relay rather than direct SMTP.
A quick reliability note on Gmail: a single Gmail account has a daily send limit of about 500 messages for personal accounts and 2,000 for Workspace. Those limits are enormous compared with what any monitoring setup should produce, but if you suddenly hit them you almost certainly have an alert-fatigue problem and a monitor that is flapping, not a Gmail problem. Raise the failure threshold on the noisy monitor and the Gmail warning resolves itself.
Microsoft 365 SMTP
Microsoft 365 (formerly Office 365) is the most common business email platform in the UK. Setup is slightly more involved than Gmail because Microsoft has been tightening SMTP authentication over several years.
The working 2026 setup:
- Hostname:
smtp.office365.com - Port: 587
- Encryption: TLS (STARTTLS)
- Username: the full UPN ([email protected] or [email protected])
- Password: an app password generated in Microsoft Account security settings, or an OAuth 2.0 credential if the tenant requires it
- From address: must match the authenticating account — Microsoft rejects mismatched from addresses more aggressively than Google does
Two additional considerations specific to Microsoft 365. First, Microsoft has been progressively disabling basic SMTP authentication in new tenants. If SMTP AUTH is disabled tenant-wide, you need a global admin to enable it for the mailbox used for Uptime Kuma, or move to OAuth 2.0. Second, Microsoft applies sending limits per mailbox — 10,000 messages per day for most plans — which is far above what any Uptime Kuma deployment produces, but worth knowing about.
Third consideration: a dedicated mailbox for alerts is strongly recommended. Do not use a person's mailbox as the SMTP account — when they leave, the alerts stop. A service mailbox like [email protected] is easier to manage, easier to audit, and easier to hand over. The same account also serves well for the From address, so that alert recipients know exactly which system sent the message.
Self-hosted and custom SMTP servers
Teams running their own mail server, or using a transactional email provider (Mailgun, SendGrid, Postmark, SparkPost), configure those as custom SMTP hosts. The exact hostname, port and authentication mechanism are specific to the provider, but the fields Uptime Kuma asks for are the same.
A few points worth flagging.
Transactional email providers are often the best choice. Mailgun and similar services are designed for automated notification volume and give you deliverability advantages — dedicated IP reputation, automatic bounce handling, DKIM signing — that general-purpose mail providers do not. For teams sending more than a handful of alerts a day, a transactional provider is worth the £15-30/month.
Self-hosted Postfix or similar. If you already operate an SMTP server for legitimate business reasons, relaying monitoring alerts through it is straightforward. The one caveat: the machine running Uptime Kuma must be allowed to relay through the SMTP server, which typically means adding its IP address to the server's mynetworks or equivalent configuration.
Sending from a non-existent domain is asking for trouble. A custom SMTP setup using a from-address domain that you do not actually own will be blocked or filtered by most receiving servers. Always use a real domain you control, with real DNS records.
Keep monitor credentials separate from application credentials. Where possible, the SMTP account Uptime Kuma uses should be dedicated to monitoring and nothing else. If the account is ever compromised — via a leaked Uptime Kuma backup or similar — the damage is limited to somebody being able to send email as that specific service account, rather than every alert destination your organisation uses.
A managed Uptime Kuma plan on smartxhosting.uk gives you a fresh Uptime Kuma instance on UK infrastructure. You log in, create the admin account and configure the SMTP notification with your own mail provider's credentials just as described above. The application is the standard Uptime Kuma release — you provide the SMTP account, the provider handles the platform underneath.
Ports 25, 465 and 587 — which to use
The SMTP ecosystem has three main ports, each with a specific purpose, and it is worth knowing which to pick.
Port 25 is the original SMTP port for server-to-server relay. Many ISPs and cloud providers block outgoing traffic on port 25 to limit spam. Do not use port 25 for Uptime Kuma authenticated sending — it is almost always the wrong choice in 2026.
Port 587 is the modern SMTP submission port. It expects authenticated clients to connect and upgrade the connection to TLS using STARTTLS. This is the default for most authenticated SMTP relay. Pick 587 unless the provider specifically tells you otherwise.
Port 465 is SMTP over implicit TLS — the connection starts encrypted, no STARTTLS negotiation. Gmail prefers 465 (with encryption set to SSL in the Uptime Kuma UI). Some transactional providers also expose 465 for clients that prefer it.
If an alert never arrives and a test sends return TLS errors, the most common cause is port/encryption mismatch: port 465 with TLS set to STARTTLS fails, port 587 with SSL set fails. Match the port to the encryption model the provider documents.
Message template personalisation
Uptime Kuma's default email template is serviceable but terse — monitor name, status, timestamp. If you want more information in the alert email, Uptime Kuma 2.x supports custom templates for the subject line and body, with placeholders for monitor details, status change, time, ping and hostname.
Useful customisations:
- Include monitor tags in the subject. If you tag monitors by environment (production, staging) or team ownership, surfacing those tags in the subject line makes triage quicker.
- Include the monitor URL in the body. Saves a click during incident response.
- Include last-known latency. Sometimes the signal you want is not "down" but "slow in a specific way".
- Include a runbook link. For monitors that correspond to specific services, a stable link to a runbook or internal documentation lets whoever receives the alert start work immediately.
Keep the template plain-text. HTML-heavy alert emails look fine on the first inbox they land in but frequently render badly on secondary inboxes — mobile clients, archival inboxes, ticketing systems that parse and re-render. Plain text is the format every receiving system handles cleanly.
One final customisation worth mentioning: the reply-to header. If alerts are received by multiple people, setting a reply-to address that lands in a shared inbox (or a no-reply address) prevents the awkward situation where one recipient replies to an alert and only they see the reply. Many UK teams default to a no-reply address to signal that replies should go to the ticketing system, not the automated alert pipe.
SPF, DKIM and staying out of spam
The single most common source of "Uptime Kuma is sending alerts but I never see them" is not an Uptime Kuma problem — it is deliverability. The receiving mail server marked the alert as spam and filed it in a folder the recipient does not check.
Three DNS records determine most of your deliverability outcome.
SPF (Sender Policy Framework). A TXT record at your domain that lists the mail servers authorised to send on your behalf. If you send Uptime Kuma alerts from [email protected] but your SPF record does not include the IP or include directive for the SMTP server you are using, receiving servers apply suspicion to the message.
DKIM (DomainKeys Identified Mail). A cryptographic signature your SMTP server adds to outgoing mail, which receiving servers verify against a public key published in your DNS. DKIM is now effectively mandatory for reliable delivery to Gmail, Microsoft 365 and most UK business inboxes.
DMARC (Domain-based Message Authentication, Reporting and Conformance). A policy record that tells receivers what to do with messages that fail SPF or DKIM. Even a permissive DMARC record (p=none) measurably improves deliverability because it signals that you care about email authentication.
Configuring these is outside the scope of Uptime Kuma itself — they are DNS records at your domain registrar or DNS provider. But without them, Uptime Kuma's alerts will arrive unreliably. If you are configuring a full monitoring setup, spend an hour getting SPF, DKIM and DMARC right once — the deliverability improvement is permanent.
Monitoring of the alert-sending domain itself can also be worthwhile. A DNS monitor on the SPF and DMARC TXT records catches the case where those records are accidentally changed or removed. For details see our DNS monitoring guide.
Troubleshooting
The common SMTP problems and how to diagnose them.
"Test notification succeeded but no email arrives." Almost always deliverability. Check the Spam folder first. Then check the mail server logs on the SMTP side to confirm the message was accepted. If the logs show delivery with a successful handoff to the recipient server, the message is somewhere in the recipient's system. If the handoff was rejected, the message was bounced — look at the bounce report.
"Authentication failed." The username or password is wrong. For Gmail and Microsoft 365, double-check you are using an app password rather than the normal account password. Re-paste carefully — a leading or trailing space in the password field is a common mistake.
"TLS handshake failed" / "SSL error." Port and encryption mismatch. Check the provider's documentation for the correct pairing: 587 + TLS/STARTTLS, 465 + SSL/implicit.
"Connection timed out." Outgoing SMTP is blocked on the network where Uptime Kuma is running, or the SMTP host is behind a firewall you cannot reach. Try a different provider or run Uptime Kuma from a network with outgoing SMTP allowed.
"Alerts are arriving but delayed by minutes." The SMTP provider is queuing them, usually because of rate-limiting or deliverability concerns. A transactional provider like Mailgun or SendGrid will almost always deliver faster than relaying through Gmail or Microsoft 365 for an automated system.
"Alerts work for some recipients but not others." Receiving-server-specific deliverability filter. The most common culprit is a corporate Exchange Online Protection rule blocking messages that do not pass SPF and DKIM strictly. Fix authentication at your end.
Once email notifications are working, it is worth thinking about how to route different severities to different channels — our alert fatigue guide walks through strategies that prevent the team from tuning out. And if you want to put a specific monitor behind a different notification channel — say Slack for engineering and email for the business team — see our Slack and Teams alerts guide.
Summary
Email remains the most reliable and universally-understood notification channel for UK monitoring setups. Getting Uptime Kuma's SMTP integration working takes ten minutes for Gmail or Microsoft 365 with an app password; another half-hour gets you deliverability-grade DNS records that keep alerts out of spam; a custom SMTP provider or transactional email service is worth considering if you send more than a handful of alerts a day or if your own mail infrastructure is not reliable enough for automated notification volume.
Once email works, you can layer other channels on top — team chat for group-scale visibility, SMS or pager integrations for out-of-hours escalation, webhooks for custom integrations. But start with email, verify it end-to-end, and confirm the message really does arrive in the right inbox. The rest becomes much easier when that foundation is in place.