1. What the failure actually looks like

"Email alerts don't work" covers at least four different failures, and they have different fixes. Before changing anything, identify which one you have.

Write down which row you are in. Everything below is organized around that. If you skip this step you will end up changing working settings while the real fault sits untouched — the most common way a twenty-minute job turns into an afternoon.

2. The two-layer model (this is the whole mental model)

Dahua splits email alerting into two configuration surfaces that live in different parts of the web interface, and neither one works without the other.

Layer one — transport. Under Settings > Network Settings > Email, you give the camera a mail account to send from: SMTP server address, port, username, password, sender address and encryption type. This is a dumb pipe. It knows nothing about alarms.

Layer two — trigger. Under the Alarm area, you add an Email action to a specific event's linkage (+Event Linkage). This tells the camera: when this event fires, this action runs.

The manual is explicit that "email linkage takes effect only when SMTP is configured." The reverse is equally true and less obvious: a perfectly configured SMTP account sends nothing unless an event has an Email action attached. Engineers routinely configure the mailbox, assume the camera will now email about everything, and get silence.

3. Layer one: configuring SMTP correctly

Open Settings > Network Settings > Email, enable the function with the toggle, then fill in the fields. The manual lists them in a fixed order, and each one has a specific failure mode.

Two details in that table deserve emphasis because they account for a large share of support tickets.

The Test button is hidden until you enter a receiver. The manual notes that after entering the receiver's address, a Test button is displayed. If you have been staring at the page wondering where the test function is, that is why. Type a receiver first, then test. This is also the fastest way to separate layer-one from layer-two faults.

Attachment is a separate switch from "send an email." By default the camera will send a notification with no image. If the client expects a snapshot in every alert, you must enable the attachment checkbox, and if you want three images, select that option and set the interval between them. A surprising number of "the alerts have no picture" tickets are simply this checkbox.

4. Provider settings that actually work

The manual documents Gmail explicitly: smtp.gmail.com, SSL on 465 or TLS on 587, and a note that you must enable SMTP service in your mailbox. In practice, "enable SMTP service" now means generating an app password, because Google no longer accepts plain account passwords for SMTP.

For a camera deployment, do not use a personal mailbox. Create a dedicated service account — something like camera-alerts@yourdomain.com — with its own app password. This keeps alerts out of a human inbox, makes it trivial to revoke access when a camera is decommissioned, and avoids the situation where an employee changes their password and silently breaks every camera on site.

5. Layer two: attaching Email to an event

With transport proven, go to the alarm configuration. The manual's flow is: open the Alarm page, click +Event Linkage, and select Email from the drop-down. That is the entire trigger configuration — but three conditions have to be true for it to fire.

Condition one: the event itself must be enabled. The manual's alarm-type table lists a "preparation" column for exactly this reason. Motion detection alerts require motion detection to be enabled. Video tampering alerts require tampering detection. AI event alerts require the relevant intelligent rule to be armed. If the source event never fires, no linkage can run.

Condition two: the linkage schedule must cover the moment. Alarm linkages carry a schedule. A linkage configured for 18:00–06:00 will do absolutely nothing during a daytime test — and this is a genuinely common false alarm during commissioning, because the installer tests at 10 a.m.

Condition three: only one action per event behaves as expected if you have not saved. After adding the linkage, apply the change. It is easy to add the action, navigate away to check something, and lose it.

6. The twelve causes, in the order to check them

This list is ordered by observed frequency, not by severity. Work down it and stop at the first hit.

1. Port and encryption mismatch. SSL expects an implicit TLS connection, usually 465. TLS means STARTTLS, usually 587. Pairing them wrongly produces a connection that opens and then dies mid-handshake, which looks like a wrong password.

2. Using the account password instead of an app password. With 2FA enabled, Gmail and Microsoft reject the normal password. The camera shows a generic authentication failure, so people retype the same password and get the same result.

3. SMTP AUTH disabled on the mailbox. Microsoft 365 tenants often have SMTP AUTH off by default at the tenant or mailbox level. The credentials are correct and still fail.

4. ISP or firewall blocking the outbound port. Many consumer ISPs block 25, and some block 465/587 on business circuits without a request. Test from a laptop on the same VLAN before blaming the camera.

5. The camera has no working DNS. An SMTP server entered as a hostname needs DNS. If the camera's DNS field is empty or points at a dead resolver, name resolution fails while ping to the gateway succeeds.

