none
#550 5.7.1 Client host rejected: cannot find your hostname error when sending to certain domains

    Question

  • Hi, i get the following trying to send a email to certian domains, i think i need to change something on my DNS server but not 100% sure how to go about it. 

    The server's external ip is diffrent than the one i get in the error msg. Error msg has got it as x.x.x.146 and it is x.x.x.148.
    I am in the process of upgrading to exchange 2007.

    Regards

    Delivery has failed to these recipients or distribution lists:

    'ticketman@co.za'

    Your message wasn't delivered because of security policies. Microsoft Exchange will not try to redeliver this message for you. Please provide the following diagnostic text to your system administrator.

    The

    following organization rejected your message: mx2.coza.net.za.

    Sent by

    Microsoft Exchange Server 2007  

    Diagnostic information for administrators:

    Generating

    server: Server.domain.local

    ticketman@co.za

    mx2.coza.net.za #550 5.7.1 Client host rejected: cannot find your hostname, [x.x.x.146] ##

    Monday, August 17, 2009 12:16 PM

Answers

  • Looks like rDNS/PTR record is not configured for your MX record. Verify and configure in Public DNS...
    What is Reverse DNS?
    DNS, Reverse DNS and MX Records

    Amit Tank | MVP – Exchange Server | MCITP: EMA | MCSA: M | http://ExchangeShare.WordPress.com

    • Marked as answer by Danie Claassen Thursday, August 20, 2009 8:43 AM
    Monday, August 17, 2009 12:38 PM
  • You can try Reverse DNS Lookup tool

    • Marked as answer by Danie Claassen Thursday, August 20, 2009 8:43 AM
    Tuesday, August 18, 2009 7:15 AM
  • I found a few handy links:

    You must use the FQDN for the server. If you use .domain.local it look to me like that is what the ptr must point to. Going to update it with .local and will let update here if it does not work.

    Configuring Reverse DNS for Exchange

     

    Having issues sending e-mail to aol.com, hotmail.com, other ISPs and some companies?  If so there is a good chance that a reverse DNS or a PTR record does not exist for the Exchange server, or other server, that is sending your e-mail to the Internet.  About a few months ago I noticed that messages to aol.com were just sitting in the queue.  After the timeout period I would get a NDR messages for these e-mails.  It turns out that the IP address that is actually transmitting the e-mail, in my case a firewall, didn't have a valid PTR record in my ISPs DNS server.

     

    Let me start by going over how messages are transmitted and how DNS actually work, in relation to e-mail.  In most environments a firewall is between the sending mail server and the Internet.  In such a case, the sending mail server might have an IP address of 10.10.10.20 but the external address of the firewall is 206.10.10.10.  When a message is sent out from the mail server it is transmitted though the firewall and the firewall actually establishes the connection with the destination server(s).  If the destination server is configured to do a reverse DNS lookup it will query the DNS server responsible for the 206.10.10.13 IP address.  If this IP address is the property of your ISP, which is normally the case for most organizations, they will have a DNS server that has generic or no reverse lookup (PTR) entries for their IP addresses.  If entries do exist they will normally be something like host-206-10-10-13.adslcustomers.qwest.net.

     

    In most cases multiple DNS servers are actually involved in the transmission of e-mails.  But there are two key ones that provide authoritative information on the host\domain names and IP addresses of mail servers.  One is responsible for responding to the reverse lookup quires by IP, used by the receiving mail server.  The other one responds to forward lookups by host or domain name, used by the sending mail server.  When someone sends e-mail to a domain name, company.com for example, the sending mail server queries its DNS server for the IP addresses of the MX record for company.com.  In most cases, this DNS server will not know about company.com and will need to forward the request to a DNS server that knows about company.com.  Normally this request for information will be sent to the DNS servers hosting the root zone for the Internet, in this case ".com".  The responding root DNS server will then provide the requesting DNS server with the IP address of the DNS server responsible for company.com.  The requesting DNS server will then query that IP address for the MX records for company.com.  The responding DNS server at company.com will then return the IP addresses for the SMTP server, firewall, or device that handles incoming e-mail for company.com.  The sending mail server will then attempt to transmit the message to the MX record entry with the lowest priority.  A single DNS server could be used to handle both forward and reverse DNS queries, if the ARIN and domain registration information is configured correctly, discussed in more detail later.

     

    Given the example above, one or more DNS servers are host records related to the 206.10.10.13 IP address.  These DNS servers should have mail (MX), host (A), and pointer (PTR) records.  When a message is sent from company.com to hotmail.com the receiving server at hotmail.com will do a reverse lookup on the sending IP address, 206.10.10.13.  This query is handled by the DNS server that handles lookups for the 206.10.10.x, or a larger, IP block.  It should then return the PTR record for 206.10.10.13, which should be something like mail.company.com.  For more information see How Reverse DNS Works.  Some receiving mail servers, like hotmail's, and/or spam filtering solutions request this reverse lookup on the sending servers IP address, which is the only thing in a message that can't be spoofed by a spammer.  If a PTR record doesn't exist for the sending IP address the messages maybe blocked or flagged as spam.  In addition, if the PTR record doesn't match the sending servers FQDN, mail.company.com for example, the message may also be blocked or flagged as spam.

     

    Therefore, you need to make sure that the FQDN used by the sending mail server matches the PTR record for the IP address that actually transmits the messages to the Internet.  If you do not own your IP addresses or don't have control over your reverse lookup zone for your IPs you will need to contact your ISP.  I know Qwest.net, my ISP, allows their customers with static IP addresses to create PTR records in their DNS servers or to forward reverse lookups to another DNS server that their customer controls.  The DNS server that handles domain queries can also be hosted by your ISP, the registrar for your domain name, by yourself, or elsewhere.  To find out the DNS server that is handling queries for your domain check your registration information for your domain name at your domain registrar, a minimum of two DNS servers are required by most registrars.  To check the reasonable party for your IPs goto: http://ws.arin.net/whois.  Chances are that your IP address will be owned by a "super ISP" who then leases it to another ISP, who probably then leases it to yet another one.  For example, my IP addresses shows as being owned by Beyond The Network America, Inc, who controls 63.216.0.0   63.223.255.25.  But I know Qwest.net actually controls the reverse DNS servers for my IP addresses.  So Qwest either leases the IP blocks they use from Beyond or another ISP that then leases them from Beyond.

     

    The steps below will cover configuring Exchange to use the correct domain and FQDN values and the configuration of DNS.  These settings will all help prevent e-mail being sent by your servers from being blocked or flagged as spam.  By default Exchange will use the AD domain name that the server exists in.  So if your AD domain name is company.local, Exchange will use <server name>.company.local for the FQDN in all outgoing messages.  This FQDN is put in the header of all messages and is set to the receiving mail server, so it is essential that it is configured correctly.


    Reverse DNS mismatches mark Exchange email as spam

    Configuring Reverse DNS for Exchange
    • Marked as answer by Danie Claassen Thursday, August 20, 2009 8:45 AM
    Thursday, August 20, 2009 8:37 AM

