# How to Configure Wazuh Email Alerts: A Complete Setup Guide Wazuh is a powerful open-source security platform used for threat detection, log analysis, and compliance monitoring. One of its most practical features is the ability to send **email alerts** when specific security events are detected — giving your team real-time visibility without having to watch dashboards continuously. Setting it up involves several moving parts, and getting the configuration right depends heavily on your environment. ## What Wazuh Email Alerts Actually Do When Wazuh detects an event that matches a rule — say, a failed SSH login, a file integrity change, or a privilege escalation attempt — it can trigger an **alert notification**. These alerts are categorized by **severity level**, ranging from 0 (informational) to 15 (critical). Email alerts work by routing these triggered rules through an SMTP server of your choosing. Wazuh doesn't send emails itself; it hands the job to a mail transport agent or a configured SMTP relay. That distinction matters when troubleshooting delivery issues. ## Core Components You'll Need Before touching any configuration file, make sure you have: - **A working SMTP server or relay** — this could be a local mail server (like Postfix), a corporate SMTP gateway, or a third-party service like Gmail, SendGrid, or AWS SES - **Valid SMTP credentials** — username, password, host, and port - **Access to the Wazuh manager** — email alerts are configured at the manager level, not on agents - **A destination email address** — where alerts should land ## Editing the Wazuh Manager Configuration The main configuration file is located at: ``` /var/ossec/etc/ossec.conf ``` Inside this XML file, you'll find (or need to add) a ` ` block. This is where email settings live. ### Basic Email Configuration Block ```xml yes smtp.yourdomain.com [email protected] [email protected] 12 alerts.log ``` Key fields to understand: | Field | Purpose | |---|---| | `email_notification` | Enables or disables the email feature globally | | `smtp_server` | Hostname or IP of your SMTP relay | | `email_from` | The sender address Wazuh uses | | `email_to` | Primary recipient address | | `email_maxperhour` | Caps how many emails are sent per hour | | `email_log_source` | Which log file triggers are read from | ### Setting the Alert Threshold By default, Wazuh only emails alerts that reach a certain **severity level**. You control this with: ```xml 7 ``` Level 7 is a common starting point — it catches meaningful security events without flooding your inbox. Setting it too low (like 3 or 4) will generate excessive noise. Setting it too high means you may miss important mid-severity events. ## Configuring Granular Email Alerts Per Rule Beyond the global threshold, Wazuh lets you send emails for **specific rules** regardless of their level. This is done inside ` ` blocks: ```xml [email protected] 5710 ``` This tells Wazuh to send an immediate email to a specific address whenever rule 5710 fires — in this case, an SSH authentication failure. The ` ` tag bypasses any batching delay, which is useful for critical rules. You can also filter by **group** rather than individual rule IDs: ```xml [email protected] authentication_failed ``` This approach scales better in larger environments where you're watching dozens of rule categories. ## Using an External SMTP Service (Gmail, SendGrid, etc.) If you're relying on a third-party SMTP provider rather than a local mail server, the process typically involves one extra layer: **a local MTA (mail transfer agent)** configured as a relay. On most Linux systems running Wazuh, **Postfix** is the standard choice. You'd configure Postfix to authenticate with your external SMTP service and relay outbound mail, then point Wazuh's `smtp_server` value to `localhost`. This setup adds complexity but gives you reliable delivery, especially when outbound port 25 is blocked by your cloud provider — which is common on AWS, GCP, and Azure instances. In those cases, using port 587 (STARTTLS) or 465 (SSL) through a relay is the standard workaround. ## 🔍 Variables That Affect Your Specific Configuration No two Wazuh deployments look the same. What works cleanly in one environment may require significant adjustments in another. Key variables include: - **Wazuh version** — configuration syntax has evolved across major releases; always check against your installed version's documentation - **Network restrictions** — firewall rules, outbound port policies, and cloud provider limitations all affect SMTP reachability - **Volume of monitored agents** — a single-agent homelab has very different alert volume than a 200-agent enterprise deployment - **Alert tuning** — your existing custom rules and rule exclusions determine what actually triggers an email - **Authentication requirements** — some SMTP providers require OAuth2 or app-specific passwords, which may require Postfix relay configuration rather than direct SMTP ## 📋 After Saving Your Configuration Once you've edited `ossec.conf`, restart the Wazuh manager to apply changes: ```bash sudo systemctl restart wazuh-manager ``` Then send a test alert using Wazuh's built-in tool: ```bash /var/ossec/bin/wazuh-maild ``` Check the log for errors: ```bash tail -f /var/ossec/logs/ossec.log ``` Common failure points include DNS resolution of the SMTP hostname, authentication errors, and firewall blocks on outbound mail ports. ## Where Individual Setup Diverges The configuration steps above cover the technical mechanics — but how you tune the alert threshold, which rules you target, how many recipients you set up, and whether you layer in a Postfix relay all depend on factors that are specific to your infrastructure, team size, and risk tolerance. A homelab running Wazuh for personal learning needs a very different alert strategy than a regulated environment sending alerts to an on-call security team. 🛡️ The gap between "configured correctly" and "configured correctly for your situation" is where most of the real decision-making lives.