6. Sender address does not match the authenticated account. Many providers rewrite or reject mail whose From does not align with the authenticated user. Use the same address for Username and Sender.

7. The receiver limit. Three addresses maximum. A fourth is silently not used. If a customer insists four people must be notified, use a distribution list or an alias on the mail server.

8. No email linkage on the event. Transport works, the event fires, nothing is attached to it. This is the classic "Test works but alerts don't" case.

9. Linkage schedule does not cover the test window. Covered above. Set 24/7 while commissioning.

10. The source event is not enabled or not armed. Motion detection off, IVS rule not drawn, tampering detection disabled. The linkage is fine and never gets a trigger.

11. Attachment expectations. The alert arrives but has no image because Attachment is unchecked, or because three-image mode was selected with an interval longer than the event.

12. Receiver-side filtering. The mail is sent and lands in spam, quarantine, or a rule-based folder. Check the sending account's Sent folder and the mail server logs before concluding the camera failed. If the camera's subject line is generic and the sending domain is unfamiliar, corporate filters will treat it as bulk mail.

6.1 How to prove where the chain stopped

Guessing is expensive. There are four observation points in the alert chain, and each one tells you something different. Use them in this order.

Observation point one: the Test button. It exercises transport only. Success proves the camera can reach the SMTP server, authenticate, and hand off a message. It says nothing about events.

Observation point two: the sending account's Sent folder. Log in to the service mailbox in a browser. If the camera sent something, it appears there. This distinguishes "the camera never sent" from "the mail server accepted it and the receiver's side dropped it". Without this step people spend hours on the camera when the problem is a spam rule.

Observation point three: the camera's own log. The web interface keeps an event and operation log. After a deliberate event, check whether the event was recorded at all. If the log shows no event, the detection layer is not firing and the linkage never had a chance. If the log shows the event but no email action, the linkage or schedule is at fault.

Observation point four: the receiving mailbox and its quarantine. Check spam, quarantine and any rules that file messages automatically. A subject line containing "alarm" or "motion" trips a surprising number of corporate filters.

That table resolves almost every case in under ten minutes, and it prevents the most expensive mistake in troubleshooting: changing a working component because it was easier to reach than the broken one.

6.2 Three patterns we see most often

Pattern A — the successful test, the silent camera. An installer sets up Gmail, tests successfully, ticks the attachment box, and leaves. A week later the client reports no alerts. The SMTP layer was never the problem: no Email action was ever attached to the motion rule. The fix takes two minutes once you stop looking at the mail settings.

Pattern B — the alert that only works at night. A site reports that alerts "mostly work but not in the morning". The linkage schedule is 18:00–06:00 because someone reused a recording schedule. Nothing is broken; the schedule simply does what it says. This is the single most common "intermittent" email bug on commercial sites.

Pattern C — the mail that stopped after an unrelated change. Everything worked for months, then stopped. Usually one of three things happened: the sending account's password was rotated, the site's ISP changed the router and the camera lost its DNS entry, or the office migrated to a new mail provider. In all three cases the camera configuration looks untouched, which is why nobody suspects it.

Patterns B and C share a lesson: alerts are a chain of dependencies, and any link can be changed by someone who has no idea the chain exists. Document the sending account, the SMTP host and the linkage schedule in the handover pack. When something stops working eighteen months later, that page saves an entire service visit.

7. Using Health Mail as a canary

The Email page includes a Health Mail option: enable it, set a sending interval, and the camera mails a test message on that schedule. This is the single most useful diagnostic in the whole feature set, and it is underused.

Enable Health Mail at a short interval — say every ten minutes — and leave it overnight. Three outcomes tell you three different things:

• All health mails arrive. Transport is stable. Any missing alarm is a layer-two problem. Stop debugging SMTP.
• Health mails arrive irregularly. Transport is flaky: DNS, intermittent WAN, or a provider throttling the account. This is why alarms "sometimes" work.
• No health mails at all. Transport is broken. Use the Test button with a receiver entered, then work through causes 1–6.

Turn Health Mail off when you are done. Leaving it running in production generates a steady trickle of mail that trains everyone to ignore camera alerts — which defeats the purpose of having them.

8. A commissioning checklist you can hand to an installer

The following sequence takes about fifteen minutes and eliminates almost every failure mode. It is written to be followed literally, in order, because the order matters: each step proves something the next step depends on.

If you run this sequence in order, you will never again spend an afternoon changing SMTP settings that were already correct.

