3 AM. My phone buzzes. Not the Uptime Kuma alert I configured — that one went to spam three weeks ago and I never noticed. No, this is a customer emailing to ask why the API has been down for six hours.

That's when I learned — the hard way, obviously — that self-hosted monitoring is only as good as your notification path. Uptime Kuma can watch 50 services. Doesn't matter. If alerts route through your VPS's local sendmail, they're going straight to junk. Gmail sees an email from some random IP with no SPF record and does exactly what it should: treats it as spam.

Here's the fix. By the end of this, you'll have Uptime Kuma sending alerts through JustEmails SMTP — authenticated, DKIM-signed, actually arriving in your inbox.

What We're Building

An Uptime Kuma notification configuration that:

Sends DOWN/UP alerts through authenticated SMTP
Uses your domain (not some @gmail.com or @outlook.com address)
Passes SPF, DKIM, and DMARC checks
Actually lands in your inbox, not spam

If you're also running Grafana or Prometheus, the setup is similar — but Uptime Kuma's SMTP config has some quirks worth covering. For voice alerts on critical outages, VeloCalls can escalate failures to phone calls. Teams using DevOS for project management can integrate alerting into their incident workflows.

Prerequisites

Uptime Kuma installed and running (Docker, bare metal, whatever — the SMTP config is the same)
A JustEmails account with at least one domain configured
DNS access to add SPF/DKIM/DMARC records if you haven't already (JustEmails shows you exactly what to add)
The email address you want alerts sent TO (your inbox, a team alias, wherever)

One thing before we start: if you're running Uptime Kuma on a home network, confirm your ISP doesn't block port 587 outbound. Most don't, but some residential connections block SMTP ports. A quick nc -zv smtp.justemails.app 587 from your server tells you if you're clear.

Step 1: Create a Sending Mailbox

Log into justemails.app and create a mailbox for your alerts. Something like alerts@yourdomain.com or uptime@yourdomain.com.

Why a dedicated mailbox? Isolation. When you inevitably need to rotate passwords because you pasted them somewhere dumb (ask me how I know), you're only touching the alerts account. Not your main inbox.

Write down:

SMTP Host: smtp.justemails.app
Port: 587
Username: The full email address (alerts@yourdomain.com)
Password: The mailbox password

The $49/year plan includes unlimited mailboxes, so creating a dedicated one costs nothing extra. If you're curious how SMTP compares to APIs like SendGrid or Mailgun, our SMTP vs API comparison breaks it down. Short version: for alerting, SMTP is less overhead.

Step 2: Verify DNS Records

Before configuring Uptime Kuma, confirm your domain's DNS records are in place. JustEmails auto-configures DKIM signing on their side, but your DNS needs the matching records for receivers to verify signatures.

In your JustEmails dashboard, go to Domains → your domain → DNS Status. You should see green checkmarks for:

SPF — authorizes JustEmails servers to send for your domain
DKIM — cryptographic signature for message authenticity
DMARC — policy telling receivers what to do with failures

If any are red, click through to see the exact DNS records to add. Propagation can take 5 minutes to 48 hours depending on your registrar and TTL settings. I've had Cloudflare pick up changes in under a minute; GoDaddy has taken most of a day. (GoDaddy's DNS propagation is a special kind of torture. I genuinely don't understand how they're still slow in 2026.)

Don't skip this step. Sending email through an authenticated relay but from a domain without DNS records is still suspicious. The relay is one piece; DNS authentication is the other. For a deeper dive on getting DMARC from monitoring to enforcement, the DMARC enforcement guide covers it.

Step 3: Configure SMTP in Uptime Kuma

Open your Uptime Kuma instance and go to Settings → Notifications → Add Notification.

Select Email (SMTP) as the notification type.

Fill in the fields:

Field	Value
Friendly Name	JustEmails SMTP (or whatever you want)
Hostname	`smtp.justemails.app`
Port	`587`
Security	STARTTLS
Username	`alerts@yourdomain.com` (your full email)
Password	Your mailbox password
From Email	`alerts@yourdomain.com`
To Email	Where you want alerts sent

Important: The "From Email" must be on a domain you've configured in JustEmails. You can't send as alerts@yourdomain.com if yourdomain.com isn't verified. SMTP auth will succeed, but the relay will reject the message.

The "To Email" can be anything — your personal Gmail, a team alias, a ticketing system. Multiple recipients work, comma-separated.

For "Custom Subject", include monitor name and status: [Uptime Kuma] {{NAME}} is {{STATUS}}. Uptime Kuma's template variables ({{NAME}}, {{STATUS}}, {{HOSTNAME}}) work in both subject and body — useful for inbox filtering if you're monitoring 20+ services.

Step 4: Test the Notification

Before you trust this with actual outages, test it.

Click Test in the notification settings. Uptime Kuma will attempt to send a test email.

If it works, you'll see "Sent Successfully" and an email arrives. Open it, view headers, look for:

Authentication-Results: ...
  spf=pass
  dkim=pass
  dmarc=pass

All three should say pass. If DKIM fails, your DNS probably hasn't propagated — wait an hour. If SPF fails, check that your SPF record includes JustEmails' servers.

If the test fails entirely, check the Uptime Kuma logs. Docker:

docker logs uptime-kuma

Look for SMTP errors. The most common ones are covered in the troubleshooting section below.

Step 5: Assign the Notification to Monitors

The notification exists, but it's not attached to any monitors yet.

Go to your monitor list, edit a monitor, scroll to Notifications, and enable the SMTP notification you created.

