Wazuh Email Alerts Not Working? Complete Fix Guide

Wazuh email alerting is a core component of its Security Information and Event Management (SIEM) capability, enabling security teams to receive real-time notifications when suspicious activity, rule triggers, or compliance violations occur.

In production environments, email alerts often serve as the first line of operational awareness when dashboards are not actively monitored.

Email notifications remain essential in SIEM deployments because they:

• Provide asynchronous alerting when dashboards are not actively monitored
• Enable escalation workflows for SOC teams
• Support compliance requirements (audit logs, incident notifications)
• Bridge detection systems with human response processes

Without reliable email alerts, even correctly detected security incidents may go unnoticed, reducing the effectiveness of the entire monitoring pipeline.

Causes of Wazuh Email Alerts Not Working 

When Wazuh email alerts stop working, the symptoms typically fall into predictable categories:

• No emails are received at all despite alerts appearing in the dashboard
• Alerts are delayed by several minutes or hours
• Only high-severity alerts are delivered, while others are missing
• Intermittent delivery failures depending on load or time of day

These symptoms usually indicate issues in the SMTP integration layer rather than the detection engine itself.

How Wazuh Email Alerts Work (Architecture Overview)

Understanding the internal flow of alert delivery is essential before troubleshooting failures.

Wazuh email notifications are not generated directly by the detection engine; instead, they are triggered through a layered pipeline.

Role of the Wazuh manager in alert generation

The Wazuh manager is responsible for:

• Receiving and decoding logs from agents
• Matching events against rules
• Generating structured alerts in alerts.json
• Assigning severity levels (rule level-based classification)

At this stage, alerts exist only within the Wazuh ecosystem and are not yet externalized.

Integration with email systems (SMTP relay, external providers)

Email delivery is handled through integration scripts that interface with SMTP servers. These can include:

• Local SMTP relays (Postfix, Sendmail)
• Cloud email providers (Amazon SES, Gmail SMTP, Microsoft 365)

For reference on secure email relay configuration, see:
Wazuh Official Documentation – Email Alerts Integration

Alert flow: rule match → alert.json → integration script → SMTP server → inbox

The typical Wazuh email alert pipeline works as follows:

1. Event ingestion → logs are collected from agents
2. Rule evaluation → Wazuh rules match patterns and assign severity
3. Alert generation → results are stored in alerts.json
4. Integration trigger → scripts (e.g., maild) detect alert conditions
5. SMTP forwarding → email is sent via configured mail server
6. Delivery to inbox → recipient receives formatted alert notification

Any failure in this chain can prevent email delivery, even if detection is functioning correctly.

Difference between active response and email notifications

It is important to distinguish between these two mechanisms:

• Active Response: Automatically executes remediation actions (e.g., blocking IPs, killing processes)
• Email Notifications: Passive alerting mechanism used for human awareness

Active response operates at the enforcement layer, while email notifications operate at the communication layer.

Common Reasons Wazuh Email Alerts Stop Working

When Wazuh email alerts fail, the root cause is typically external to the detection engine.

Below are the most frequent failure points in production environments.

Misconfigured SMTP settings

Incorrect SMTP configuration is the most common issue, including:

• Wrong SMTP host or port
• Missing TLS/SSL configuration
• Incorrect sender address (from: mismatch)
• Invalid authentication credentials

Even minor misconfigurations can silently block outbound mail delivery.

Disabled or broken integration scripts

Wazuh relies on integration scripts to trigger email sending. Issues include:

• Script not enabled in ossec.conf
• Incorrect file permissions
• Script errors or missing dependencies
• Modified or outdated integration logic

If the script does not execute, no email will ever be generated regardless of alert volume.

Incorrect alert levels in rules

Email notifications are often filtered by severity level.

If thresholds are misconfigured:

• Low-level alerts may never trigger emails
• High thresholds may suppress important events
• Rule changes may unintentionally disable notifications

This is especially common after custom rule tuning.

Firewall or network restrictions blocking SMTP ports

Network-level restrictions frequently block email delivery:

• Port 25 blocked by ISP or cloud provider
• Outbound SMTP traffic restricted by firewall rules
• Cloud security groups not allowing egress traffic

This issue is common in AWS, Azure, and hardened enterprise environments.

Authentication failures (Gmail, Office365, SES, etc.)

Modern email providers enforce strict authentication policies:

