Questions

Returned E-mail-(helo/hostname mismatch)

+
0 Votes
Locked

Returned E-mail-(helo/hostname mismatch)

Wapiti10
I have a user that received a bounce back with the following:

"Recipient address rejected: Mail appeared to be SPAM or forged. Ask your Mail/DNS-Administrator to corect HELO and DNS MX settings or to get removed from DNSBLs;"

I am using Exchange 2003 with a Front End Web Server.
the MTA HELO resolved as my Server name, and the MTA hostname resolved as my OWA URL.

is this something I can fix on my end, or do I simply need to request to be taken off of their Black List?

thanks
+
0 Votes
Churdoo

In ESM,

your administrative group / Servers / your server / protocols / SMTP / default SMTP virtual server (or the applicable virtual server) / properties / Delivery tab / Advanced button / make "Fully -qualified domain name" = the public DNS name of your server (matching the A record and PTR record)

+
0 Votes
Wapiti10

thanks for the reply...I want to make sure I understand, I have 3 FQDN's.
1.Backend_Server.domain.com
2.Frontend_Server.domain.com
3.OWA.domain.com

right now the FQDN field you referenced is "backend_server.domain.com" should it be something else? my Smart host is set to Frontend_Server.domain.com. If I am to understand, are you stating that the FQDN under advanced delivery should be OWA.domain.com?

thanks in advance for your help.

+
0 Votes
Churdoo

If you have a backend/frontend, then leave your backend server alone -- this is not the part that's causing you grief. The frontend server however, the one that actually connects via SMTP to external servers is the one for which you have to modify the reported FQDN of its SMTP virtual server.

What you enter into this field depends ...

For the best chance of not being flagged as spam from a receiving SMTP server, you want a PTR record resolving your SMTP server's PUB IP to an FQDN within your public email domain, then you want a corresponding A record in your public email domain's zone matching the same IP. It is this FQDN referenced in the PTR and A records that you want entered in the frontend server's SMTP virtual server properties FQDN field.

If you have an MX record which causes email to be delivered directly to your FE server (opposed to using an outside service to filter email then deliver to your frontend server), then presumably you would create a corresponding PTR record for the FQDN referenced in your MX record (the PTR record by the way, is likely maintained by your ISP) and use this same FQDN in your SMTP virtual server properties

Does that make sense or still confusing?