New Question
 
 
PRTG Network Monitor

Intuitive to Use.
Easy to manage.

200.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free PRTG
Download >>

 

What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

 

Top Tags


View all Tags


MX Server Error Message

Votes:

0

Your Vote:

Up

Down

Receive an error message when testing email notification. Using the built in SMTP function (no external SMTP relay).

Have read previous posts but the answer to previous posts is just a link to the manual. If I could figure it out from the manual, wouldn't be posting here.......

Error message reads,

"Status Sending Email: DNS Server 75.75.75.75 Email "xxxxx@gmail.com" Can Not connect to MX Servers for address xxxxx@gmail.com"

Message repeats with the secondary DNS address.

I've disabled the firewall and anti-virus software to make sure they are not interfering.

The 75.75.75.75 DNS address is used by my ISP.

mx-server prtg smtp

Created on Sep 6, 2013 1:14:41 AM by  ksouthard (0) 1



25 Replies

Votes:

0

Your Vote:

Up

Down

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.

Created on Sep 6, 2013 9:08:15 AM by  Patrick Hutter [Paessler Support] (7,164) 3 3



Votes:

0

Your Vote:

Up

Down

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.

Created on Sep 6, 2013 5:09:46 PM by  ksouthard (0) 1



Votes:

0

Your Vote:

Up

Down

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?).

Created on Sep 9, 2013 9:19:32 AM by  Patrick Hutter [Paessler Support] (7,164) 3 3



Votes:

0

Your Vote:

Up

Down

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,

Created on Jun 23, 2016 7:21:47 PM by  lhaus (0)



Votes:

0

Your Vote:

Up

Down

@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

Created on Jun 24, 2016 9:16:46 AM by  Konstantin Wolff [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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 : )

Created on Mar 19, 2017 1:18:37 AM by  syscom (0)



Votes:

0

Your Vote:

Up

Down

Thanks for sharing! :)

Created on Mar 20, 2017 6:37:26 AM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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.

Created on Jul 3, 2017 8:00:01 PM by  safvat (0)

Last change on Jul 4, 2017 8:20:52 AM by  Luciano Lingnau [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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.

Created on Jul 4, 2017 12:18:48 PM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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?

Created on Jul 5, 2017 12:46:45 PM by  safvat (0)



Votes:

0

Your Vote:

Up

Down

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)"?

Created on Jul 6, 2017 5:05:10 PM by  Arne Seifert [Paessler Support]

Last change on Jul 6, 2017 5:05:25 PM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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)".

Created on Jul 6, 2017 7:33:58 PM by  Ilya (0)



Votes:

0

Your Vote:

Up

Down

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

Created on Jul 7, 2017 12:35:10 PM by  Dieter Loskarn [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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.

Created on Jul 7, 2017 4:13:13 PM by  Ilya (0)



Votes:

0

Your Vote:

Up

Down

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.

Created on Jul 7, 2017 7:37:13 PM by  safvat (0)

Last change on Jul 10, 2017 6:35:48 AM by  Luciano Lingnau [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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.

Created on Jul 10, 2017 1:55:01 PM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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.

Created on Jul 11, 2017 5:24:19 PM by  safvat (0)



Votes:

0

Your Vote:

Up

Down

Dear safvat

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

Created on Jul 12, 2017 12:45:33 PM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Any updates on this issue

Created on Jul 15, 2017 1:51:59 AM by  Ilya (0)



Votes:

0

Your Vote:

Up

Down

Dear Ilya

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

Created on Jul 17, 2017 11:54:44 AM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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 ;)

Created on Oct 8, 2017 9:51:03 PM by  Byron (0)



Votes:

0

Your Vote:

Up

Down

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

why is paessler.com not fixing it ?

Created on Apr 26, 2018 1:39:29 PM by  xpoint (0)



Votes:

0

Your Vote:

Up

Down

Dear xpoint,

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

Created on Apr 26, 2018 3:51:22 PM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

We have the same issue.

Created on Oct 4, 2018 2:39:04 PM by  chi_ltd1 (0)



Votes:

0

Your Vote:

Up

Down

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!

Created on Oct 4, 2018 8:00:27 PM by  Arne Seifert [Paessler Support]



Please log in or register to enter your reply.


Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.