• Gmail requires App Passwords or OAuth2
• Microsoft 365 may disable basic SMTP AUTH by default
• AWS SES requires verified identities and sandbox removal

For example, Microsoft has progressively deprecated basic SMTP authentication in many tenants:

Microsoft SMTP AUTH Deprecation Guidance

Wazuh manager service issues

If the Wazuh manager service is unstable:

• Alerts may not be processed in real time
• Integration queues may stall
• Email scripts may not be triggered

This often correlates with CPU spikes or disk saturation on the manager node.

Log/queue backlogs causing delays

High event volume can overwhelm processing pipelines:

• alerts.json grows faster than integration scripts can consume
• Queue delays result in late email delivery
• Burst traffic causes temporary email suppression

In large environments, this becomes a scaling and tuning problem rather than a configuration issue.

Outbound architectural reference (email delivery systems)

For deeper understanding of SMTP relay behavior and authentication best practices, AWS provides a reliable reference architecture:

Amazon SES SMTP Integration Guide

Verify Basic Wazuh Email Configuration

Before diving into deeper system or network issues, you need to confirm that the foundational Wazuh email configuration is correctly defined.

A large percentage of “Wazuh Email Alerts Not Working” cases are caused by simple misconfigurations in ossec.conf.

Checking ossec.conf email settings

Wazuh email functionality is controlled primarily through the global and integration-related sections of ossec.conf.

Key areas to verify:

• <email_notification> is set to yes
• <smtp_server> is correctly defined
• <email_from> and <email_to> fields are present
• Optional: <email_maxperhour> is not limiting output excessively

A minimal valid configuration typically looks like:

• email notifications enabled globally
• SMTP server explicitly defined
• at least one recipient configured

Validating SMTP host, port, and credentials

Incorrect SMTP parameters are one of the most common root causes of failure.

You should verify:

• SMTP host (e.g., smtp.gmail.com, smtp.office365.com)
• Correct port:
  • 587 (STARTTLS)
  • 465 (SSL)
  • 25 (unsecured or relay)
• Username/password correctness
• Whether authentication is required or relay-based

Even a single mismatch (such as using port 25 with TLS enabled) can silently break delivery.

TLS/SSL configuration mistakes

Encryption mismatches frequently break email delivery without obvious Wazuh-side errors.

Common issues include:

• Enabling TLS while connecting to a non-TLS port
• Using SSL on port 587 instead of STARTTLS
• Missing CA certificates on the Wazuh server
• Outdated OpenSSL libraries causing handshake failures

A good rule: match provider documentation exactly—do not assume defaults.

Ensuring correct sender and recipient fields

Misconfigured sender/recipient values can cause silent rejection by SMTP servers.

Check:

• email_from must be a valid, authenticated sender domain
• email_to must use properly formatted addresses (no commas, correct separators)
• Some providers reject mismatched “from” domains (common with Gmail and SES)

Many systems silently drop emails if sender validation fails, even if SMTP authentication succeeds.

Fixing SMTP Configuration Issues

Once basic configuration is validated, the next step is to ensure the SMTP layer is actually capable of sending mail externally.

This is where most production failures occur.

Testing SMTP connectivity from Wazuh server

Before blaming Wazuh, validate raw SMTP connectivity:

You can test using:

• telnet smtp.server.com 587
• openssl s_client -starttls smtp -connect smtp.server.com:587

You are checking for:

• Network reachability
• Open firewall ports
• Proper TLS handshake response

If these fail, Wazuh will never be able to send email regardless of configuration correctness.

Gmail SMTP setup (app passwords required)

Gmail is strict and often breaks traditional SMTP setups.

Requirements:

• Enable 2FA on Google account
• Generate an App Password
• Use:
  • SMTP: smtp.gmail.com
  • Port: 587
  • STARTTLS enabled

Important constraint: Google no longer allows basic password authentication for most accounts.

Reference:
Google App Passwords Documentation

Microsoft 365 SMTP requirements

Microsoft 365 has progressively tightened SMTP security.

Common requirements:

• SMTP AUTH must be enabled for the mailbox
• Use:
  • Server: smtp.office365.com
  • Port: 587
  • STARTTLS required
• Ensure tenant policies allow SMTP authentication

Microsoft is actively deprecating legacy authentication methods, which can silently break older Wazuh setups.

AWS SES configuration

AWS SES is commonly used for production SIEM environments due to reliability and scalability.

Key requirements:

• Verify sender identity (domain or email)
• Move account out of SES sandbox for production sending
• Use SMTP credentials generated from SES console
• Configure:
  • SMTP endpoint specific to region
  • Port 587 (STARTTLS) or 465 (TLS)

SES is often preferred in Wazuh deployments due to high deliverability and low spam filtering risk.

Reference:
AWS SES SMTP Integration Guide

Resolving authentication failures (535 errors, login rejected)

SMTP authentication failures are typically represented by:

• 535 Authentication failed
• 535 Incorrect username or password
• Login rejected

Root causes include:

• Incorrect credentials
• Disabled SMTP AUTH on provider side
• App password not used where required
• Account blocked due to security policy
• IP restrictions on SMTP relay

In most cases, these errors indicate provider-side rejection rather than Wazuh misbehavior.

Checking Wazuh Integration and Alert Rules

Even when SMTP is correctly configured, email alerts may still fail if Wazuh integration logic or rule conditions are not properly set.

Verifying integration blocks in configuration

Wazuh uses integration scripts (such as email notification scripts) defined in ossec.conf.

You should verify:

• Integration section is enabled
• Script path is correct
• Execution permissions are valid
• No syntax errors in configuration

If integration blocks are disabled or misconfigured, alerts will never trigger outbound email events.

Ensuring email alerts are enabled for correct rule levels

Wazuh does not send emails for every alert by default. It is usually filtered by rule level.

Check:

• Minimum alert level threshold (e.g., level 7+)
• Whether custom rules override default behavior
• Whether specific rule groups are excluded

A common mistake is setting the threshold too high, which effectively suppresses most alerts.

Checking decoders and rule mismatches

If logs are not correctly decoded, rules may never trigger.

Issues include:

• Incorrect log format (JSON vs syslog mismatch)
• Missing or custom decoder not applied
• Rule conditions not matching event structure
• Agent logs not reaching manager correctly

This leads to “silent failure,” where logs exist but no alert is generated.

Debugging missing alerts using alerts.json

alerts.json is the single most important debugging artifact in Wazuh.

You should:

• Confirm alerts are being generated locally
• Check timestamps for expected events
• Validate rule IDs and severity levels
• Ensure email-triggering rules exist in output

If alerts are present in alerts.json but no emails are sent, the issue is almost always in the integration or SMTP layer—not detection.

Firewall, Network, and Port Issues

Even when Wazuh and SMTP are correctly configured, email alerts often fail due to network-level restrictions.

In SIEM environments, outbound SMTP traffic is frequently blocked by default for security reasons, making this one of the most overlooked failure points.

Ensuring outbound access on port 25, 465, or 587

Wazuh relies on external SMTP connectivity, so the server must be able to reach the mail relay over the correct port:

• Port 25 → traditional SMTP (often blocked by ISPs/cloud providers)
• Port 587 → STARTTLS submission (most recommended)
• Port 465 → implicit TLS SMTP

You should verify:

• The Wazuh manager can reach the SMTP host on the required port
• No upstream firewall is silently dropping packets
• The chosen port matches the email provider’s configuration

A quick validation method:

• nc -vz smtp.server.com 587
• telnet smtp.server.com 465

If these fail, Wazuh email failures are guaranteed regardless of internal configuration.

Checking iptables / ufw rules

Local firewall rules on the Wazuh manager can also block outbound SMTP traffic.

Check common Linux firewall layers:

• iptables
  • Look for DROP or REJECT rules affecting outbound traffic
• ufw (Ubuntu/Debian systems)
  • Ensure outbound SMTP ports are allowed
• firewalld (RHEL/CentOS)
  • Verify zone-based egress rules

Typical misconfiguration patterns:

• Outbound policy set to DROP by default
• SMTP ports not explicitly allowed
• Interface-specific restrictions blocking external traffic

Cloud environment restrictions (AWS, Azure, GCP SMTP blocking)

Cloud providers often impose strict anti-spam policies that block direct SMTP traffic.

Common behaviors:

• AWS EC2: Port 25 is throttled or blocked by default
• Azure VMs: Outbound SMTP may require request-based unblocking
• GCP Compute Engine: Port 25 is restricted unless explicitly enabled

Recommended best practice:

• Avoid direct port 25 usage in cloud environments
• Use SMTP relay services (SES, SendGrid, Office365)
• Prefer port 587 with authenticated submission

These restrictions are not Wazuh-specific but are frequently misdiagnosed as application-level issues.

