<

[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x

Problems sending mail to one or more external domains

Published on
81,622 Points
20,622 Views
40 Endorsements
Last Modified:
Approved
I have seen a lot of questions on EE where there have been problems sending out emails to one or more external email domains and most issues can be resolved fairly simply by checking to see that your Mail Server configuration is setup optimally and that your domains DNS records are setup correctly (where your domain is registered - not internally in your own server's DNS records).

If you face problems sending out mail, but only to a handful of domains, please run through the following checks / tests and make sure your environment is setup properly:

Reverse DNS:

Check your domain on http://www.dnsgoodies.com/ and see if you have a Reverse DNS pointer setup with a proper FQDN, not an ISP generic one.  If you do not have one setup - call your Internet Service Provider (ISP) and ask them to set one up to match the Fully Qualified Domain Name (FQDN) that your mail server responds as e.g., mail.yourcompany.com.  Also, your mailserver FQDN should also be setup with something like mail.yourcompany.com.  Any FQDN ending in .local or .internal or anything that is not a valid Internet Domain Name is not correct and should be changed otherwise you may experience problems sending out emails to some domains.

To get your ISP to setup Reverse DNS on your Fixed IP Address, there must be a corresponding A record configured in your DNS records (at your Domain Registrar) that resolves the name you want added, to the IP Address.  If such a record doesn't exist, then the ISP won't set it up for you!

A simple test from a DOS Prompt (Command Prompt) will help here:

nslookup mail.yourdomain.com

This should return your Public IP Address e.g., 123.123.123.123

Then if you run the following command:

nslookup 123.123.123.123

It will return your Reverse DNS record.  If it says mail.yourdomain.com (or at least if it matches what you type in the first time) then you are good to go.

Blacklists:

Check that your IP address is not listed on any Blacklists on http://www.mxtoolbox.com/blacklists.aspx and http://www.blacklistalert.org/ - If you appear on any blacklists, then you may have problems sending mail to some domains who check against blacklists (not everyone does, but a lot do). Follow the links on the results page to the particular blacklist site to find out the reason why you are listed (you may have an infected computer sending out spam that you are not aware of) and then deal with the issue before requesting removal from those blacklists (if you don't deal with the problem, such as an infected computer, you will get removed from the blacklist, but will only re-appear again as more spam is sent out).  Once you know what you are facing, you can resolve the problem.

If you are blacklisted - configure your firewall / router to block all traffic on TCP Port 25 Outbound from all IP addresses apart from your Mail Server.  This should reduce the possibility of an infection from getting you blacklisted further and will help prevent getting listed again once you have cleaned up your network.

IP Reputation:

Check your IP reputation on Senderbase http://www.senderbase.org.  You will either be Good, Neutral or Poor.  If your reputation is Poor - then you may have problems sending out mail and are most likely appearing on a blacklist or two somewhere.  If you are Neutral, then you may have had a problem in the recent past and are still recovering your reputation.  If you have a Good reputation, you should have no problems sending out emails.

SPF Record (Sender Policy Framework):

Check to see if you have an SPF (Sender Policy Framework) record setup on http://www.mxtoolbox.com/spf.aspx - If you do not have a record setup, visit http://old.openspf.org/wizard.html, run through the various options carefully and then you should see your SPF record in the final box at the bottom of the screen.  Once you have an SPF record, you have to publish this record in your Domains DNS records by adding a TXT record with the SPF record as the data e.g., Type=TXT Record=(output from http://old.openspf.org/wizard.html).  An alternative site to the openspf.org site that you can use is http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/ .

It is far better not to have an SPF record, than it is to have an incorrect one.  Not having an SPF record won't get your emails rejected, but a badly configured on will.

SPF records essentially tell the world which IP Address(es) / Mail Server(s) are permitted to send out mail on behalf of your domain.  If you send out mail from an IP Address that isn't permitted / included in your SPF record, don't be surprised if your emails get rejected and don't blame the recipient server for rejecting you.

General:

If you send out mail from a different IP address to the advertised MX record IP Address, please check that the Reverse DNS entry for this IP Address is also configured properly and that it resolves correctly to the same IP address on http://www.dnsgoodies.com/.  As an example, if you send mail out via IP 123.123.123.123 and the Reverse DNS entry setup on this IP address by your ISP is mail.yourcompany.com then mail.yourcompany.com should also resolve in DNS back to the same 123.123.123.123 IP Address.

Having checked all of the above and made any corrections to your configuration, your mail should be flowing better.  If it is not and your house is now in order, you are not listed on any blacklists and you still have problems sending out mail to one or more domains, then it may be that the external domain may be specifically blocking you, (Hotmail are quite good at doing this for no particularly good reason) you will need to contact them to try to resolve the issue.
40
Comment
14 Comments
 
LVL 11

Expert Comment

by:manav08
Hi Alan,

Good article!! You have my vote.
One thing I recommend you add is open relay checking via a site like www.abuse.net/relay.html. So that people can determine if this is the cause for them being listed in the SPAM DATABASE. Also another great site apart from MXTOOLBOX is www.dnsbl.info
0
 
LVL 23

Expert Comment

by:Malli Boppe
Great article
0
 

Expert Comment

by:Lisaa_G
Thanks - this is very useful!
0
Fill in the form and get your FREE NFR key NOW!

Veeam is happy to provide a FREE NFR server license to certified engineers, trainers, and bloggers.  It allows for the non‑production use of Veeam Agent for Microsoft Windows. This license is valid for five workstations and two servers.

 
LVL 44

Expert Comment

by:Amit
Great Article Sir. I have voted.
0
 
LVL 76

Author Comment

by:Alan Hardisty
Thanks very much.

Alan
0
 
LVL 23

Expert Comment

by:Suliman Abu Kharroub
Thanks !
0
 
LVL 76

Author Comment

by:Alan Hardisty
You are welcome - thanks for the Yes vote :)
0
 
LVL 23

Expert Comment

by:Suliman Abu Kharroub
I have a question related to this topic:

when I fill the FQDN in the send connector properties, why could telnet ehlo respond with the internal name ?

Please help.

Thanks again.
0
 
LVL 76

Author Comment

by:Alan Hardisty
What version of Exchange?
0
 
LVL 23

Expert Comment

by:Suliman Abu Kharroub
Exchange 2010 no SP installed.
0
 
LVL 76

Author Comment

by:Alan Hardisty
Telnet will connect to the Receive Connector, not the Send connector, so you can ignore the FQDN as the name isn't relevant and no-one cares what you have on that!
0
 
LVL 23

Expert Comment

by:Suliman Abu Kharroub
So to make the external FQDN appears in the ehlo respond, it should be filled in the receive connector not the send connector properties.


I think Microsoft should change the description of that setting in the send connector properties to something more relevant.

Once again, thanks Alan :)
0
 
LVL 76

Author Comment

by:Alan Hardisty
Yes - but there really isn't any need to change it as it is only seen by sending servers and they don't care what name you put there.

If you run a domain report, it will report on the Receive Connector, so errors can be ignored.
0
 
LVL 2

Expert Comment

by:Peter Wilson
Good article!
0

Featured Post

Free learning courses: Active Directory Deep Dive

Get a firm grasp on your IT environment when you learn Active Directory best practices with Veeam! Watch all, or choose any amount, of this three-part webinar series to improve your skills. From the basics to virtualization and backup, we got you covered.

Join & Write a Comment

In this video we show how to create an Accepted Domain in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center. Navigate to the Mail Flow >> Ac…
In this video we show how to create an email address policy in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.:  First we need to log into the Exchange Admin Center. Navigate to the Mail Flow…
Suggested Courses
Course of the Month19 days, 9 hours left to enroll

Keep in touch with Experts Exchange

Tech news and trends delivered to your inbox every month