9. What to do when the customer's IT department owns the mail server

In commercial deployments the camera rarely talks to Gmail. It talks to a corporate relay, and the relay has opinions. Expect to need three things from IT, and ask for all three at once so you do not make three trips.

An SMTP relay hostname and port. Confirm whether it expects implicit TLS (usually 465) or STARTTLS (usually 587), and whether port 25 is available for internal relay. Do not assume; relay configurations vary more than provider configurations do.

A service account with SMTP AUTH permission. Some relays accept mail from any internal IP without authentication, others require it. Ask which model they run. If authentication is required, get the username format — it may be DOMAIN\user rather than an email address, and the camera will accept whatever you type, so a wrong format fails silently at the server.

IP allowlisting if the relay uses it. If the camera is on a site with a dynamic WAN address, allowlisting by IP is fragile. Ask for authentication instead, or reserve a static address for that circuit.

One more consideration: if the site has multiple cameras, configure one completely, verify it, then clone the configuration to the rest. Dahua web interfaces support exporting and importing configuration on many models; where they do not, reproduce the exact same fields rather than "similar" ones. A single mismatched character in a relay hostname produces hours of confusion across a fleet.

9.1 NAT, VLANs and outbound rules

Cameras usually sit on a dedicated surveillance VLAN, and that VLAN is often more restricted than anyone remembers. Three network facts determine whether SMTP can work at all.

The camera needs a default gateway. Without one, it can reach devices on its own subnet and nothing else. A camera that responds to ping from the NVR but cannot reach an internet mail server is a gateway problem, not a password problem.

The camera needs a working DNS server. SMTP hosts are entered as names. If DNS is empty, inherited from a DHCP scope that no longer exists, or pointed at a decommissioned internal resolver, name resolution fails before any mail protocol begins. Entering an IP address in the SMTP field sometimes appears to work, but it breaks silently when the provider changes addresses — and it defeats TLS certificate validation, which expects a matching hostname.

The outbound port must be permitted. Firewalls frequently allow 443 and block everything else. If the site's rule set permits only web traffic, SMTP on 465 or 587 will fail while the camera's own web interface works perfectly from the same subnet — a confusing combination that sends people hunting for a wrong password.

Test the path from a laptop on the same VLAN before touching the camera: open a command prompt and try a raw connection to the SMTP host on the chosen port. If that fails from a laptop, it will fail from the camera, and no amount of camera configuration will change it. If it succeeds from the laptop but fails from the camera, compare the two devices' gateway, DNS and subnet mask. The difference is always in those three fields.

10. If email simply will not work, use a different action

Email is not the only alarm action, and for some sites it is the wrong one. The same +Event Linkage menu offers alternatives that do not depend on an SMTP account at all.

Send Command. The camera posts alarm information to a server you define, with its own server configuration, optional HTTPS and optional authentication. If the customer already runs a VMS or an integration service, this is more reliable than email and easier to audit.

Record and Snapshot linkage. Write the event to the SD card and capture a still. Even if notifications fail, evidence exists locally. For sites where the alarm matters legally, recording is the primary control and notification is secondary.

Alarm-out. Drive a physical output to a siren, strobe or relay. No mail server, no spam filter, no app password.

Platform access and push. If the site uses a mobile app or a cloud platform, push notification often works where SMTP does not, because it uses an outbound connection the camera already maintains.

A practical architecture for most small commercial sites is: record locally, push to the app for the day-to-day, and use email as a secondary channel for the person who does not check the app. If email breaks, nothing critical is lost.

10.1 What the alert email actually contains

Knowing the payload helps you decide whether email is the right channel at all — and it explains several complaints that are not bugs.

The camera composes a short message using the subject you configured, the alarm type that fired, and the device's own identification. The subject is capped at 63 characters and supports up to two title parts, which is why installers often combine a site name with an event name and then run out of room for the camera identifier.

If the attachment option is enabled, one image is included by default. The three-image option sends three stills spaced by the interval you set. That interval matters operationally: three frames one second apart document a person crossing a line, while three frames thirty seconds apart document a vehicle leaving a gate. Choose based on what the customer actually needs to see, not on the maximum.

What the email does not contain is equally important. It is not a continuous clip, it does not include a link back to the recorder, and it does not carry a structured payload an automation system can parse. If the requirement is "open the footage from the notification", email is the wrong transport — use platform push or a VMS integration instead. Email is a notification channel, not an evidence channel. Evidence lives on the SD card or the recorder, and that is where the recording linkage matters.