Debugging Wazuh Logs for Email Failures

When email alerts fail, Wazuh logs provide the most direct evidence of what is breaking in the pipeline.

Proper log analysis helps isolate whether the issue is configuration, SMTP, or integration-related.

Key log locations

/var/ossec/logs/ossec.log

This is the primary Wazuh manager log file. It contains:

• Integration script execution status
• SMTP connection errors
• Authentication failures
• Service-level warnings and errors

Look for entries related to:

• mail notifications
• integration scripts
• queue processing

/var/ossec/logs/alerts/alerts.json

This file contains structured alert data generated by Wazuh rules.

Key things to check:

• Whether alerts are being generated at all
• Rule level and group classification
• Timestamps matching expected events
• Missing alerts indicating rule or decoder issues

If alerts exist here but not in email, the issue is downstream (integration or SMTP).

Common error messages and meanings

Typical Wazuh email-related errors include:

• “Cannot connect to SMTP server”
  → Network/firewall or wrong host/port
• “Authentication failed”
  → Invalid credentials or disabled SMTP AUTH
• “Timeout while sending email”
  → TLS negotiation failure or blocked outbound traffic
• “Integration failed”
  → Script error or permission issue

Each error maps to a different layer of the stack, so identifying it precisely is critical for resolution.

Enabling verbose logging for email debugging

To gain deeper insight into email failures, you can increase logging verbosity in Wazuh.

Recommended actions:

• Enable debug mode for the manager
• Increase log level for integration scripts
• Monitor real-time log output using tail -f

This helps expose:

• SMTP handshake steps
• Script execution output
• Hidden authentication or TLS errors

Verbose logging is especially useful when failures are intermittent or environment-dependent.

Testing Email Alerts Manually

Before assuming system-wide failure, it is important to validate email functionality using controlled tests.

This helps isolate whether the issue is in detection logic or the email pipeline.

Using test alerts via rule simulation

Wazuh allows you to simulate or trigger test alerts by generating known events.

Approaches include:

• Sending sample logs that match existing rules
• Using built-in test rules (low severity security events)
• Simulating authentication failures or file changes

This confirms:

• Rule matching works correctly
• Alert generation pipeline is functional
• Integration scripts are triggered

Sending manual SMTP test emails from server

You should always validate SMTP independently of Wazuh.

Common tools:

• sendmail
• mail / mailx
• swaks (SMTP testing utility)

This verifies:

• SMTP authentication
• Network connectivity
• TLS handshake success
• Provider acceptance of messages

If manual SMTP tests fail, Wazuh will also fail—this isolates the issue immediately.

Triggering low-level security events for validation

Another reliable method is to generate real but harmless security events that Wazuh is designed to detect.

Examples:

• Failed SSH login attempts
• File modification in monitored directories (FIM)
• Temporary rule-triggering log entries

This helps confirm:

• End-to-end alert pipeline integrity
• Proper rule evaluation
• Email notification triggering under real conditions

Fixing Delayed or Missing Alerts

Delayed or missing email notifications in Wazuh are typically not caused by SMTP itself, but by upstream bottlenecks in the alert processing pipeline.

These issues manifest when alerts exist in the system but are not delivered to the integration layer in a timely manner.

Queue backlog in Wazuh manager

Wazuh processes events through internal queues before they reach alert generation and integrations. When traffic exceeds processing capacity, queues begin to backlog.

Common indicators:

• Increasing delay between event occurrence and email delivery
• Growing analysisd or remoted queue size
• Alerts appearing in bulk after a delay

Typical causes:

• Burst log ingestion (e.g., attack spikes or misconfigured verbose logging)
• Insufficient CPU allocation for the manager
• Inefficient or overly complex custom rules

Queue backlogs effectively delay the entire alert pipeline, including email notifications.

Disk space and performance bottlenecks

Wazuh is sensitive to disk I/O performance, especially for log-heavy environments.

Issues include:

• Full or near-full disk partitions (especially /var/ossec)
• Slow SSD/HDD I/O impacting log writing
• High latency in writing alerts.json

When disk performance degrades:

• Alerts are generated slower
• Integration scripts execute late
• Email notifications are delayed or dropped

Monitoring disk usage and IOPS is essential in production SIEM deployments.

High event throughput issues

High-volume environments can overwhelm Wazuh if not properly tuned.

Typical scenarios:

• Large-scale log ingestion from multiple endpoints
• Misconfigured verbose logging across agents
• Security incidents generating massive event spikes

