We’re going to take it back to the basics, because as we grow, we get new batches of partners which in turn comes with a new batch of tech support staff. And let’s face it, their knowledge of mail flow can vary from the guy that can write his own sendmail/postfix custom scripts, to the guy that just had great upbeat personality that most of tech folks lack. So… here we go.

There you are minding your business, possibly catching up on your company allowed tech blogs then your phone lines explode and you hear the dreaded words “We have not received any mail in the past “x” hours!! FIX THIS NOW”! Here at ExchangeDefender, this is easy to handle and you don’t need to call anyone, you don’t need to open and wait for a ticket for 99% of the scenarios.

Step 1

Check the mx record.

From windows:
nslookup -type=mx domain.com

From linux:
dig mx domain.com

From the web:

The one and only result you should get back is:


If you have anything else in there, and you’ve been getting complaints about random mail not arriving, the odds are great that they arrived at the alternative location and got bounced because of IP restrictions. But let’s not get sidetracked.

If there was no mx record in place, that’s your problem. Contact your client’s DNS provider and get inbound30.exchangedefender.com added ASAP. If inbound30 is the one and only record in place, go to step 2.

Step 2

Send a test message from a non ExchangeDefender domain. Here’s why, we route all outbound mail directly to the mail for processing speed so it won’t show up on your client’s mail log, but yours. Once you’ve sent your test message you want to note the from and to address and go to Step 3.

Step 3

Log into https://admin.exchangedefender.com with your Service Provider ID (Hint: it’s not a domain or an email address). Once you’ve logged in, click on Mail Log. Now you can search the Mail Log for your client for the very message you tested with and your answer will be at your finger tips.




You will see a line by line log of the SMTP transaction the most important one being the last one to your delivery IP. Generally, it will tell you exactly what the problem is, ranging from your ISP blocking the port, or a new tech blocking the port from us, or the email server running low on resources it’s all right there.

Blue – The recipient servers and the status returned, if it starts with a 2 it was accepted, if it starts with a 4 it was deferred, if it starts with a 5 it was permanently rejected.

Green – If it was accepted and your end user says they don’t see it. You can search the mail logs on that server for the message ID. (odds are there’s a rule in place if you get this far.)



Carlos Lascano
VP Support Services, ExchangeDefender
(877) 546-0316 x737