Uptime Kuma Email Alerts: JustEmails SMTP Setup (2026)

Picture 3 AM. A customer emails to ask why the API has been down for six hours. The Uptime Kuma alert was configured, but it had gone to spam three weeks earlier, and nobody noticed.

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 — the numbers on unauthenticated senders suggest that's the rule, not the exception. 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.

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 mail.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, you're only touching the alerts account. Not your main inbox. The same reasoning applies to app-generated mail — Django's verification and reset mail deserves its own mailbox rather than sharing this one.

Write down:

• SMTP Host: mail.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. Outbound volume is the finite part: 20 emails/day in an account's first week, 200/day in the second, and 500/day from day 15 on, measured across the whole account rather than per mailbox. Sixty monitors that all flap and recover overnight can reach that, so pick your retry intervals with the figure in view. 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. If SPF, DKIM, and DMARC are still unfamiliar acronyms, the JustEmails security glossary defines each one without the RFC-speak.

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. Cloudflare can pick up changes in under a minute; GoDaddy can take most of a day.

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:

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)

A sensible setup is to notify on down immediately, notify on up, and use 2 retries with 60-second intervals. A service then has to be down for about 2 minutes before anyone gets paged, which filters out brief hiccups. Repeat for each monitor, or use "Default Notification" to apply globally.

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. Some configs pass tests but fail on real alerts 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 commonly goes wrong, and how to fix it.

"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 mail.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.

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, layering notifications works well: 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 an incident like the 3 AM one above, too many alerts beat 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.

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.

Same story for anything that fires mail from a trigger rather than a person: self-hosted database automations in Baserow or NocoDB point at the same host and port, just from a webhook instead of a monitor check.

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 mail.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 is not an option against mail.justemails.app: JustEmails publishes 587 only, so a 465 config produces a connection that hangs rather than an error you can read. In Uptime Kuma's SMTP settings, set Port to 587 and 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