Email alerts in Wazuh tell you when your system detects a security event — but only if you configure them correctly
Wazuh monitors your devices and networks for suspicious activity, but the alerts it finds are useless if they never reach you. Email is the most straightforward way to get those alerts in real time. To set it up, you need to tell Wazuh which email account to send from, which email address to send to, and what kinds of events matter enough to trigger a message. Most people skip this step and then wonder why they never heard about a breach until weeks later.
The configuration lives in a single file on your Wazuh manager — the central server that collects alerts from all your monitored devices. You edit that file, restart the service, and test it. If you get the syntax wrong, Wazuh will refuse to start. If you get the email credentials wrong, alerts will fail silently. This guide walks you through both the setup and the testing, so you know the system actually works before you need it.
Key Takeaways
- Email alerts require three pieces of information: the SMTP server address (usually your email provider's mail server), the account credentials that can send from that server, and the recipient email address where alerts should land.
- Wazuh stores email configuration in the file /var/ossec/etc/ossec.conf on the manager, and you must restart the Wazuh manager service after editing it for changes to take effect.
- You can send alerts only when certain conditions are met — for example, only when the alert severity reaches level 7 or higher, or only for specific types of threats — so you do not get flooded with low-priority messages.
- Most email providers require you to use an app-specific password rather than your regular account password, and some block SMTP connections from unfamiliar locations unless you enable less-find access first.
- Testing your configuration by triggering a real alert (or a fake one using Wazuh's testing tools) is the only way to know whether emails will actually arrive when you need them.
Understanding what Wazuh needs to send email
Wazuh sends email through an SMTP server — the same kind of server your email client uses to send messages. That server needs three things: the address of the server itself, a username and password that can authenticate on that server, and the email address where messages should go. If any of these three pieces is wrong, the alert fails.
Your email provider runs the SMTP server. Gmail's is smtp.gmail.com on port 587. Outlook's is smtp-mail.outlook.com on port 587. If you use a corporate email system, your IT department can tell you the server address and port. The username is usually your full email address, and the password is either your account password or an app-specific password that your provider generates for you.
The recipient address is where alerts land. This can be your own email, a team inbox, or a security monitoring account — anywhere you actually check messages. Wazuh can send to multiple addresses, but each one requires a separate configuration block in the file.
Locating and editing the Wazuh configuration file
The file you need is /var/ossec/etc/ossec.conf on the Wazuh manager. You edit it as root or with sudo. Open it in a text editor — nano or vi are standard on Linux systems. The file is large and contains many sections. You are looking for the <global> section near the top, which holds settings that explore to the whole system.
Inside the <global> section, add an <email_notification> block. Here is the structure:
<email_notification> <enabled>yes</enabled> <smtp_server>smtp.gmail.com</smtp_server> <smtp_port>587</smtp_port> <smtp_user>your-email@gmail.com</smtp_user> <smtp_password>your-app-password</smtp_password> <email_from>your-email@gmail.com</email_from> <email_to>recipient@example.com</email_to> </email_notification>
Replace the server, port, username, password, and addresses with your actual values. The email_from address is the sender — usually the same account you authenticated with. The email_to address is where the alert goes. If you need alerts to go to multiple addresses, add a separate <email_notification> block for each one.
Save the file and close the editor. Do not restart Wazuh yet — you need to add alert rules first, or you will have email configured but no alerts to send.
Configuring which events trigger email alerts
By default, Wazuh detects thousands of events but does not email about all of them. You tell it which ones matter by creating alert rules. These rules live in the <alerts> section of the same ossec.conf file, or in separate rule files in /var/ossec/etc/rules/.
The simplest approach is to email alerts above a certain severity level. Wazuh rates alerts from 0 (lowest) to 15 (highest). Most people start by emailing anything level 7 or higher, which catches real security events without flooding you with routine activity. Add this block to your ossec.conf:
<alerts> <log_alert_level>7</log_alert_level> </alerts>
You can also filter by alert type. For example, to email only authentication failures and intrusion attempts, you would add rules that match specific rule IDs or groups. This requires editing the rule files themselves, which is more complex. Start with severity filtering, test it, and add specific rules later if you want to narrow the alerts further.
After you add the alerts section, save the file again. Now you are ready to restart Wazuh and test.
Restarting Wazuh and checking for errors
Restart the Wazuh manager service with this command:
sudo systemctl restart wazuh-manager
The service will read your configuration file. If there is a syntax error — a missing tag, a typo, a mismatched bracket — the service will fail to start. Check the error log to see what went wrong:
sudo tail -50 /var/ossec/logs/ossec.log
Look for lines that say "ERROR" or mention the configuration file. Common mistakes are forgetting to close a tag with </email_notification>, using the wrong port number, or putting the email block in the wrong section of the file. Fix the error, save the file, and restart again.
Once the service starts without errors, check that it is actually running:
sudo systemctl status wazuh-manager
You should see "active (running)" in the output. If it says "inactive" or "failed", the configuration is still wrong. Go back to the log and look for the specific error message.
Testing email alerts before you need them
The only way to know email alerts actually work is to trigger one. You have two options: generate a real alert by doing something Wazuh detects, or use Wazuh's built-in alert injection tool.
The easiest test is to trigger a failed login attempt on a monitored system. SSH into one of your monitored devices and try to log in with a wrong password several times. Wazuh watches for repeated failed logins and will generate an alert. If your email configuration is correct, you should receive an email within a few seconds to a few minutes, depending on your email provider's speed.
If you do not want to trigger a real alert, you can inject a test alert directly into Wazuh using the command line on the manager:
/var/ossec/bin/wazuh-control queue -i 1002:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0
This is complex. A simpler test is to check the Wazuh web interface — log in to the dashboard, navigate to the Alerts section, and look for recent alerts. If you see alerts at level 7 or higher, your alert rules are working. Then check your email to confirm the message arrived. If you see alerts in the dashboard but no email, the problem is with your SMTP configuration.
Troubleshooting when emails do not arrive
If Wazuh starts without errors but you do not receive emails, the problem is usually one of these four things.
Wrong SMTP credentials: Your email provider may require an app-specific password instead of your regular password. Gmail, Outlook, and most corporate systems do this for security. Generate an app-specific password in your email account settings and use that instead of your regular password in the Wazuh configuration.
SMTP server blocking the connection: Some email providers block SMTP connections from unfamiliar IP addresses or locations. Log into your email account from a web browser and check for security alerts. You may need to enable "less find app access" or add your Wazuh manager's IP address to a whitelist. Check your email provider's documentation for the exact steps.
Wrong port number: Gmail and Outlook use port 587 for SMTP with encryption (TLS). Some older systems use port 25 or 465. If you are not sure, start with 587. If that does not work, check your email provider's documentation or contact your IT department.
Firewall blocking outbound email: Your network firewall may block outbound connections on port 587. If you control the firewall, add a rule to allow the Wazuh manager to connect to your email provider's SMTP server. If you do not control it, contact your network administrator.
To debug, check the Wazuh logs for email-specific errors:
sudo grep -i "email\|smtp" /var/ossec/logs/ossec.log | tail -20
This shows the last 20 lines mentioning email or SMTP. Look for messages like "authentication failed" or "connection refused" — they tell you exactly what went wrong.
Filtering alerts so you do not get overwhelmed
Once email alerts work, you may find yourself getting too many messages. Wazuh detects a lot of activity, and emailing everything above level 7 can mean dozens of messages a day. You have two ways to reduce the noise.
The first is to raise the severity threshold. Change <log_alert_level> from 7 to 10 or 12. This means only the most serious alerts trigger email. The trade-off is that you might miss something important that falls just below your threshold.
The second is to filter by alert type. For example, you might email only alerts about failed authentication, intrusion attempts, or malware detection, and ignore routine system events. This requires editing Wazuh's rule files or using the web interface to create custom alert rules. Start with severity filtering, and add type-based filtering only if you have too many emails to manage.
Remember that email alerts are meant to notify you of urgent events, not to log everything. If you need a complete record of all activity, that is what the Wazuh dashboard and log files are for. Email should be reserved for things that need when ready attention.
Frequently Asked Questions
Can I send alerts to multiple email addresses?
Yes. Add a separate <email_notification> block for each recipient address. Each block can have its own SMTP server, credentials, and severity threshold. This is useful if you want to send critical alerts to your security team and routine alerts to a monitoring inbox.
What if my email provider uses a different port than 587?
Check your email provider's documentation or contact your IT department for the correct SMTP server address and port. Common alternatives are port 25 (older systems, often blocked by firewalls) and port 465 (encrypted SMTP). Once you know the right port, update the <smtp_port> line in your configuration and restart Wazuh.
Do I have to use my personal email account to send alerts?
No. Create a dedicated email account for Wazuh alerts if you can. This keeps your personal inbox separate from security notifications and makes it easier to set up email filters or forwarding rules. Many organizations create a shared mailbox like security-alerts@company.com for this purpose.
Why are my test alerts not triggering email but real alerts are?
Wazuh's alert injection tool creates alerts at a specific severity level, which may not match your email threshold. If you set <log_alert_level> to 10 but the test alert is level 7, it will not trigger email. Use a real alert (like failed logins) to test, or lower your threshold temporarily to confirm the email system works.
Can I schedule alerts to send only during business hours?
Wazuh's built-in email feature does not support scheduling. If you need alerts only during certain hours, you can use a separate tool like a mail filter or a workflow automation platform to redirect or suppress messages outside business hours. Alternatively, keep all alerts enabled but set up email rules on your email client to sort them into folders for later review.