cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5228
Views
5
Helpful
3
Replies

envelope sender domain could not be resolved

For this error:

Apr 23 18:11:07 2008 Info: ICID 815272710 Address: <nurmaria> sender rejected, envelope sender domain could not be resolved

If the domain has multiple MX(es) record. I.e cardig.com has :

cardig.com mail is handled by 10 mail.cardig.com.
cardig.com mail is handled by 10 mail2.cardig.com.

Does Ironport check all the mx(es) first then reject if one of them is not exists?

Or just query it once (first match mx or first low priority mx)?

TIA.

3 Replies 3

david.shoesmith
Level 1
Level 1

I'm not sure what Ironport would do, however from my understanding, it would only use the first MX record that is could contact, and only use the 2nd record as a backup connection should it not be able to contact the lower priority record.
Looking at what you posted for that domain.
I would say that their MX records are not right, as the 2nd record would need another number apart from 10, as this is the same priority as the first record. When I did an nslookup on that domain it only had one MX record in the list.
Non-authoritative answer:
cardig.com MX preference = 10, mail exchanger = mail.cardig.com

cardig.com nameserver = ns1.dutaint.com
cardig.com nameserver = ns2.dutaint.com
mail.cardig.com internet address = 203.130.233.2
ns1.dutaint.com internet address = 203.130.233.3
ns2.dutaint.com internet address = 203.130.233.13
So I am not sure if you miss-typed or was just using it as an example.

Regards,

David


Non-authoritative answer:
cardig.com MX preference = 10, mail exchanger = mail.cardig.com


Yes, the dns that was read by ironport was not update, the mail2.cardig.com should no longer handle that domain.

In this case, it looks Ironport attempt to do an nslookup to all available MX records for each domain.

andrea.murari
Level 1
Level 1

I think that the problem is not related to MX records existence or priority.
The error you found occurs when a DNS server does not provide an answer to the query your appliance send when checking the sender.
Suppose that a remote SMTP server connect to your appliance and send a "MAIL FROM: user @ domain.com" SMTP command; at this point your appliance checks whether "domain.com" exists or not and therefore asks for a MX record for "domain.com" to the DNS you configured. The DNS in turn searches for an authoritative DNS for "domain.com" and then sends it a query for the MX records of "domain.com"; if it doesn't get an answer your appliance cannot validate the sender domain and rejects the connection with the error you reported.
In your example this means that the appliance didn't even know that the MX for cardig.com were "mail.cardig.com" and "mail1.cardig.com", but rather that the DNS server didn't get that information from the authoritative DNS server of "cardig.com".

Hope this helps.
Andrea