Synology SMTP Alerts and TrueNAS Email Setup That Actually Sends

A pool can sit in DEGRADED for days before anyone notices. Synology SMTP alerts and TrueNAS notifications are only worth anything if they actually leave the box.

A box can try to warn you again and again and still stay silent. Alert emails die on the way out when the SMTP password has rotated, and nothing in the UI surfaces a failed send — no banner, no red dot, just a line in the system log that nobody reads voluntarily.

Often the discovery comes when someone opens the web UI for something unrelated and gets hit with a wall of red.

Here's the thing about NAS alerting: the disk failure isn't the incident. The disk failure is Tuesday. ZFS shrugs, the array keeps serving, and you have days or weeks of slack to swap the drive. The incident is not knowing. And "not knowing" is almost always an email problem, not a storage problem.

So let's fix the email problem. Both boxes, start to finish.

What We're Building

By the end of this you'll have a Synology DSM box, a TrueNAS SCALE box, or both, sending alerts that:

• Authenticate over SMTP with a real username and password
• Come from your own domain instead of noreply@ something you don't control
• Pass SPF, DKIM, and DMARC, so Gmail doesn't quietly file them under junk
• Land in an inbox you actually read

This guide uses JustEmails as the relay — the $49/year plan includes unlimited mailboxes, so a throwaway nas@ address costs nothing extra. The DSM and TrueNAS steps work the same on any authenticated SMTP host; swap the hostname if you relay elsewhere.

Prerequisites

• A Synology running DSM 7.x, or TrueNAS SCALE, or both. Bare metal, VM, whatever — the config lives in the web UI either way.
• A domain you control with DNS access.
• A JustEmails account (or another SMTP provider) with that domain added.
• An inbox to receive the alerts. Personal Gmail is fine. A shared alias is better if more than one person cares about the array.

One pre-flight check before you touch either UI. SSH into the box and run:

nc -zv mail.justemails.app 587

If that hangs, your ISP or firewall is eating outbound SMTP and no amount of UI fiddling helps. Most home connections leave 587 open and block 25. Better to learn that now than after twenty minutes of blaming the password.

Step 1: Create a Dedicated Alerts Mailbox

Log into your JustEmails dashboard and make a mailbox — nas@yourdomain.com, alerts@yourdomain.com, pick your poison.

Don't reuse your personal mailbox for this. The credential ends up parked on an appliance that sits on your LAN and takes firmware updates from a vendor — keep that blast radius small. And when you rotate the password (at 1 AM, while annoyed, probably), you're touching one device instead of your whole mail setup.

Write down four things:

• SMTP host: mail.justemails.app
• Port: 587
• Username: the full address, nas@yourdomain.com — not just nas
• Password: the mailbox password

Mailboxes are unlimited on the $49/year plan, so if you're running three boxes there's a decent argument for three mailboxes. More on that later. The send cap is per account rather than per mailbox, though — counting from when you verify the domain, no more than 50 a day in the first week, 200 in the second, and up to 500 from day 15, with mailbox sends and API sends drawing on the same allowance — so three mailboxes share one daily budget.

Copy the password from your password manager rather than retyping it. Retyping is where typos come from.

Step 2: Confirm DNS Is Actually Green

Skip this and you'll get mail that sends successfully and lands in spam, which is somehow worse than mail that fails loudly.

In the dashboard, open your domain's DNS check. You want SPF, DKIM, and DMARC showing as configured. JustEmails auto-generates the SPF, DKIM, DMARC, and MTA-STS records for you; your registrar still has to actually serve them. If anything's red, the dashboard hands you the exact records to paste.

Propagation is a coin flip. Some DNS hosts pick up changes in under a minute; others take most of a working day, which is a special kind of tedium. Once the records are live, the DMARC enforcement guide covers moving from monitoring to p=reject without nuking your own mail.

Step 3: Synology SMTP Alerts in DSM

Open Control Panel → Notification → Email.

Tick Enable email notifications. Then, in the service provider dropdown, choose Custom SMTP server. DSM offers webmail presets such as Gmail right there, and they're a trap: they hang your infrastructure alerts on a personal account's credentials and security settings.

Fill it in:

Two fields cause most of the pain. Username must be the full email address — DSM accepts nas and then fails auth with a message that tells you nothing. And keep the sender address on your verified domain: point it at your Gmail while authenticating as nas@yourdomain.com and the login can succeed while the message is refused or junked, with DSM reporting a generic failure at best.

Which is its own small insult, by the way. An SMTP rejection comes with a reply code and a reason, and DSM decides you don't need to see it, so you're left guessing at a problem the box already knows the answer to.

Hit Send a test email before you leave the page.

Now switch to the Advanced tab. This is where you choose which events actually generate mail: Storage, Hardware & Power, External Devices, File Sharing, System, Package Center, Security. Turn on Storage and Hardware & Power at minimum — that's degraded volumes, SMART warnings, fan failures, UPS events, overheating.

Turn off Package Center notifications. I'm serious about this one. A NAS that emails you every time a package auto-updates trains you to archive its mail without reading it, and then the disk failure email arrives and gets the same reflex.

Step 4: TrueNAS SMTP Alerts in SCALE

SCALE has moved this panel around across releases. If the path below doesn't match your build, type "email" into the UI search bar.

As of the 24.10 line: System Settings → General → Email.

