MX Server Error Message

Please notice that the built-in mail option uses the MX record to send the emails. As such, such a record must exist and must connect to a mail relay server in order for this option to work. If you have such a connection, please check the same and the DNS settings, to make sure that the settings are properly defined in such a way that PRTG would also be able to connect to the mail relay server defined.

Ok, so HOW do I ensure a record exists and HOW do I connect to a mail relay server? With the built in mail option, there are only a couple fields to complete, none of which are a mail relay server.

The MX record would already have to be configured within your network, this is not a PRTG setting. If you do not have a MX record for a mail relay server, you would have to configure the same, respectively contact an administrator who is able to define the same for the network in case. For gmail, for example, you will find some information under Troubleshoot MX records. If, however, you are using gmail as a relay provider, we would highly recommend setting this up using the SMTP server option (please have a look at Can GMail / Google Apps be used for SMTP relay?).

This is not a very helpful reply by support. I've noticed that support omits many steps from the how-to. Why is that? If they don't know please say you don't know and you're looking into it instead of sending us customers into nowhere land without complete information.

Thank you,

@lhaus: Please note that the quintessence of the support staff answer is that probably no mx record is set up for the network PRTG is running in. This is basically all information you need to troubleshoot the issue as setting up an MX record correctly will indeed fix the issue. The linked articles are references for further reading and I cannot see any wrong with that. If you would like to have more information on how our support staff works, please contact us directly at support@paessler.com.
Best regards

i just moved from one server to another. notifications were working fine, until this move. new server is giving this error:

"Status sending Email: DNS Server: xxx.xxx.xxx.xxx E-Mail: "xxx@gmail.com". No MX records for the domain gmail.com. DNS Server: xxx.xxx.xxx.xxx. E-Mail: "xxx@gmail.com". Can not connect to MX servers for address xxx@gmail.com."

From the command line on the server, I am able to lookup and resolve the MX records for gmail.

Adding a rule to allow PRTG outbound traffic resolved the issue. Maybe this will be helpful to someone : )

Thanks for sharing! :)

Hello support - Is there a formal solution from Paessler to this problem i.e. "Can not connect to MX servers..." ?

The problem happens when:

1. Notification Delivery is configured to use "built-in email relay server"
2. Email is being sent to outside of the LAN, i.e. gmail, yahoo.com, .etc.

Sending notification to email addresses inside the LAN works fine. If "Adding a rule to allow PRTG outbound traffic" was a solution, would you please elaborate?

You can simply reproduce the error by sending an email notification to outside of Paessler network.

Thank you.

Dear safvat

There is no official solution, as this has to be configured outside of PRTG. If DNS servers are used, they must have an MX resource record entry for the email address domain. You also might find this KB entry useful.

The referenced KB does not apply since the solution was to use an internal SMTP. The point is to use PRTG to check the health of an internal SMTP server and if Down, use external SMTP server (e.g. user@gmail.com) for notification.

Maintaining an MX record for a server outside of our control is unsuitable. One has to maintain a zone file for example for gmail.com and include MX record that would change over time.

Have you tested what is being requested internally? Perhaps PRTG internal SMTP server is reporting a wrong error, i.e. MX Server error rather than "Relaying" error?

Dear safvat

Please clarify, which option you are using (since there is no "built-in email relay server" option). Are using "Direct delivery using built-in email server (default)", or "Use SMTP relay server (recommended inside LANs/NATs)"?

Dear "Paessler Support"

Joining Safvat in his request. I'm having similar issue on one of the PRTG servers. Same configuration, but one of them has the above mentioned errors with MX records. Command Prompt - nslookup - q-mx = works fine and returns correct answers. I'm using "Direct delivery using built-in email server (default)".

Hi Safvat, Hi Ilya,

Obviously some definitions got mixed up in the previous posts, I'll try to bring them in order.

An MX-Record is just a DNS-Record that points to the MX (Mail Exchange) server(s) that is / are responsible for a specific domain.
If you are able to resolve the record to an ip-address through a dns-lookup it is not even clear that you will be able to connect to these systems and communicate with it at port 25 / 587 for obvious security reasons.
I'm pretty sure this was meant previously by user syscom with his tip of 'Adding a rule to allow PRTG outbound traffic resolved the issue'. You simply have to make sure that PRTG is able to connect to the internet using port 25 (and / or maybe 587) when you are using the buildin mailsystem to send emails to external domains.
Otherwise PRTG will be able to determine the appropriate server that is responsible for the email but is not able to connect to it and deliver the mail.

Kind Regards

There is no block for port 25 on PRTG server. Tested and successfully sent email to the same recipient PRTG is supposed to send, using telnet commands on PRTG server.

Sorry for the confusion. The discussion is concerning "Direct delivery using built-in email server (default)"

None of the incoming or outgoing ports (25, 587, or 465) are blocked on our network. Our on-site SMTP server works fine sending a test e-mail to user@gmail.com therefore ports are open and DNS resolves.

Here is a simple request to replicate the problem:

1. Configure your PRTG to use "Direct delivery using built-in email server (default)"
2. Make sure your DNS is reachable and ports (25,587, etc.) are open
3. Send a test e-mail to a gmail, yahoo, etc.
4. Report the outcome

My bet is that you will see the MX Error in discussion. My guess is that your "built-in" server is configured not to allow relaying and PRTG is showing MX error rather than showing a relaying error.

In this case, please enable the notification debug logging. (Please disable it afterwards, because this log creates a lot of entries.)

Please have a look into the logs created. Can you find further information about the exact cause? You can also contact us via support@paessler.com to send us those logs.

Dear Support,

The debug log only shows what is already in the regular log.

Frankly the remedies and the links shared by the support so far have not been useful. Could I trouble you with performing the simple 4-steps outlined above and escalating the case to tier-3 if needed? Thank you.

Dear safvat

For analysis, please contact us via said email and attach the debug log.

Any updates on this issue

Dear Ilya

For analysis, please also contact us via email and attach the debug log.

Hi, ran in to the same problem and tried the steps listed, but one of the steps above alluded to this;

"Our on-site SMTP server works fine sending a test e-mail to user@gmail.com therefore ports are open and DNS resolves."

Hmm Ok... what was the email address you were sending from?

I suspect that google maybe doing a reverse lookup on the 'mail from'?? as my 'Sender Email' address wasn't a real address, I created it in O365 and google accepted the emails.

Hope this helps someone, oh and check the spam folder ;)

https://tools.ietf.org/html/rfc5321#section-5

why is paessler.com not fixing it ?

Dear xpoint,

please clarify. If it gets into detail, you could also get to us directly via support@paessler.com-

We have the same issue.

Dear chi_ltd1,

please enable the debug log for notifications. Do you get more information out of those logs?

Please note that the debug logs should be disabled later, as this extended logging impacts the performance of PRTG, and writes a lot of data to disk.

If the issue persists, please provide more detail, as "the same issue" is not too precise in this context. Thank you!