Data Domain: Autosupports Not Sending over Email SMTP

When a Data Domain system generates an Autosupport, it sends packaged diagnostic information using the configured SMTP server along with the system’s admin‑email identity. Successful delivery relies on several components working together:

• A reachable and properly configured SMTP mail server
• A valid admin‑email sender address, including a domain that the mail server accepts for relay
• Correct recipient and notify‑list entries
• Accurate DNS resolution for the mail server hostname
• Firewall rules allowing outbound TCP 25 or 587 to the mail relay
• Mail server acceptance of the sender identity, authentication, and relay permissions

If any of these components fail, the system still generates Autosupports internally, but theses are not delivered to Dell Support or to any configured recipients.

Confirm Autosupport Functionality.

Before diving deeper into troubleshooting, verify whether the system can send an Autosupport on demand. This helps determine whether the issue is mail‑related or part of a larger configuration problem.

• Send a generic Autosupport:

autosupport send

•  Or target a specific recipient for testing:

autosupport send <email_address>

Check for Mail-related Errors.

When Autosupports fail to send, the system usually provides clear indicators that the mail relay is unreachable or refusing the connection. One of the most common system alerts you see is:

EVT-SMTOOL-00001: Error communicating with mail server.

**** Unable to send message: (errno 51: Unrecoverable... autosupport@autosupport.datadomain.com)
**** Unable to send message: (errno 51: Unrecoverable errors from server--giving up)

These errors typically indicate one of the following underlying problems:

• The mail relay is blocking the connection
• Authentication to the mail server is failing
• The relay cannot route the sender domain
• The relay is unreachable due to DNS or network restrictions

Identifying these errors early helps narrow the troubleshooting focus to SMTP configuration, relay permissions, or network reachability.

Autosupport, alerting, and email-related logs are found in system logs stored under:

/ddvar/log

These logs include SMTP errors, connection failures, and Autosupport generation details.

Verify SMTP (Mail server) Configuration.

SMTP configuration problems are the most common reason Autosupport messages fail to send. Before troubleshooting anything else, confirm that the mail server settings are correct and reachable.

• Check that the configured mail server is correct on the DD
• Ensure that the target mail server can be reached (from the DD and its local network):

config show mailserver
net ping <mailserver-host-or-ip> count 4

• If the mail server entry is wrong or missing, update it and retest:

config set mailserver <mailserver-host-or-ip>
net ping <mailserver-host-or-ip> count 4

• DD OS 7.0+ and newer releases support authenticated SMTP over port 587 (STARTTLS and SMTPS). This is required for services like Office 365, Google Workspace, or any secured mail relay:

config set mailserver <mailserver-host-or-ip> port 587 user <smtp_user@yourdomain>
net ping <mailserver-host-or-ip> count 4

• Some environments may use port 25 instead. Allow outbound TCP 25 or 587 from the DD to your SMTP server.
• If the SMTP server requires authentication, the user must match (or be permitted to send as) the admin-email value.
• If the mail server rejects the authenticated identity, the Autosupport fails.

Validate the Admin Email (Sender Address)

The admin‑email value is used as the "From" address for all Autosupport and alert messages. If this address is invalid, improperly formatted, or associated with a domain that has no public MX record, many mail servers reject or identify the message as spam. This is a common cause of Autosupport failures, especially when external delivery fails while internal messages appear to work.

• Check the configured sender:

config show admin-email

• Update it if needed:

config set admin-email <email_address>

If the system can send to internal recipients but external messages fail, the sender domain is often the issue:

• Use nslookup (Windows) or dig (Linux/macOS) to confirm that the admin‑email domain has a valid public MX entry. If no MX exists, external relays do not accept mail from that domain.
• If the current sender domain is internal‑only, set a new admin‑email address using a domain with valid public DNS and MX records.
• For relays that require authentication (for example, Office 365, cloud SMTP), the SMTP username must either match the admin‑email address or have send‑as permissions for it. If the authenticated identity does not align with the sender address, the mail server rejects the message.

Confirm Recipient and Notify‑List Configuration.

Autosupports and alert notifications require valid recipients. If no recipients are configured—or if the addresses are incorrect—the system generates Autosupports internally but have nowhere to send them.

• View the current Autosupport and alert subscribers:

autosupport show all
alerts show all

• If recipients are missing, add them to the default notification group:

alerts notify-list add default emails <recipient@domain.com>

• You can verify that alert delivery is functioning by sending a test notification:

alerts notify-list test group default

Using these commands helps confirm that recipients are defined correctly and that the notification workflow is operational.

Firewall, Routing, and DNS Validation

Ensure that the system can reach the mail server. SMTP delivery cannot succeed unless DNS resolution and network connectivity are working end‑to‑end.

• Check connectivity to the mail server.
• The mail server hostname must resolve through DNS.
• The system must be able to reach the mail server on port 25 (SMTP) or port 587 (SMTPS and STARTTLS). If either check fails, the appliance cannot transmit Autosupports.
• Validate DNS resolution
  • If the mail server is configured using a hostname, verify that the appliance can resolve it:

net lookup <mailserver-fqdn>

• If the lookup fails, correct DNS before proceeding:
  • Add or update a DNS server. 

net set dns <dns-server-ip>
net lookup <mailserver-fqdn>

• • Or add a hosts file entry (useful as a temporary workaround)

net hosts add <mailserver-ip> <mailserver-fqdn>
net ping <mailserver-fqdn> count 4

• Test the mail server’s open ports:

net port-check <mailserver> 25
net port-check <mailserver> 587

Common Failure Scenarios and How to Fix Them.

1. Internal email works but external does not
   • Cause:
     • Admin-email domain lacks valid MX record.
     • SMTP relay disallows sending to external addresses.
   • Fix:
     • Use a public‑facing domain for admin-email.
     • Update relay permissions.
2. No email messages delivered (internal or external)
   • Cause:
     • SMTP server not configured or unreachable
     • Wrong port (25/587)
     • DNS resolution failure
     • Firewall blocking outbound SMTP
     • Initial setup wizard not completed
   • Fix:
     • Reconfigure SMTP (config set mail server…)
     • Verify DNS and firewall access
     • Rerun config setup if the system was never fully configured
3. SMTP authentication failures (such as, 550 errors)
   • Cause:
     • SMTP user not allowed to send as admin-email
     • Mail relay rejecting sender address or recipient domains
   • Fix:
     • Align the SMTP username with admin-email, or grant "send as" permissions
     • Add required external domains to the allowed recipient list

When to Contact Dell Support.

Reach out to Dell Support if any of the following conditions apply:

• Autosupports continue to fail even after verifying and correcting the mail server settings, admin‑email configuration, DNS resolution, and network connectivity.
• The system cannot establish a connection to the SMTP host, despite firewalls, routing, and DNS appearing to be correctly configured and open. 
• SMTP‑related logs show repeated failures, authentication errors, or internal validation issues that do not resolve through standard configuration updates. Autosupport delivery logs commonly contain errors such as EVT-SMTOOL-00001 or errno51 when persistent mail server failures occur.

If any of these conditions persist, Dell Support can help identify deeper platform, service, or mail‑handling issues that may not be visible through CLI‑level troubleshooting.

References:

• Data Domain: How to Troubleshoot Mail Server Issues | SMTP