We currently have a couple of delivery type failures that can be somewhat difficult to troubleshoot so we've put together some steps to identify the issue. 

  1. The first issue revolves around a DNS lookup issue regarding QuadA or AAAA lookups and wildcard records
    • Summary of the issue:
      • Outbound FOPE server queries MX record for contoso.com response is mail.contoso.com
      • Outbound FOPE server queries AAAA record for mail.contoso.com (Default Exchange 2010 behaviour required for IPv6) response is that AAAA record does not exist but an additional record A mail.contso.com is generated and sent in the response pointing to the IP address of the wildcard * for contoso.com (in the cases we have seen this wildcard points to the web server and not the IP of the actual A record for mail.contoso.com)
      • Since there is already a cached response pointing to A mail.contoso.com the server does not do a specific new DNS query for A mail.contoso.com and uses the wildcard generated response which results in failed connection for mail delivery and subsequent deferrals until the email eventually times out and sends an NDR to the sender.
    • How to verify this is the issue:
      • Lookup the nameservers for the recipient domain "nslookup -q=ns contoso.com"  this will typically result in a list of nameservers ns1.contoso.com etc..
      • Lookup the mx record for the recipient domain "nslookup -q=mx contoso.com" this should result in something like MX preference = 10, mail exchanger = mail.contoso.com along with others (we want to chose the one with the lowest preference #)
      • Now we need to chain results from those two together in a more complicated query to see what a QuadA or AAAA query returns the query will look like the following "nslookup -d2 -q=aaaa mail.contoso.com ns1.contoso.com"  This will produce several pages of results but the important thing is at the very end if we see a section that says "ADDITIONAL RECORDS" which contains mail.contoso.com type = a internet address =x.x.x.x we need to mark down this x.x.x.x.
      • Run a query for the following "nslookup -q=a mail.contoso.com ns1.contoso.com" this should result in a mail.contoso.com and a corresponding ip address y.y.y.y.
      • Compare the IP x.x.x.x to the IP y.y.y.y and verify if they match or not.. if they don't then we have a problem with the wildcard overriding the actual A name IP for the mail.contoso.com record.
    • Fixes/Mitigations
      • Primarily the DNS server responsible for this issue needs to be fixed as this is a logic issue before generating an additional record based on the wildcard they should check to see if the record they are going to generate actually exists and utilize that record instead in the additional records section.
      • The wildcard record could be removed for the domain which would also fix the issue
      • The AAAA record could be created using an IPv4-mapped IPv6 address (see http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses for more information) pointing to the IPv4 address of their MTA
  2. Another issue is regarding MX records that point to C-Name records
    • Summary of the issue:
      • Outbound FOPE server queries MX record for contoso.com response is mail.contoso.com
      • Outbound FOPE server queries for AAAA record followed by A record query for mail.contso.com either one of these results in a response where an A name is not returned but rather a CNAME for mail.contoso.com pointing to mail2.contoso.com or some other resource record in general
      • Since this is non RFC compliant with RFC 2181 Section 10.3 "the value of a MX resource must not be an alias" the Outbound FOPE server does not attempt to follow through with this invalid configuration and send to any specified system.
    • How to verify this is the issue:
      • Lookup the nameservers for the recipient domain "nslookup -q=ns contoso.com"  this will typically result in a list of nameservers ns1.contoso.com etc..
      • Lookup the mx record for the recipient domain "nslookup -q=mx contoso.com" this should result in something like MX preference = 10, mail exchanger = mail.contoso.com along with others (we want to chose the one with the lowest preference #)
      • Run a lookup against both the AAAA name and then the A name record for mail.contoso.com against the recipient nameservers "nslookup -d2 -q=aaaa mail.contoso.com ns1.contoso.com" and "nslookup -d2 -q=a mail.contoso.com ns1.contoso.com"  Each of these will produce multi-page outputs however the last Got answer entry is the one we need to examine specifically we need to look to see if the ANSWERS: section has mail.contoso.com followed by type = CNAME if this is the case this indicates that the MX record is not actually pointed at an AAAA or A name record but is rather pointed at an alias which is an invalid configuration.
    • Fixes/Mitigations
      • This is a configuration issue with the recipient DNS configuration which is not following RFC specifications.  The recipient DNS administrator will need to be contacted to inform them that their MX record must point to an A name record in order for email to be delivered properly to them.