Set Send Mail Method to SMTP (not GMail OAuth — that's the same App Password fragility wearing a nicer coat). Then:

• From Email: nas@yourdomain.com
• From Name: something identifying, like truenas-01
• Outgoing Mail Server: mail.justemails.app
• Mail Server Port: 587
• Security: TLS (this is STARTTLS on 587)
• SMTP Authentication: enabled, with the full address as username

Click SEND TEST MAIL. It should land in a few seconds.

And now the part that costs people an afternoon.

TrueNAS delivers alerts to the email address on your admin user account, not to the From address. Go to Credentials → Local Users, edit truenas_admin (or root on older installs), and put your real inbox in the Email field. If that box is empty, alerts have no default address to go to.

I'll die on this hill: that's a bad default. The single field deciding whether alerting works at all sits three menus away from the alerting config.

Then head to System Settings → Alert Settings. Two things live here:

1. Alert Services — confirm an Email service exists and is enabled. Set its minimum level to WARNING or CRITICAL.
2. Per-alert tuning — every alert class has its own level and frequency. Pool state, SMART, ZFS scrub results, and UPS should be CRITICAL. Certificate expiry and update availability can drop to INFO or off entirely.

This granularity is genuinely better than what DSM gives you. Credit where it's due.

Step 5: Break Something On Purpose

A test email proves your SMTP config works. It doesn't prove your alert pipeline works — different code path, different recipient resolution, and on TrueNAS an entirely different delivery mechanism.

Cheapest real test: on TrueNAS, start a manual scrub with the scrub-finished alert set to WARNING. On Synology, run a S.M.A.R.T. quick test from Storage Manager. Both fire a real event down the real path.

Feeling thorough? Pull a drive from a redundant array and wait. Five minutes of adrenaline, and the only way to prove the whole chain.

Common Errors and How to Fix Them

"Authentication failed" / 535

Ninety percent of the time it's the username missing the domain part. The rest is a trailing space from a paste. Retype it by hand once before you go debugging anything else.

Connection times out on 587

Blocked outbound. Test with nc -zv mail.justemails.app 587 from the box itself, not your laptop — the NAS may sit on a VLAN with different egress rules than you think. Unsure which port you even want? The port breakdown covers 25, 465, 587, and 993.

TLS handshake failure

Usually a stale CA bundle on an out-of-date release. Update the system, then retry.

Test mail arrives, real alerts don't

On TrueNAS: no Email alert service is enabled, its level is set above the alerts that fire, or the admin user's Email field is empty. On Synology: your Advanced tab has the relevant event category switched off. Check both before assuming the relay is at fault.

Mail arrives but lands in spam

DNS. Send a message to mail-tester.com from the NAS and read the score. Under 7/10 usually means a DKIM typo or a missing DMARC record.

Alerts stop after months of working

Password rotated, or the mailbox filled up. Neither box will tell you. That is how a pool ends up DEGRADED for days — the same failure mode that hits cron jobs relaying through SMTP, where the script keeps running and the mail keeps not arriving.

Advanced: One Mailbox Per Box

If you run more than one NAS, give each its own sending mailbox — nas-basement@, nas-office@, whatever. Costs nothing since mailboxes are unlimited, and inbox filtering gets trivial: one rule per sender, one label per machine.

For a household or small team, add recipients as plain addresses in the recipient field. You only need actual team members on the account ($2/member/month, prorated) when someone else has to log into the mail dashboard itself. Receiving alerts doesn't require a seat.

Running scripts on the box that also send — backup wrappers, ZFS report jobs? Same mailbox, same port. Or use the API instead; the plan includes 1,000 transactional emails a month. For a shell script that fires twice a day, honestly, SMTP is less to maintain.

Next Steps

Alerts are flowing. A few things worth doing next:

• Add an external heartbeat. Your NAS can't email you that it's dead. Something outside the house has to notice the silence — JustAnalytics handles uptime checks.
• Escalate the critical ones. Email is fine for degraded. For "pool is FAULTED at 3 AM", a phone call cuts through in a way an inbox doesn't.
• Wire up the rest of the homelab. If you're already running uptime monitoring, the Uptime Kuma SMTP guide uses the same mailbox and the same port.
• Write down the credential. In your password manager, tagged with which devices use it. Future you, mid-rotation, will be grateful.
• Kill the noisy alert categories. Ruthlessly.

This setup isn't perfect. Neither DSM nor TrueNAS gives you a visible indicator that your last alert failed to send, which is the one feature that would catch a silent failure early. Until that exists, a quarterly test email is the closest thing to a safety net.

Frequently Asked Questions

What SMTP settings should I use for Synology DSM?

In Control Panel → Notification → Email, pick Custom SMTP server rather than a webmail preset such as Gmail. Set the server to mail.justemails.app, port 587, tick the secure connection option, enable SMTP authentication, and use your full mailbox address as the username. Keep the sender address on a domain you've verified; a From address on another domain can pass the login and still be refused or junked.

Why do my Synology email alerts stop working after I change my Google password?

Usually because DSM was sending through Gmail with a Google App Password, and Google revokes App Passwords when the account password changes. The NAS keeps the old credential and quietly fails every send. A dedicated SMTP mailbox on your own domain isn't tied to your personal Google account, so password hygiene on one doesn't silently break the other.

Why does TrueNAS say the test email succeeded but no alerts arrive?

The test only proves the SMTP settings work. Real alerts go through an alert service, addressed by default to the email on your admin user account. Confirm an Email alert service exists and is enabled under System Settings → Alert Settings with a level the alerts actually reach, and that Credentials → Local Users → truenas_admin has your inbox in its Email field.

Should I use port 25, 465, or 587 for NAS alerts?

Use 587 with STARTTLS. Port 25 is blocked outbound on most residential ISPs and plenty of cloud networks, so a NAS sitting behind a home connection usually can't reach it at all. Port 465 is not an option against mail.justemails.app — JustEmails publishes 587 only, so a NAS configured for implicit TLS on 465 will report a connection failure or simply time out, even though every credential is right.

---

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