You can set different behaviors:

Notify on Down — alert when the service goes down (you want this)
Notify on Up — alert when it recovers (optional, can be noisy)
Notify after X retries — wait for N consecutive failures before alerting (reduces flapping)

I usually set: notify on down immediately, notify on up, and 2 retries with 60-second intervals. A service has to be down for ~2 minutes before I get paged, filtering out brief hiccups. Repeat for each monitor, or use "Default Notification" to apply globally.

Honestly, I probably over-engineer my notification rules. But getting woken up at 4 AM because a healthcheck flapped for 30 seconds will do that to you.

Step 6: Verify Production Alerts (Optional but Smart)

Your test email worked. But test emails and actual DOWN alerts take slightly different code paths in Uptime Kuma. I've seen configs where tests work but real alerts fail because of template variable issues.

Quick way to verify: add a monitor for a URL you control and can break. Toggle it off, wait for Uptime Kuma to detect the failure, confirm the email arrives. Or just monitor something flaky and wait.

Common Errors and Fixes

Things break. Always. Here's what I've seen — and what actually fixed them.

"Connection refused" or timeout on port 587

Your server can't reach the SMTP port. Either your ISP/cloud provider blocks it (common on residential connections and some cloud platforms), or there's a firewall rule. Test with nc -zv smtp.justemails.app 587. If it hangs, it's blocked somewhere. Open the port or use a different network path.

"Authentication failed" (535 error)

Wrong username or password. The username must be the full email address — not just the local part. Double-check for trailing whitespace. Just copy it fresh from the dashboard. I've lost 20 minutes to an invisible space character before.

Test sends but real alerts don't arrive

Check the "From Email" field. If it's not on a verified domain, the relay will accept the connection but reject the message. Uptime Kuma doesn't always surface this error clearly — check your JustEmails dashboard for rejected messages.

Emails arrive but in spam

Your DNS records aren't in place or are wrong. Run mail-tester.com — send a test to their address, get a deliverability score. Below 7/10 means there's a DNS issue. Usually a typo in the DKIM record or a missing DMARC policy.

"Certificate error" or TLS handshake failure

Rare, but happens on minimal Docker images. The container lacks CA certificates. On Alpine: apk add --no-cache ca-certificates. On Debian/Ubuntu: apt-get install ca-certificates. Restart the container after.

Advanced: Multiple Notification Channels

Email is reliable but not always urgent enough. For critical production services, I layer notifications: email via JustEmails SMTP for the audit trail, Slack/Discord for team visibility during business hours, and phone/SMS for after-hours critical alerts. Uptime Kuma supports all of these — you can assign multiple notification methods to a single monitor.

Is this overkill for a side project? Probably. But after the 3 AM incident I mentioned earlier, I'd rather have too many alerts than too few.

For tracking uptime across multiple services and correlating with traffic patterns, JustAnalytics integrates status data into broader observability dashboards. ClickzProtect helps filter bot traffic that might skew your availability metrics. For secure browser-based testing of your monitored endpoints, JustBrowser offers isolated sessions without leaving traces.

Next Steps

Uptime Kuma is now sending authenticated alerts. From here:

Set up a status page — Uptime Kuma has a built-in status page feature. Point a subdomain at it for customer self-service
Add maintenance windows — suppress alerts during planned downtime
Monitor your monitors — if Uptime Kuma itself goes down, you won't know. Run a secondary monitor (even a free external service) that pings your Uptime Kuma instance
Consider certificate monitoring — Uptime Kuma can alert before SSL certs expire

If you're running other self-hosted services that need email — GitLab, Gitea, Nextcloud — the SMTP config is similar. For CI/CD pipelines specifically, the GitLab CI SMTP guide covers that setup.

Frequently Asked Questions

Why are my Uptime Kuma email alerts going to spam?

Your alerts are likely sending from an unauthenticated source — either localhost, your server's IP, or a relay without proper DNS records. Email providers see unauthenticated messages as suspicious. Configure Uptime Kuma to send through an SMTP relay with valid SPF, DKIM, and DMARC records for the From domain. JustEmails handles DKIM signing automatically when you route through smtp.justemails.app.

Can I use Gmail SMTP with Uptime Kuma?

Yes, but it's fragile. Google disabled less secure app access in 2022, so you need an App Password. Those break if you change your Google password, enable new 2FA methods, or Google decides your usage looks automated. Dedicated SMTP services avoid the account-tied complexity and give you a proper transactional sending identity separate from your personal email.

What SMTP port should I use for Uptime Kuma?

Port 587 with STARTTLS. Avoid port 25 — most residential and cloud providers block it outbound. Port 465 (implicit TLS) works but 587 is the standard for authenticated submission. In Uptime Kuma's SMTP settings, set Port to 587 and enable Security to STARTTLS.

How do I test if Uptime Kuma SMTP is working?

After saving SMTP settings, click the Test button in Uptime Kuma's notification settings. If it fails, check the Uptime Kuma container logs for the actual SMTP error. Common issues: wrong port, firewall blocking 587, incorrect password, or the From address domain not matching your SMTP account's authorized domains.

Try JustEmails

Unlimited custom domain email hosting for $49/year flat — unlimited domains, unlimited mailboxes, 10 GB storage, full IMAP/SMTP. Built for agencies, freelancers, and anyone managing email across more than one domain.

Start your 7-day free trial → · How it compares

Uptime Kuma Email Alerts: JustEmails SMTP Setup (2026)