All replies

  • Looks like rDNS/PTR record is not configured for your MX record. Verify and configure in Public DNS...
    What is Reverse DNS?
    DNS, Reverse DNS and MX Records

    Amit Tank | MVP – Exchange Server | MCITP: EMA | MCSA: M | http://ExchangeShare.WordPress.com

    • Marked as answer by Danie Claassen Thursday, August 20, 2009 8:43 AM
    Monday, August 17, 2009 12:38 PM
  • Ok, i added the FQDN to the send connector.

    Havent restarted anyservices but not working yet.

    I thin part of the issue is that the outgoing ip seems to be diffrent than the incoming ip? Is that what the FQDN in the send connector sort out?

    Should i give it some time? 
    What should be in my reverse lookup? I have added a PTR record pointing to the ip x.x.x.148. the email is revering to x.x.x.146
    Monday, August 17, 2009 1:03 PM
  • I guess in that case you can create another MX record with higher priority for 146 ip address with PTR record...

    Amit Tank | MVP – Exchange Server | MCITP: EMA | MCSA: M | http://ExchangeShare.WordPress.com

    Monday, August 17, 2009 1:07 PM
  • ah, maybe that is our problem. 

    Our mail gets forwarded via a ISP to filter ot for spam. From there it gets forwarded to our mail server.

    So if i add another MX record, i dont want to to be routed derectly to our mail server. Should i make the Mail server priority higher? 

    Monday, August 17, 2009 1:12 PM
  • Ok, im getting very confused here.

    This is part of a upgrade. So im in the process off moving everything over to a new box.

    So at the moment there are 3 dns servers.

    DNS1: a DNS server we have out site the organition. Used as the primary DNS
    DNS2: The old domain controller. Still on as the socondary domain controller at the domain authority.
    DNS3: The new Domain controller with Exchange.

    Where will it first look for the MX records and PTR records?
    Monday, August 17, 2009 1:46 PM
  • Well, in that case you have two options, either configure outbound mailflow through ISP or other thing, yes, configure MX record with higher priority so first mails goes to ISP if it is down in that case only it tries to deliver directly...

    Amit Tank | MVP – Exchange Server | MCITP: EMA | MCSA: M | http://ExchangeShare.WordPress.com

    Monday, August 17, 2009 1:47 PM
  • DNS1: a DNS server we have out site the organition. Used as the primary DNS
    DNS2: The old domain controller. Still on as the socondary domain controller at the domain authority.
    DNS3: The new Domain controller with Exchange.
    Which one is public DNS? I think it should be DNS1 which is out side the organization...

    Amit Tank | MVP – Exchange Server | MCITP: EMA | MCSA: M | http://ExchangeShare.WordPress.com

    Monday, August 17, 2009 1:59 PM
  • Yes, DNS1 is the primary/public one.

    So what i have now:

    MX Records:

    Pointing to 196.x.x.146 (IP in Undeliverable mail) with a metric of 20
    Pointing to 196.x.x.148 (Real mail server IP) with metric of 19

    Pointing to spam filters A (Real mail server IP) with metric of 10
    Pointing to spam filters B (Real mail server IP) with metric of 10

    in reverse lookup zones:

    I have added 2 PTR's

    IP 196.x.x.146 pointing to server FQDN
    IP 196.x.x.148 pointing to server FQDN

    Does that look right. Sorry for the stupid questions but i am quite confused as im sitting here.


    Monday, August 17, 2009 2:24 PM
  • Looks fine, so mail tries to any one of the spam filters A or B first, if both of these are not available then it tries to 148 and if all of three are not available then at last it tries to fourth one 146 ip address...

    Amit Tank | MVP – Exchange Server | MCITP: EMA | MCSA: M | http://ExchangeShare.WordPress.com

    Monday, August 17, 2009 3:08 PM
  • Agree with Amit. Usually, such symptom happens when domain doesn’t configure the reserve DNS and attempt to send mails to other that perform Reverse verification

    Tuesday, August 18, 2009 2:39 AM
  • Is there a way i can test it? A tool or something?
    Tuesday, August 18, 2009 6:30 AM
  • You can try Reverse DNS Lookup tool

    • Marked as answer by Danie Claassen Thursday, August 20, 2009 8:43 AM
    Tuesday, August 18, 2009 7:15 AM
  • Ok, so my reverse loopkup zones are somehow not configured correctly...

    how can that be... can i just delete them and recreate? will i lost anything if i do that?

    No reverse DNS entry could be found


    Tuesday, August 18, 2009 9:18 AM
  • Reverse DNS entry is cached, so if you changed it recently, it will not be reflected immediately. And, as said in the articles from Amit, the reverse DNS record shall be added by the ISP. You shall confirm with them whether it has been added properly or not

    Tuesday, August 18, 2009 10:25 AM
  • Graet, i got the reverse DNS setup and it is now resolvong.

    What is exchange looking for in the reverse DNS? Does it want the machine name? i have made it reversedns1 and pointing it in our dns to the right machine?
    Or must it be the machine name? 


    I still get the error so must still be doing something wrong but the reverse dns is resolving.

    Thursday, August 20, 2009 6:53 AM
  • I found a few handy links:

    You must use the FQDN for the server. If you use .domain.local it look to me like that is what the ptr must point to. Going to update it with .local and will let update here if it does not work.

    Configuring Reverse DNS for Exchange

     

    Having issues sending e-mail to aol.com, hotmail.com, other ISPs and some companies?  If so there is a good chance that a reverse DNS or a PTR record does not exist for the Exchange server, or other server, that is sending your e-mail to the Internet.  About a few months ago I noticed that messages to aol.com were just sitting in the queue.  After the timeout period I would get a NDR messages for these e-mails.  It turns out that the IP address that is actually transmitting the e-mail, in my case a firewall, didn't have a valid PTR record in my ISPs DNS server.

     

    Let me start by going over how messages are transmitted and how DNS actually work, in relation to e-mail.  In most environments a firewall is between the sending mail server and the Internet.  In such a case, the sending mail server might have an IP address of 10.10.10.20 but the external address of the firewall is 206.10.10.10.  When a message is sent out from the mail server it is transmitted though the firewall and the firewall actually establishes the connection with the destination server(s).  If the destination server is configured to do a reverse DNS lookup it will query the DNS server responsible for the 206.10.10.13 IP address.  If this IP address is the property of your ISP, which is normally the case for most organizations, they will have a DNS server that has generic or no reverse lookup (PTR) entries for their IP addresses.  If entries do exist they will normally be something like host-206-10-10-13.adslcustomers.qwest.net.

     

    In most cases multiple DNS servers are actually involved in the transmission of e-mails.  But there are two key ones that provide authoritative information on the host\domain names and IP addresses of mail servers.  One is responsible for responding to the reverse lookup quires by IP, used by the receiving mail server.  The other one responds to forward lookups by host or domain name, used by the sending mail server.  When someone sends e-mail to a domain name, company.com for example, the sending mail server queries its DNS server for the IP addresses of the MX record for company.com.  In most cases, this DNS server will not know about company.com and will need to forward the request to a DNS server that knows about company.com.  Normally this request for information will be sent to the DNS servers hosting the root zone for the Internet, in this case ".com".  The responding root DNS server will then provide the requesting DNS server with the IP address of the DNS server responsible for company.com.  The requesting DNS server will then query that IP address for the MX records for company.com.  The responding DNS server at company.com will then return the IP addresses for the SMTP server, firewall, or device that handles incoming e-mail for company.com.  The sending mail server will then attempt to transmit the message to the MX record entry with the lowest priority.  A single DNS server could be used to handle both forward and reverse DNS queries, if the ARIN and domain registration information is configured correctly, discussed in more detail later.

     

    Given the example above, one or more DNS servers are host records related to the 206.10.10.13 IP address.  These DNS servers should have mail (MX), host (A), and pointer (PTR) records.  When a message is sent from company.com to hotmail.com the receiving server at hotmail.com will do a reverse lookup on the sending IP address, 206.10.10.13.  This query is handled by the DNS server that handles lookups for the 206.10.10.x, or a larger, IP block.  It should then return the PTR record for 206.10.10.13, which should be something like mail.company.com.  For more information see How Reverse DNS Works.  Some receiving mail servers, like hotmail's, and/or spam filtering solutions request this reverse lookup on the sending servers IP address, which is the only thing in a message that can't be spoofed by a spammer.  If a PTR record doesn't exist for the sending IP address the messages maybe blocked or flagged as spam.  In addition, if the PTR record doesn't match the sending servers FQDN, mail.company.com for example, the message may also be blocked or flagged as spam.

     

    Therefore, you need to make sure that the FQDN used by the sending mail server matches the PTR record for the IP address that actually transmits the messages to the Internet.  If you do not own your IP addresses or don't have control over your reverse lookup zone for your IPs you will need to contact your ISP.  I know Qwest.net, my ISP, allows their customers with static IP addresses to create PTR records in their DNS servers or to forward reverse lookups to another DNS server that their customer controls.  The DNS server that handles domain queries can also be hosted by your ISP, the registrar for your domain name, by yourself, or elsewhere.  To find out the DNS server that is handling queries for your domain check your registration information for your domain name at your domain registrar, a minimum of two DNS servers are required by most registrars.  To check the reasonable party for your IPs goto: http://ws.arin.net/whois.  Chances are that your IP address will be owned by a "super ISP" who then leases it to another ISP, who probably then leases it to yet another one.  For example, my IP addresses shows as being owned by Beyond The Network America, Inc, who controls 63.216.0.0   63.223.255.25.  But I know Qwest.net actually controls the reverse DNS servers for my IP addresses.  So Qwest either leases the IP blocks they use from Beyond or another ISP that then leases them from Beyond.

     

    The steps below will cover configuring Exchange to use the correct domain and FQDN values and the configuration of DNS.  These settings will all help prevent e-mail being sent by your servers from being blocked or flagged as spam.  By default Exchange will use the AD domain name that the server exists in.  So if your AD domain name is company.local, Exchange will use <server name>.company.local for the FQDN in all outgoing messages.  This FQDN is put in the header of all messages and is set to the receiving mail server, so it is essential that it is configured correctly.


    Reverse DNS mismatches mark Exchange email as spam

    Configuring Reverse DNS for Exchange
    • Marked as answer by Danie Claassen Thursday, August 20, 2009 8:45 AM
    Thursday, August 20, 2009 8:37 AM
  • Great you found the cause, the following is just some additional information about reverse DNS record for you

    Some e-mail systems, such as Microsoft Hotmail®, will not accept e-mail from organizations that do not have reverse DNS records. If you want your users to be able to send e-mail to these systems, be sure to create a reverse DNS record. If your ISP manages your DNS records, your ISP must create this record for you

    -----------Refer to <Post-Installation Steps for Exchange Server 2003>

    External domains’ mail systems may require to perform reverse DNS lookup for incoming messages in order to prevent them from receiving spam, so they try to verify that your Internet-facing exchange server's IP address matches the host and domain that is submitted by the server in the EHLO/HELO command

    Thursday, August 20, 2009 9:00 AM
  • Well i hope so but im definatly getting there. Will have to wait a while for the server to update.

    In the Diagnostics Information it revers to the server: Server.domain.local. I told my ISP to create the PTR record for the same(.local) and not .com. Do i understand that correctly?
     "So if your AD domain name is company.local, Exchange will use <server name>.company.local for the FQDN in all outgoing messages.  This FQDN is put in the header of all messages and is set to the receiving mail server, so it is essential that it is configured correctly."

    And then what still might be a issue is that the server sits behind x.x.x.148 and not x.x.x.146 as in the failed report on returing emails.

    They created pointer records on both ip's pointing to the exchange server.
     
    Thursday, August 20, 2009 9:09 AM
  • Unfortunately, I think that you shall create PTR for your registered domain name on the Internet.  .Local is invalid on the Internet.This also mentioned in the bottom of the article that you posted

    Thursday, August 20, 2009 9:22 AM
  • Ok, they dont really say what the correct way is.... or im misinterpriting it.

    I thaught they mean you must use .domain.local... Will just give it a few hours to propagate and then maybe change it.

    Does anyone know for sure if it must be .local or .com?

    Thanks
    Thursday, August 20, 2009 9:48 AM
  • Ok, the ptr is pointing to server.domain.com and still not working.

    The error msg in the returning email still say server.domain.local.

    I did change the send connector to .com ...

    There is 2 send connectors, one for the old server (exch2003) and one for the new server... Should there b 2?

    Friday, August 21, 2009 11:49 AM
  • Why would the NDR return with the wrong the IP address in the first time? Please contact the ISP and check it out

    Monday, August 24, 2009 1:47 AM
  • Hi

    Will you suggest me where need to be changed at our local DNS or PUBLIC DNS or any other places.

    Regards

    Md Ehteshamuddin Khan

    Tuesday, July 10, 2012 7:06 AM