Setting up email alerting on iDRAC 9

HCHTech

HCHTech

Well-Known Member
Reaction score
4,050
Location
Pittsburgh, PA - USA
As the title says. No email server on site, and no luck using an external SMTP server (tried Gmail, Smtp2Go & SendGrid, as well as my own domain's SMTP server). I originally discounted setting up an SMTP Relay server on the server itself because it is a Hyper-V host with 2 guests and adding features/roles to the Host itself would seem to break the licensing requirement since I only have a single copy of Server 2019 licensed in this installation. After my failure to get it working though, it appears that might be the only option. I can't get any details on the failure, and it appears that the mails aren't even reaching the SMTP servers, although it's difficult to be certain.

Am I missing something?
 
Last edited:
I just stuff in the MX record for the domain I wand to get alerts, and let it fire. You can't relay those emails to other domains... so this is also why I use a shared mailbox on M365, so I can forward from there to wherever I am.

DO NOT do the relay thing, that just means when the VM that does the relaying crashes you don't get notifications. iDRAC needs to be alerting directly to have value.

If the recipient is M365, you'll have to add the public IP the server is transmitting from to the SPF record. This assumes that Internet connection has a static address. Otherwise the alerts will be tagged as spam.
 
It was user error, as always. I had setup the iDRAC with a static on the client's management network, but the server was still on my bench. I was simulating the client's network with a spare firewall here, and didn't have the management network defined, so the iDRAC didn't have a path out to the internet. Duh. I tested that by changing the static to one living on the regular LAN, reset the email settings and it worked. Then, I added the management LAN on the firewall changed the iDRAC settings back to what I wanted and wdyk, it worked. I was so stuck on the settings nonsense, I didn't consider the basic internet connection. Couldn't see the forest for the trees. iDRAC needs a 'ping' on the diagnostics page or something, I guess.

I found threads on Dells forums & Reddit where someone had to set the iDRAC DNS name to the sending email name and the iDRAC DNS Domain to the sending email domain to make the authentication work, but that wasn't necessary at all for either Gmail or my own domain, so I don't know what they were on about there.
 
The iDRAC DNS name's suffix is what appears after the @ in the from address. The host name appears before the @. So playing with those two fields is how you set the email address iDRAC alerts FROM. Which is kind of handy...

Of course Dell could save this headache by letting us simply configure that along with SMTP authentication all in one place... But they don't.
 
Hmm.... So I just went back to it again, after reviewing my settings and still got the same error using my own email server. So I decided to just switch smtp to earthlink and it worked as advertised.
 
YeOldeStonecat said:
We just include our SMTP services in our domains SPF.....and in our clients DNS, we always include our domain in their SPF. Covers all this crap...keeping it simple.
Click to expand...

When you use your own domain's SMTP server for this, does that count as a relay? I've seen domain hosters that limit the number of relays you can have per time (so many per hour/day/month, etc). Maybe that's the reason to match the iDRAC's DNS name & host to the server you'll be using to send the mail - so it sees it as 'regular' mail and not as being relayed?
 
If you aren't authenticating, and the mail server is relaying mail... that's an open relay which is a great way to find yourself black listed.

This is why I aim a customer's notification systems at the MX record for the M365 instance (or GSuite). Because I can send mail from something@theirdomain.com directly to that MX and it'll be delivered. It'll likely be considered spam, so you need rules to deal with that but it works, and I don't have my junk between my customer and their stuff.
 
Sky-Knight said:
This is why I aim a customer's notification systems at the MX record for the M365 instance (or GSuite).
Click to expand...

Makes sense. I'm using a Gmail address for any hardware notification stuff, mostly just servers baseboard management and NAS units. That Gmail then forwards to the domain address we use in house to get & deal with those notifications. Any "success" messages get auto-peeled off into folders by client leaving only the stuff that needs attention left in the inbox. It works, but I worry it isn't scalable. We're not rapidly growing, so it's just something I'm keeping an eye on.
 
HCHTech said:
When you use your own domain's SMTP server for this, does that count as a relay? I've seen domain hosters that limit the number of relays you can have per time (so many per hour/day/month, etc). Maybe that's the reason to match the iDRAC's DNS name & host to the server you'll be using to send the mail - so it sees it as 'regular' mail and not as being relayed?
Click to expand...

We have 3x SMTP servers out there....and we use authentication most of the time (has the ability to allow unauth from designed IPs).
Clients domains SPF record includes our domains resources. I leave the iDracs host name reflective of clients domain.
 
You must log in or register to reply here.

Similar threads

HCHTech
Best Practice scan-to-email setup?
Replies
6
Views
1K
Sky-Knight
Sky-Knight
HCHTech
Managing Unifi equipment
Replies
12
Views
3K
Sky-Knight
Sky-Knight
HCHTech
Troubleshooting email bounces
Replies
11
Views
4K
HCHTech
HCHTech
B
APC Network Management Card AP9619
Replies
1
Views
918
pceinc
P
Hampden Comp
Setting up my server.
Replies
1
Views
986
angry_geek
angry_geek
Back
Top