SCOM 2025 not sending alert notifications using SMTP

If SCOM 2025 is not sending alert notifications using SMTP, here are some troubleshooting steps you can take:

1. Check SMTP Configuration: Ensure that the SMTP server information is correctly configured in SCOM. This includes the Fully Qualified Domain Name (FQDN), port number, and authentication method. You can refer to the configuration steps in the SCOM documentation to verify this.
2. Verify Email Channel Setup: Make sure that the email notification channel is properly set up in SCOM. This includes ensuring that the channel is enabled and that the return email address is correctly specified.
3. Event Viewer Logs: Check the event viewer logs for any errors related to the notification system. Each time the notification part runs, it logs events into the event viewer, which can help identify issues.
4. Test SMTP Server: Use the test SMTP server functionality in SCOM to send a test email. This can help confirm whether the SMTP server is reachable and configured correctly.
5. Firewall and Network Configuration: Double-check that there are no firewall rules or network configurations that might be blocking the SMTP traffic, even if the ports are opened and IPs whitelisted.
6. Retry Interval: If you have configured a retry interval, ensure that it is set appropriately. This is relevant if you have a secondary SMTP server configured.
7. Permissions: Ensure that the account used for SMTP authentication has the necessary permissions to send emails.

If you have gone through these steps and the issue persists, you may want to consult the SCOM documentation for further details on configuring email notifications or consider reaching out to Microsoft support for assistance.

References:

• How to enable an email notification channel
• Configure alerts in Configuration Manager

Hi,

You already did the right first checks (ports and whitelisting), but there are a couple of SCOM-specific pieces that commonly block notifications in SCOM 2025. I would walk through the following:

1. Verify that alerts exist

1. Open Monitoring → Active Alerts.
2. Confirm that alerts are being raised which should trigger notifications.
3. Note severity, class, and resolution state of a test alert for later checks.

2. Check the core notification components

2.1 Notification action account & permissions

1. In Administration → Run As Configuration → Accounts, verify a Notification action account exists, has valid credentials, and is not locked/expired.
2. Ensure it is distributed to the Notifications Resource Pool.
3. In Run As Configuration → Profiles → Notification Account, confirm this account is bound to the profile.
4. On the SMTP side, confirm:
   • The account (if used for auth) is allowed to authenticate and relay.
     • Or, for anonymous auth, that the SCOM servers’ IPs are allowed to relay.

2.2 SMTP channel

1. In Administration → Notifications → Channels, open your E-Mail (SMTP) channel.
2. Verify:
   • Correct SMTP FQDN and port.
   • Correct authentication type (Anonymous / Windows Integrated / External).
   • Reasonable Return address.
3. Use the Test button with a known recipient and note whether it succeeds or fails.

3. Network, ports, and whitelisting

1. In Administration → Resource Pools → Notifications Resource Pool, list all pool members.
2. From each member, verify connectivity to the SMTP host/port (e.g. Test-NetConnection).
3. Confirm all these IPs are allowed and whitelisted on firewalls and the SMTP relay/gateway.

4. Check the Operations Manager event log

1. On each notifications pool member, open Event Viewer → Applications and Services Logs → Operations Manager.
2. Trigger a test mail (channel test or test alert).
3. Look for notification-related warnings/errors (DNS issues, connection failures, authentication errors, TLS problems).

5. Validate subscribers and subscriptions

5.1 Subscribers

1. In Administration → Notifications → Subscribers, check that the subscriber is enabled.
2. Ensure the subscriber schedule is active for your test time.
3. On the subscriber’s email address:

• Correct SMTP channel.
• Correct address.
  • Address schedule active.

5.2 Subscriptions

1. In Administration → Notifications → Subscriptions, confirm the relevant subscription is enabled.
2. Temporarily simplify Criteria (e.g. only severity) to avoid over-filtering.
3. Ensure:
   • Correct subscriber(s) are added.
   • Correct SMTP channel is selected.
4. Optionally create a simple test subscription directly from a known alert via Active Alerts → right-click → Notifications → Subscribe… and verify if that sends mail.

6. SMTP / mail system checks

1. On the SMTP server or mail gateway, review logs for:
   • Connections from SCOM servers.
     • Auth failures.
       • Relay denials or rejected messages.
       1. Confirm the sender/Return address and domain are allowed to send to the recipients.
       2. For Exchange Online / external SMTP, verify SMTP AUTH or equivalent sending mechanism is allowed for the account you use.

Hope this helps you out! 

Best Regards

Stoyan Chalakov

"If my response was useful, please consider marking it as the answer. It keeps the forum clean, structured, and more helpful for everyone. Thank you for supporting the community."

Hi,

good, this already narrows it down quite a bit – if PowerShell can send mail via the same SMTP server and port, and nothing shows up in the Operations Manager log, then the problem is no longer "network/SMTP", but that SCOM’s notification engine is not actually firing the email channel at all.

Below are the next focused steps I would go through.

1. Make sure the notification engine is actually enabled

1. In the console, go to Administration → Settings → Notifications
   • Check that global notifications are enabled (no "master switch" set to off).
     • Confirm there is no very restrictive throttling or global schedule that would block sends.
     1. In Monitoring → Operations Manager → Management Group Health, look at the "Notifications" / "Alert Notification Subscription Server" components (naming may vary slightly in SCOM 2025).
        • Verify they are Healthy, not grey or critical.
          • If unhealthy, open their alerts and state changes – these often point directly to why subscriptions are not being processed.

2. Explicitly configure (or at least validate) the Notification Action Account

Even if your SMTP server allows anonymous relay, SCOM still uses the Notification Account Run As profile internally for the notification workflows. For SCOM 2025 the official guidance is to create and associate this account.

From:

How to create and configure the Notification action account

https://learn.microsoft.com/en-us/system-center/scom/manage-notifications-create-configure?view=sc-om-2025

"The Notification Account Run As profile is used to send notifications. For notifications to work correctly, you must create a Run As account that provides the credentials for sending notifications, and associate the Run As account to the Notification Account profile."

This step ensures that the notification workflows actually have a valid security context to run in, instead of silently doing nothing. Pleae follow the steps from the link to create  an account and then associate it with the respective profile.

3. Verify the Notifications Resource Pool really owns the work

SCOM 2012+ executes notifications via the Notifications Resource Pool. If that pool is misconfigured (empty, unhealthy, or pointing only to a dead server), notifications never run and you will see no SMTP-related events

1.    Go to Administration → Resource Pools → Notifications Resource Pool:

• Right-click → Properties → Membership:

Ensure at least one healthy management server is a member.

For testing, you can temporarily set membership to Manual and leave one known-good management server in there, so you know exactly where to look for events.

• Check the Health of the pool and its members in Monitoring (Management Group Health view).

1. On the selected management server:
   • Confirm these services are running:

System Center Data Access Service

System Center Management Configuration Service

System Center Management Service

4. Prove that subscriptions are evaluated (ultra-simple test subscription)

Given that no SMTP-related events show up, there is a high chance the existing subscription criteria never match, or the subscription/subscriber schedules filter everything away. To rule this out, create the most permissive test possible:

1. In Administration → Notifications → Subscribers:
   • Create a new test subscriber "TestSubscriber".
   • Schedule: Always send notifications.
   • Add one email address (yours), linked to your existing SMTP channel.
     1. In Administration → Notifications → Subscriptions:
        • Create a new subscription "Test - All Alerts".
        • Criteria:
          • Start with no filters except:

"Alert is new" (resolution state New/0),

Any severity, any priority,

Do not filter by group, class, name, or custom fields.

• Channel:

Select your working Email (SMTP) channel.

• Subscribers:
• Add the subscriber

1. Generate a fresh, very obvious test alert:
   • E.g. stop the HealthService on a test agent to trigger a "Health Service Heartbeat Failure" alert, or use a known rule/monitor that generates an alert immediately.
     • Make sure it is a new alert (not an old one changing state).
     1. While doing this, keep Event Viewer → Applications and Services Logs → Operations Manager open on the management server in the Notifications pool:
        • You should see events indicating that SCOM has evaluated the subscription and is sending an email.
          • If you still see no notification-related events at all for this new alert, we know subscriptions are not being processed.

The official Microsoft article on "Notification of Operations Manager alerts may not be received" (Link) describes this same approach: make the criteria very broad and check that prerequisites (subscriber schedule, address schedule, etc.) are all open.

5. Use the built-in channel "Test" and compare with PowerShell

You have already proven with PowerShell that SMTP itself works from the management server. Now compare that with SCOM’s own test:

1. In Administration → Notifications → Channels:
   • Open your E-Mail (SMTP) channel → Test.
   • Use the same recipient you used in your PowerShell test.
     • If this test also results in no mail and no Events in the Operations Manager log:

The SMTP call is not even reached → still points to missing Notification Account / pool / global notifications.

• If the test writes errors (e.g. DNS, TLS, auth), you will finally have concrete error codes to work with.

In short: SMTP and ports are fine in your case. The next steps are to (a) make sure SCOM has a proper Notification action account and a healthy Notifications Resource Pool, and (b) prove that at least one "catch-all" test subscription actually fires. Once you see Events for "sending notification" in the Operations Manager log, any remaining problems will be normal SMTP/auth/TLS issues instead of "SCOM never even tried".

If you like, you can post back the result of the ultra-simple test subscription (step 4) and whether you see any Events on the Notifications pool member – that will show very clearly where to dig next.

Hope this helps you out!

Regards,

Stoyan Chalakov

"If my response was useful, please consider marking it as the answer. It keeps the forum clean, structured, and more helpful for everyone. Thank you for supporting the community."