Email alerts in Wazuh require three separate configurations: the mail server connection, the alert rules that trigger emails, and the recipient addresses
Wazuh will not send you email notifications unless you tell it which mail server to use, which events matter enough to email about, and where those emails should go. Most people skip one of these steps and then wonder why alerts never arrive. The process takes about 15 minutes if your mail server details are ready, and you can test it immediately to confirm it works before relying on it.
This guide covers the standard setup for Wazuh 4.x running on Linux. If you are using a managed Wazuh cloud instance, your mail server settings may be pre-configured or restricted by your provider — check their documentation first.
Key Takeaways
- Wazuh's mail settings live in ossec.conf, and you must restart the Wazuh manager after editing this file for changes to take effect.
- You need a working SMTP server (your own mail server, Gmail with an app password, or a third-party service like SendGrid) and the correct hostname, port, and authentication details.
- Alert rules in ossec.conf determine which events trigger emails — by default, almost nothing does, so you must add rules to send alerts for the events you care about.
- Test your configuration by triggering a rule manually or waiting for a real event, then check both the Wazuh logs and your inbox to confirm the email arrived.
Locate and edit the Wazuh configuration file
The main Wazuh configuration file is /var/ossec/etc/ossec.conf on Linux systems. Open it with a text editor — most administrators use nano or vi. You will need root or sudo access.
The file is long and organized into sections marked with angle brackets like <global> and <alerts>. You will be adding or editing content in two places: the <global> section (for mail server details) and the <alerts> section (for which events trigger emails). Scroll through the file to find these sections before you start editing.
Configure the mail server connection in the global section
Inside the <global> section, add or update these lines with your mail server details:
<mail_notification>yes</mail_notification> <smtp_server>mail.example.com</smtp_server> <smtp_port>587</smtp_port> <smtp_security>tls</smtp_security> <smtp_authentication> <server>mail.example.com</server> <port>587</port> <username>your-email@example.com</username> <password>your-app-password</password> </smtp_authentication> <email_notification>yes</email_notification>
Replace mail.example.com with your actual SMTP server hostname. Common options are your company mail server, Gmail's SMTP server (smtp.gmail.com), or a third-party service like SendGrid or Mailgun. The port is usually 587 for TLS or 465 for SSL — check your mail provider's documentation if you are unsure. The username and password are the credentials Wazuh will use to log into that server.
If you are using Gmail, you cannot use your regular Gmail password. Instead, create an app password by enabling two-factor authentication on your Google account, then visiting myaccount.google.com/apppasswords. Select "Mail" and "Linux" to generate a 16-character password that works with Wazuh. Use that password in the <password> field, not your actual Gmail password.
Add alert rules to trigger email notifications
By default, Wazuh logs security events but does not email about them. You must create rules that tell Wazuh which events should trigger an email. These rules live in the <alerts> section of ossec.conf.
A basic alert rule looks like this:
<alert_by_email> <email_notification>yes</email_notification> <group>authentication_failed</group> <do_not_group>no</do_not_group> </alert_by_email>
This rule sends an email whenever Wazuh detects an event in the authentication_failed group — for example, failed SSH login attempts. You can add multiple <alert_by_email> blocks for different event types. Common groups include authentication_success, rootkit_detection, file_integrity_monitoring, and vulnerability_detected. Check the Wazuh documentation or your own rule files in /var/ossec/etc/rules/ to find the group names that match the events you want to monitor.
The <do_not_group>no</do_not_group> line tells Wazuh to send one email per event. If you set it to yes, Wazuh will batch multiple events into a single email, which reduces email volume but delays notification.
Specify the recipient email address
Still inside the <alerts> section, add the email address where alerts should be sent:
<email_alerts> <email_to>security-team@example.com</email_to> </email_alerts>
You can add multiple <email_to> lines if you want alerts sent to more than one person. Each line should contain one email address.
Restart the Wazuh manager and check for errors
After you save your changes to ossec.conf, restart the Wazuh manager so it reads the new configuration:
sudo systemctl restart wazuh-manager
Check that the restart succeeded by running:
sudo systemctl status wazuh-manager
If the status shows "active (running)", the restart worked. If it shows "failed" or "inactive", check the Wazuh logs for the error:
sudo tail -50 /var/ossec/logs/ossec.log
Common errors include a typo in the SMTP server hostname, an incorrect port number, or authentication credentials that do not match your mail server. Fix the error in ossec.conf, save it, and restart again.
Test the email configuration before relying on it
The safest way to test is to trigger a real event that matches one of your alert rules. For example, if you have an alert rule for failed SSH logins, try logging into the monitored system with a wrong password a few times. Wazuh should detect this and send an email within a minute or two.
If you do not want to wait for a real event, you can manually trigger a test alert by adding a temporary rule to ossec.conf. Add this block to the <alerts> section:
<alert_by_email> <email_notification>yes</email_notification> <group>test_alert</group> </alert_by_email>
Then restart Wazuh and check the logs to see if an email was sent. Look in /var/ossec/logs/alerts/alerts.log for a line that says "Email alert sent to" followed by your recipient address. If you see that line, the email was sent. If you do not see it, check your mail server logs and the Wazuh logs for errors. Once you confirm it works, remove the test rule and restart again.
Frequently Asked Questions
Why am I not receiving emails even though Wazuh says they were sent?
Check your spam or junk folder first — mail from Wazuh often gets filtered there. If it is not there, verify that the email address in <email_to> is correct and that your mail server is actually accepting messages from Wazuh. Check your mail server's logs to see if the message arrived but was rejected. If the mail server rejected it, the error is usually an authentication failure — double-check your username and password in the <smtp_authentication> section.
Can I send alerts to different email addresses for different event types?
Yes. Create separate <alert_by_email> blocks for each event type, and inside each block add the <email_to> address you want for that group. For example, you could send failed login alerts to your security team and file integrity alerts to your compliance officer.
What if my mail server requires SSL instead of TLS?
Change <smtp_security>tls</smtp_security> to <smtp_security>ssl</smtp_security> and change the port to 465. Most modern mail servers use TLS on port 587, but some older systems or internal mail servers use SSL on 465.
How do I know which event groups are available to alert on?
Check the rule files in /var/ossec/etc/rules/ — each rule has a <group> tag that shows its classification. You can also search the Wazuh documentation for "rule groups" to see a full list. Start with common ones like authentication_failed, rootkit_detection, and vulnerability_detected, then add more specific groups as you understand your environment better.
Will too many alert emails slow down Wazuh or my mail server?
Wazuh can handle sending hundreds of emails per minute without performance issues, but your mail server might not. If you are getting too many alerts, use <do_not_group>yes</do_not_group> to batch events into fewer emails, or narrow your alert rules to only the most critical events. You can also set a minimum severity level so that low-priority events do not trigger emails.