Wazuh email alerts not sending: level 12 by default and no SMTP login, measured

Wazuh email alerts not sending

Two defaults explain most cases on Wazuh 4.14.7. Only alerts of level 12 or higher are mailed (<email_alert_level>12), so a brute-force alert at level 10 sends nothing. And wazuh-maild speaks plain SMTP with no login and no TLS, so it can't log in to a server that requires authentication, as Gmail and Office 365 do. Our test server that asked for a login refused it with (1764): Mail from not accepted by server.

Dong Nguyen, ATK New Technology · 2 October 2026 · measured on Wazuh 4.14.7 (manager container, local test SMTP server)

Stuck on this right now? Email your custom rules or decoders, one sample log line and your Wazuh version to dongnx@atkvn.com. We run them on that exact version and reply within 24 hours with what we find. Free. Remove hostnames, IPs and usernames first. Rather not send them? Run the free pre-check in your browser; your files never leave your machine. Rather have it fixed? USD 149 fixed price per problem, reproduced on your version, and you pay only after it works on your system. Our first three customers pay USD 49 for one fix, in exchange for an anonymised write-up we can publish.

How to check in one minute

grep -E 'email_notification|smtp_server|email_to|email_alert_level' /var/ossec/etc/ossec.conf
grep wazuh-maild /var/ossec/logs/ossec.log | tail -n 20

<email_notification>no is the default: nothing is sent at all.
<email_alert_level>12 is the default: only alerts at 12 or above are mailed.
(1764): Mail from not accepted by server followed by (1263): Error Sending email: the server wants authentication or refuses the sender.

What we measured

We pointed a 4.14.7 manager at a test SMTP server on 127.0.0.1, set <email_notification>yes, and sent ten sshd events over syslog: one failed login on one host, then eight failed logins and a success from one address on another.

Setting	Alerts written	Emails received
defaults (`email_alert_level` 12)	8 × 5760 (level 5) · 1 × 5763 brute force (level 10) · 1 × 40112 (level 12)	1, containing 40112 only
`email_alert_level` 10	same	1, containing both 5763 and 40112 (grouped; subject shows the highest level)
defaults, server answers `530 Authentication required`	same	0; `ERROR (1764)` and `ERROR (1263)` in `ossec.log`

The SMTP conversation from wazuh-maild was Helo notify.ossec.net, Mail From, Rcpt To, DATA, QUIT: no EHLO, no STARTTLS, no AUTH. A relay that wants a login stops it at Mail From.

Fix

1. Turn it on and choose the threshold. In the <global> section of /var/ossec/etc/ossec.conf on the manager:

<global>
  <email_notification>yes</email_notification>
  <smtp_server>127.0.0.1</smtp_server>
  <email_from>wazuh@your-domain</email_from>
  <email_to>soc@your-domain</email_to>
  <email_maxperhour>12</email_maxperhour>
</global>
<alerts>
  <log_alert_level>3</log_alert_level>
  <email_alert_level>10</email_alert_level>
</alerts>

Restart the manager. Lowering the threshold means more mail; email_maxperhour caps it, and alerts that arrive together are grouped into one message, as we saw.

2. Send through a relay that does the login. Because wazuh-maild cannot authenticate, point <smtp_server> at a local relay (for example Postfix on the manager, listening on 127.0.0.1) and configure that relay with the credentials and TLS your provider requires. Test the relay on its own first, then Wazuh.

Limits of what we measured

Measured on a Wazuh 4.14.7 manager container against a minimal SMTP test server on 127.0.0.1, with alerts in log format (the default). We did not configure a real Postfix relay, Gmail or Office 365, per-rule or per-group email options (<email_alerts>), or other versions. The relay setup itself depends on your mail provider.