Your title says your email is being blocked by hotmail.com but in one of your comments to Stony's answer you state that your SMTP log shows "RCPT=OK" and "RECV=OK" when sending email to hotmail.com. That in and of itself should be telling you that your email is not being blocked. It's being accepted by hotmail.com and is most likely being filtered after being accepted. there's a difference between an email being blocked/rejected and being filtered after being accepted.
You state that you can't telnet to port 25 of mail.hotmail.com. That's because mail.hotmail.com is not an MX for hotmail.com. A quick nslookup shows the following MX records for hotmail.com: mx1.hotmail.com, mx2.hotmail.com, mx3.hotmail.com, and mx4.hotmail.com.
You state that you can't ping hotmail.com but you can ping gmail.com. It's irrelevant whether or not you can ping hotmail.com or any other server, name, web site, etc. The ping tool doesn't test the availability of a service (web, email, etc). The fact that you can't ping hotmail.com only means that the hosts that hotmail.com resolve to don't respond to pings or that a firewall is blocking those pings. It's totally irrelevant to the problem. In addition, pinging hotmail.com has nothing to do with the MX records for hotmail.com. Hotmail.com is the domain name and pinging hotmail.com is pinging the A records configured for that domain name. When you ping gmail.com you're pinging the A record for that domain name, you're not pinging the MX records for gmail.com.
Have a look at the Hotmail Postmaster page here to see if there's anything you need to look in to:
http://mail.live.com/mail/troubleshooting.aspx
The FQDN presented by the MTA to remote servers should match the server's internet FQDN; I'm surprised that hosts rejecting your mail before started accepting it when using localhost
.
There are a few things that go into this, and what gets checked varies wildly from one mail server to another.
What you're likely running into is a check on the reverse-lookup (PTR
) DNS records for your IP:
- Some mail servers expect that a reverse lookup matches exactly to the FQDN you sent with your
EHLO
command.
- Some servers also expect that that FQDN resolves back to the IP address of your sending server.
- But, servers with that level of strictness are rare. More often, they will verify that your reverse entry (say,
mail1.mydomain.com
) is a child of the domain you're attempting to send mail from (say, user@mydomain.com
).
So, if you're in a position to be able to control your reverse DNS (if it's not a commercial internet connection with a static address, you may not be) then get your PTR record set up, and match it to the forward DNS of the server that's sending.
The other aspect to this is the SPF record. Many mail servers will use this as an alternative to that reverse-lookup checking when it's available, or at least as an additional factor in the consideration of whether to drop a message. Tons of info here, the short version is you'll create a DNS record of type TXT
in your domain, which will contain something like this:
v=spf1 mx -all
which will allow the devices in your MX records to send, or this:
v=spf1 ip4:x.x.x.x -all
where x.x.x.x
is your server's public IP address. Even if you don't have the ability to work with your reverse entries, an SPF record should help a good amount.
On the subject of using your ISP's relayers, that's not terribly relevant when you're operating your own mail domain.. I don't think most ISP's relayers will accept mail that's not from their own domain in this day and age. To clarify, those would be from whoever is providing your internet connection, not DynDNS.
Best Answer
I have tried multiple approaches with the HELO/EHLO checking with a fairly decent sized customer base of between 100k-200k users and ended up going with a solution that does the following:
Here's the Postfix block we use for these checks: