Im not sure, but I believe along with correcting the reverse dns lookup (see below) you also need to set a fully qualified domain name (FQDN) for EasyMail SMTP Express. Usually, EasyMail will use the name of the server as the FQDN. An example, my server is dyna-web, so the error message is <DYNA-WEB>: Helo command rejected: need fully-qualified hostname. To override EasyMail's FQDN see http://www.enewsletterpro.com/support/changefqdn.asp which says:

 By default SMTP Express uses the FQDN assigned to the computer itself.  However, you can make a change in the registry to have a different FQDN added to the email headers. To change the registry, do the following:

   1. Launch Regedit by choose Run on the Windows start menu then entering "Regedit".
   2. Expand the following item:
      HKEY_LOCAL_MACHINE\SOFTWARE\Quiksoft\EasyMail SMTP Express
       
   3. Right click and select New String Value.
      
   4. Enter a name of HostName.
   5. Now double-click on HostName and under Value Data enter the FQDN you wish to use.  For example:

      myserver.somedomain.com

A MX record (Mail Exchange) is used to define the actual SMTP mail server responsible for receiving mail sent to a certian domain. Not for sending. So if someone sends mail to x@dynatronsoftware.com it does not use dynatronsoftware.com's IP address as the mail server, it looks up the MX record and in my case finds po.dynatronsoftware.com which is my exchange mail server, so the mail is sent there (po.dynatronsoftware.com).

The rDNS and IP's must match, see 'Fix RDNS Issue below'

The SPF TXT records are setup on the dynatronsoftware.com DNS. It is a list of all IP's that can send mail FROM dynatronsoftware.com So all 7 of our servers IP addresses are listed in dynatronsoftware.com's SPF records.

The A record is simply the IP address of a domain name. So the A record for dynatronsoftware.com is 216.253.190.244. A simple ping of a domain name will use the A record to get it's IP. The rDNS PTR record is the opposite of this.

The PTR record is the opposite of the A record. It is the domain name of an IP address. So nslookup PTR of 216.253.190.244 is mail.dynatronsoftware.com. Used for rDNS (get name from IP). PTR records are usually adjust by the one who owns the IP, usually your Internet Service Provider, in my case its Time Warner Business Cable.

See http://support.google.com/a/bin/answer.py?hl=en&answer=48090 for a basic overview

So I am dynatronsoftware.com, but I want to send mail using SMTP express as a different FROM address, lets say new.com. I want the people at new.com to get all replies, so new.com MX should be mail.new.com which points to THEIR SMTP servers A record (say x.200)

Lets say web6 is x.60. Web6 is setup as usual, the IP is x.60, the PTR is mail.dynatronsoftware.com which points to the exchange server of x.100. The x.100 goes back to mail.dynatronsoftware.com as PTR. So this is all good. Now when sending mail as new.com I don't need to change any PTR stuff. What I have to do is allow x.60 to send mail on behalf of new.com, so I need to add x.60 to new.com's SPF TXT record (do this in new.com's DNS).

So now rDNS is still satisfied, even though it's still mail.dynatronsoftware.com PTR (note, cannot have multiple PTR records for one IP). And MX is THEIR mail server so all replies will goto them. And my web6 x.60 IP is allowed to send mail FROM new.com because of the SPF TXT records.

When you receive a BOGUS HELO message in your email bounces, this means that the Reverse DNS lookup on the sending servers IP failed to resolve back to the correct name.

Many email providers will not accept email from mail servers that don't have a correct reverse dns (rDNS) lookup.

When one of your servers sends an email, spam blockers will look at your servers IP (not the name). So lets say machine x.100 (the external IP) sends an email. Blockers will do a rDNS query on that IP (which gets the name assigned to that IP by your PTR record). So lets say an rDNS returns mail.domain.com (this is the PTR record for that IP), ok, the blockers will then run a query on mail.domain.com, if that query returns x.100 then your good (rDNS is good not spam), if not, the blocker will continue checking with the returned IP. Lets say it returned x.200, the blockers will rDNS x.200, if that goes to mail.domain.com your good, if not it will continue... I don't know how many times it will continue, but in our case we had a continuous loop, example:

say our server sending mail is x.100
say our mail servers of mail.dynatronsoftware.com is at x.244

x.100 resolves to mail.dynatronsoftware.com (good, this is our correct PTR record for that IP)
mail.dynatronsoftware.com resolves to x.244
x.244 resolves to dynatronsoftware.com (this is not the same as mail.dynatronsoftware.com)
dynatronsoftware.com resolves to x.51 (a different machine that hosts our website)
x.51 resolves to mail.dynatronsoftware.com
and you have a loop, back to x.244...

This is a perfect example of invalid reverse dns records.

What we want is this:

x.100 resolves to mail.dynatronsoftware.com
mail.dynatronsoftware.com resolves to x.244
x.244 resolves to mail.dynatronsoftware.com

So all we had to do is changes our PTR (rdns record) for x.244 from dynatronsoftware.com to mail.dynatronsoftware.com

A nice article, where I learned most of this, can be found at http://forums.serverbeach.com/archive/index.php/t-7153.html

Tools: http://www.dnstools.com/
start with your servers IP (the server sending the mail, in my case the external ip for dyna-web4)
then click it's resolved name, then that names resolved IP... until it stops (ie: name and ip resolves to each other)

A bogus helo occures when the returned helo DNS name and IP don't match. If you ping the name, you must get the IP back, and if you nslookup the IP, you must get the correct name back.

Most places do NOT regard a bogus helo email as spam, therefore it is usually not a problem. However, there are some prividers, like the ones who host spsdfw.com that do regard these emails as spam.

We have a server (web2) that was sending emails to wherever, FROM xxxx@dynatronsoftware.com. Which means, the privider checking for spam looked at dynatronsoftware.com, not the IP of the originating mail (web2). So the bogus helo problem must be fixed at the server dynatronsoftware.com, not web2. Now dynatronsoftware.com goes to some host in china as our website, but we handle our mail server (anything@dynatronsoftware.com). So po.dynatronsoftware.com goes to our inhouse server, so this server is our problem.

When I did a

telnet po.dynatronsoftware.com 25
Helo dynatronsoftware.com

250 dynatronsoftware.com Hello [216.xxx].

Which is the problem, because 216.xxx is the IP address of po.dynatronsoftware.com, not dynatronsoftware.com which results in a bogus helo. Again, like I said up top, the name and the IP must match. So in exchange I changed the fully qualified domain name (FQDN) from the old invalid dynatronsoftware.com, to po.dynatronsoftware.com, now a telnet results in

250 po.dynatronsoftware.com Hello [216.xxx].

which is valid, because pinging po.dynatronsoftware.com gives 216.xxx and a reverse DNS lookup (nslookup) on 216.xxx gives po.dynatronsoftware.com

When spsdfw.com started blocking this, they gave a URL in the bounce email where I could enter my IP and they would unblock, I tried several times and they kept refusing, until I found and fixed the FQDN issue above, I then requested removal again, and it went through immediately.

Solved