11. Security notes worth ten seconds of your time

Never use an administrator's personal mailbox. The password sits in the camera's configuration and is visible to anyone who can log in as admin. A dedicated service account limits the blast radius to a mailbox that only receives alerts.

Keep the receiver list short. Three addresses is the camera's limit and a sensible operational limit too. A long list makes people filter the alerts, and a filtered alert is worse than no alert because everyone assumes it is being handled.

Do not put sensitive site information in the subject line. The subject is limited to 63 characters and travels through every relay and gateway in the path. Use a site code or camera name, not a street address.

Review the account when hardware is decommissioned. Revoke the app password. Unused service accounts with SMTP permission are a quiet liability.

11.1 The clock, the certificate and the two-minute drift

The camera's clock is used for three things that interact with email: the timestamp in the message, the validity window for the TLS certificate presented by the mail server, and the start and end of any linkage schedule.

If the clock drifts far enough, certificate validation can fail even though nothing about the account changed — the server's certificate appears to be from the future or the past. The symptom is identical to a wrong password, and it appears out of nowhere on a camera that has worked for a year. Setting a working NTP server during commissioning removes this whole class of failure, and it costs thirty seconds.

Schedule boundaries are the second victim of a drifting clock. A linkage set for 18:00–06:00 evaluated against a clock that is forty minutes fast will fire early and stop early. Nobody notices until someone compares the notification time with a different system's log and finds a gap that should not exist.

A sensible commissioning step is to check the device time against a known reference, confirm NTP is enabled and reachable, and note the configured time zone in the handover pack. Time zone mistakes are even more common than drift: a camera set to the wrong zone produces perfectly accurate email with confidently wrong timestamps.

12. FAQ

Why is there no Test button? It appears only after you enter a receiver address. This is documented behaviour, not a bug.

Can I use my normal Gmail password? No. Google requires an app password for SMTP when 2-Step Verification is on, and rejects plain passwords otherwise for most accounts.

Why do test emails arrive but motion alerts do not? The SMTP layer works and the trigger layer does not. Check the event linkage, its schedule, and whether the source event is actually enabled.

Why do alerts stop after a few weeks? Usually the sending account's password changed, or the provider rotated or revoked the app password, or the camera lost DNS after a network change.

How many receivers can I add? Three. Use an alias or distribution list beyond that.

Can the camera send three pictures per alert? Yes — select the three-image option and set the interval. Each image adds to the message size, so keep an eye on the receiver's attachment limit.

Does the camera need internet access for email? It needs access to the SMTP server. That may be an internal relay on the LAN, in which case no internet access is required at all.

What time zone do the alert timestamps use? The camera's own clock. If the device is not time-synced, timestamps drift and correlation with other systems becomes impossible — set NTP during commissioning.

13. Sources

• Dahua Network Camera Web 5.0 Operation Manual V1.3.1 — §6.3.5 Email, Table 6-15, §6.5.1.2.5 Email Linkage, §6.5.1.3.1 Alarm Types
• Google Account Help — App passwords
• Microsoft — POP, IMAP and SMTP settings for Outlook.com
• Dahua Technology — product documentation portal

14. Where this fits in a larger deployment

Email alerting is one link in a chain that starts with detection and ends with a human response. In practice the chain looks like this: the camera detects, the event triggers a set of actions, the actions produce evidence and notifications, and the site's process turns a notification into a response.

Weak links are usually not where people look. A site with perfect SMTP configuration and a badly drawn IVS rule will produce flawless emails about nothing. A site with a perfect rule and no recording will notify you about an event you can no longer review. A site with both and no response process will notify someone who assumes someone else is handling it.

When commissioning, test the whole chain once, deliberately: trigger the event, confirm the recording exists, confirm the notification arrived, and confirm a named person acknowledged it. That single rehearsal is worth more than any amount of configuration review, because it is the only test that exercises every layer at once.

For teams standardising hardware across sites, keeping the camera models consistent simplifies this considerably — the same web interface, the same field names, the same alarm linkage layout. Browsing a consistent Dahua network camera lineup and matching accessories avoids the situation where three sites run three different firmware generations with three different menu trees. Where pan-tilt coverage is part of the design, the same logic applies to PTZ models. And if you are still specifying the hardware, our Dahua buying guide for 2026 covers the model families and what each tier is actually for.