Symptoms:

• Delayed alert processing
• Missing low-priority alerts
• Email notifications arriving in bursts

Mitigation typically involves:

• Rule tuning to reduce noise
• Increasing manager resources
• Load balancing or clustering Wazuh components

Indexer synchronization delays

If Wazuh is integrated with an indexing backend (e.g., OpenSearch), synchronization delays can indirectly affect alert visibility.

Problems include:

• Delayed indexing of alerts
• Lag between alert generation and dashboard visibility
• Misleading assumption that alerts were not generated

While indexing does not directly control email alerts, delays can complicate troubleshooting by obscuring real-time system state.

Advanced Troubleshooting

When standard configuration and log checks do not resolve email issues, deeper system-level debugging is required.

This involves inspecting network traffic, scripts, and OS-level restrictions.

Packet capture with tcpdump for SMTP traffic

Packet analysis helps confirm whether SMTP traffic is actually leaving the Wazuh server.

Useful commands:

• Capture outbound SMTP traffic:
  • tcpdump -i eth0 port 25 or port 587 or port 465
• Inspect TLS handshake attempts
• Verify packet transmission and response codes

What to look for:

• SYN packets with no response → firewall blocking
• TLS handshake failure → encryption mismatch
• RST packets → server or provider rejection

This method isolates network-layer failures from application-layer issues.

Debugging integration scripts line-by-line

Wazuh email delivery often depends on integration scripts that can fail silently.

Key debugging steps:

• Run scripts manually from CLI to observe output
• Add temporary debug logging inside scripts
• Validate environment variables and paths
• Check for missing dependencies (Python, mail utilities, etc.)

Common issues:

• Incorrect script permissions (chmod +x)
• Hardcoded paths not matching system layout
• Unexpected input format from Wazuh alerts

Line-by-line debugging helps isolate logic-level failures that logs may not fully expose.

Reverse proxy or relay server misrouting

In environments using mail relays or reverse proxies, misrouting can silently break email delivery.

Potential issues:

• SMTP relay misconfiguration forwarding to wrong host
• Reverse proxy altering headers or ports
• Load balancers blocking persistent SMTP sessions

This is especially common in enterprise environments using centralized mail gateways.

Even if Wazuh sends data correctly, upstream relay misconfiguration can prevent delivery entirely.

SELinux/AppArmor restrictions

Linux security modules can block Wazuh’s ability to execute integration scripts or access network resources.

Common restrictions:

• SELinux blocking outbound SMTP connections
• AppArmor profiles restricting /var/ossec execution
• Denied script execution due to policy enforcement

How it manifests:

• Scripts fail silently
• No SMTP connection attempts observed
• Permission denied errors in system audit logs

In strict environments, policy exceptions must be explicitly created for Wazuh services.

Best Practices to Prevent Email Alert Failures

Preventing email alert failures is more effective than troubleshooting them after deployment.

A well-architected Wazuh alerting system reduces dependency on fragile configurations and improves reliability.

Use dedicated SMTP relay service

Avoid relying on direct SMTP delivery from Wazuh servers. Instead, use dedicated relay services such as:

• AWS SES
• SendGrid
• Microsoft 365 SMTP relay

Benefits:

• Higher deliverability rates
• Reduced spam filtering risk
• Centralized authentication and logging

This also decouples SIEM alerting from infrastructure-level email limitations.

Rotate credentials securely

SMTP credentials should be treated as sensitive secrets.

Best practices:

• Store credentials in secure vaults (not plaintext config files)
• Rotate passwords or API keys regularly
• Use app-specific passwords where supported

This reduces the risk of credential leaks and unauthorized email access.

Monitor email delivery logs

Do not assume email delivery success—verify it continuously.

Recommended monitoring:

• SMTP provider logs (SES, Office365, Gmail logs)
• Wazuh integration logs
• System mail queue status (mailq, postqueue)

This provides visibility into both successful and failed deliveries.

Set alert thresholds to reduce noise

Over-alerting is a common cause of system degradation and delayed email delivery.

Best practices:

• Filter low-value alerts from email notifications
• Use severity-based thresholds (e.g., level ≥ 7)
• Group similar alerts where possible

Reducing noise improves both performance and analyst efficiency.

Implement secondary alert channels (Slack, webhook, SIEM dashboards)

Email should not be the only alerting mechanism in a modern SIEM architecture.

Recommended alternatives:

• Slack or Microsoft Teams webhooks
• PagerDuty or Opsgenie escalation systems
• Real-time SIEM dashboards (OpenSearch, Kibana)

This ensures redundancy in case email delivery fails and improves incident response speed.

Frequently Asked Questions (FAQ)

Question: Why are Wazuh email alerts not sending at all?

When Wazuh email alerts are not sending at all, the issue is almost always located outside the detection engine.

The most common causes include:

• Misconfigured SMTP settings (wrong host, port, or credentials)
• Firewall or cloud provider blocking outbound SMTP ports
• Disabled or broken email integration scripts
• SMTP authentication failures (especially with Gmail or Microsoft 365)
• No alerts being generated due to rule or decoder issues

In most cases, verifying SMTP connectivity and checking /var/ossec/logs/ossec.log will quickly isolate the failure layer.

Question: Does Wazuh support Gmail SMTP?

Yes, Wazuh can use Gmail SMTP, but it requires strict authentication and configuration requirements due to Google’s security policies.

Key requirements:

• Two-factor authentication (2FA) must be enabled
• An App Password must be generated (regular passwords will fail)
• SMTP server: smtp.gmail.com
• Port: 587 with STARTTLS enabled

Gmail is functional for testing and small deployments, but it is not recommended for large-scale SIEM environments due to rate limits and policy restrictions.

Question: How do I test Wazuh email notifications?

You can test Wazuh email notifications using multiple methods:

• Trigger a test rule event
  • Generate a controlled event (e.g., failed SSH login)
• Check alerts.json
  • Confirm that alerts are being generated
• Send manual SMTP test email
  • Use tools like sendmail, mailx, or swaks directly from the Wazuh server
• Verify integration execution
  • Check /var/ossec/logs/ossec.log for email script activity

The most reliable validation method is confirming both:

1. Alert generation in Wazuh
2. Successful SMTP delivery outside Wazuh

Question: Can Wazuh send alerts without SMTP?

Yes, but only indirectly.

Wazuh does not have a native email delivery system and relies on external mechanisms for notification delivery. However, it can send alerts without SMTP using:

• Webhook integrations (Slack, Teams, custom APIs)
• SIEM forwarding to OpenSearch/Kibana dashboards
• Active response scripts for automated actions

In modern deployments, many teams replace SMTP with webhook-based alerting due to higher reliability and flexibility.

Question: Why are some alerts delayed or missing?

Delayed or missing alerts are typically caused by system-level bottlenecks rather than detection failures.

Common causes include:

• Queue backlog in the Wazuh manager
• High event ingestion rates overwhelming processing capacity
• Disk I/O or storage performance issues
• Indexer synchronization delays (OpenSearch/Kibana lag)
• Integration script delays or execution failures

If alerts appear in alerts.json but not in email, the issue is in the integration or SMTP layer.

If alerts are missing entirely, the issue is in rule processing or event ingestion.

 Conclusion

Wazuh email alert failures are rarely caused by a single issue.

Instead, they typically result from a combination of configuration errors, network restrictions, SMTP authentication problems, or system-level performance bottlenecks.

Understanding the full alert pipeline—from rule detection to SMTP delivery—is essential for accurate troubleshooting.

Recap of key fixes

The most critical areas to verify when Wazuh email alerts are not working include:

• SMTP configuration (host, port, credentials, TLS settings)
• Network and firewall access to outbound SMTP ports
• Integration script execution and permissions
• Rule levels and alert generation in alerts.json
• Cloud provider restrictions on SMTP traffic

Addressing these systematically ensures that both detection and delivery layers are functioning correctly.

Importance of monitoring integration health

Email alerts should not be treated as a “set and forget” feature.

The integration layer is just as important as detection rules in a SIEM system. Continuous monitoring of:

• SMTP connectivity
• Integration logs
• Alert queue health
• Delivery success rates

helps ensure that critical security events are reliably delivered to analysts in real time.

Final recommendation: proactive alert testing and monitoring

To maintain a reliable Wazuh alerting system, organizations should adopt a proactive approach:

• Regularly test email alert pipelines using controlled events
• Monitor SMTP provider logs for delivery failures
• Implement secondary alerting channels (webhooks or SIEM dashboards)
• Periodically audit rule thresholds and integration scripts

A well-maintained alerting pipeline ensures that Wazuh remains effective not only at detecting threats, but also at delivering those detections to the right people at the right time.