In order to minimize false positives due to connection problems by our monitoring services, we ask that you please whitelist these IP ranges on your firewall or network security systems:

• 44.194.168.193
• 52.55.244.91
• 18.205.72.90
• 18.209.86.113

You can see details about different warnings and errors from our tools on the Problem Details page.

To delete a monitor from the dashboard, follow these steps:

You can see details about different warnings and errors from our tools on the DNS Problem Details page.

We recommend that you contact your Domain's Registrar to update the name servers on record to include the server that is not listed at the Root Servers.

------------------------------------

Your Primary Name Server was not on the list of name servers given to us by the root.

If your name server is not listed at the root, it could cause impaired/incorrect lookups for your domain.

The Primary Name Server is the name server declared in your SOA file and is usually the name server that reads your records from zone files and is responsible for distributing that data to your secondary name servers. This problem is present when this primary name server is not included in the parent referrals and is almost always accompanied by a Local Parent Mismatch problem.

RFC 1035:

Here a primary name server acquires information about one or more zones by reading master files from its local file system, and answers queries about those zones that arrive from foreign resolvers. [RFC 1035]

If your Primary Name Server is not listed at your Parent or is not responding, then our DNS Propagation test tool will not operate properly. You will most likely also be experiencing other real-world problems with DNS queries for your domain. Users with Basic or Pro accounts can contact our Support Team for assistance with understanding any DNS warnings or errors with specific information about your domain. If you are still a free user, upgrading your account will give you access to support, as well as many other benefits.

Have a great day!

If you receive a DNS change alert from MxToolbox because of TTL changes, no need to panic. These incidents are typically caused by issues at your DNS hosting provider.

DNS TTL (time to live) is a setting that tells your DNS resolver how long to cache a query before requesting a new query. The gathered information is then stored in the cache of the recursive or local resolver for the TTL before it collects new, updated details.

For example, if your DNS TTL is set to 3,600 seconds (60 minutes), the DNS resolver will have to regather the details of a website (mxtoolbox.com) every hour. If 100 users visit our site during that time, they will all see the same visual until the resolvers update their TTL.

The TTL acts as a stopwatch for how long to keep a DNS record because it represents the time each step takes for DNS to cache a record. Recorded in seconds, using the best TTL time for your situation is key to your site's overall responsiveness.

MxToolbox often sees warning signs of issues and outages at DNS providers. Nearly every case is a problem with the specific DNS provider. For example, this outage occurred on May 5th, 2021, and affected customers' domain DNS servers: DNS outage.

To check the propagation of DNS records across your servers and see the selected TTLs, use our DNS Propagation Tool.

If you are receiving alerts for your Mailflow monitor and you are still able to send and receive email, chances are we did not receive a test message back to our system.

Click on the monitor and let it populate in the right window of the page. Under the graph you will see Outages | History | Pings | Edit > Click on Pings.

There are two (2) different results under the Pings table.

1. A message with a Green Check is a successful message returned to us. You can click on the details link and it will provide you the full headers and more information about the test message.
2. A message with a Red X on it is a failed message. If you click on Error, this will show you the test message's subject.

If the message is failing:

• Use the message subject to check that it is not being filtering by an inbound appliance or spam software.
• Use the message subject to check your outbound SMTP logs to see if the message is leaving your gateway.

The reverse IP address name (PTR) is not contained in the server HELO or EHLO banner. In the example below, the string "someotherdomain.com" is not found anywhere in the server banner, which is reporting "example.com". This is only a warning, and in some cases you might not have control over it.

Example of incorrectly matching pair:

220 mx.example.com StrongMail SMTP Service at Wed, 09 Sep 2009 17:00:01 -0700

When a sending server makes a connection to the recipient server, the recipient server notes the sending IP address and performs a reverse lookup. This is done by sending a DNS query, which returns a Fully Qualified Domain Name (FQDN) registered for that IP address. If the sending SMTP address matches the domain, then it is much more likely that the message is legitimate and, therefore, will be passed on to the recipient. If the IP address does not match, it is much more likely that the sending address was spoofed and, therefore, much more likely that it is unwanted and could be considered spam.

A Fully Qualified Domain Name (FQDN) is associated to an IP with a valid PTR record. You want the domain name portion of the FQDN to match the domain of your email address (e.g., If your sending addresses follow the convention of name@mydomain.com, your PTR record should contain something like mailserver.mydomain.com). Only the organization that controls and owns the IP can set a PTR record. PTR record queries are sent to the owner of the IP address, which is the ISP, unlike other DNS queries which are sent to the DNS server of whoever owns the domain. For this reason, setting a PTR record on your own DNS servers is essentially useless since no one is asking your servers.

To make any changes to your rDNS, you will need to contact your ISP. Or, if you host your own DNS (rare), you will adjust it yourself. You will not be able to do this in your DNS control panel unless your ISP also hosts your DNS and gives you the functionality to add your own rDNS records.

To ensure that you receive MxToolbox's Notifications and Summary emails, please whitelist the following two IPs:

• 143.55.235.77
• 209.61.151.222

Unfortunately, SendGrid is now instructing its customers to add a DMARC TXT Record "v=DMARC1; p=none" when configuring Sender Authentication. SendGrid's page provided to customers from 3rd-Party Vendors is NOT allowing the verification to happen and the vendor needs to verify that MxToolbox's DMARC CNAME setup is correct.

If you use SendGrid and encounter a step to create a DMARC TXT Record during Sender Authentication, MxToolbox offers the following DMARC Integration option:

• DMARC Integration for Delivery Center:

If you are already set up for DMARC with us, your vendor simply needs to verify the Sender Authentication without the replacement or modification of the DMARC Record currently set up. Then, you are good to go.

If you are NOT already set up for DMARC with us, use the above DMARC Integration for improved email delivery. After the integration is complete, your vendor needs to verify the Sender Authentication without the replacement or modification of the DMARC Record currently set up.

For DMARC setup assistance, please contact our expert Support Team.