Q:
MX Record & Emails
An MX record is looked-up if an email is being sent to (someone@mydomain.com) but if it directly sent to the mail server (someone@mail.mydomain.com) in this case only the A record it looked-up. Is this true?
In the latter case, emails are being sent directly to the mail server&any spam filtering system is by passed. How can this problem be solved?
MX records can be created only for spam filtering systems because the record with the lowest priority is the email server so to avoid this no MX record is created for the email server. This only is a problem when the filtering systems are down which is highly unlikely. Is there any other solution?
In the latter case, emails are being sent directly to the mail server&any spam filtering system is by passed. How can this problem be solved?
MX records can be created only for spam filtering systems because the record with the lowest priority is the email server so to avoid this no MX record is created for the email server. This only is a problem when the filtering systems are down which is highly unlikely. Is there any other solution?
ASKED:
Sep 28 2007 4:39 PM GMT
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
A:
RATE THIS ANSWER
0
Click to Vote:
0
Click to Vote:
- 0
0
For all the sending e-mail system knows, @mail.mydomain.com could be a subdomain of @mydomain.com, so an MX lookup is still performed to determine the mail host(s) that the message should be addressed to.
Here is my guidance on this topic:
Configure Internet facing MX records to point to your relay, or spam and anti-virus filtering device. Do not list any public MX records for the mail servers directly. Build in redundancy or high-availability for the mail filtering devices so that if one goes down, there is an alternate way for messages to be accepted.
Alternatively, you can subsribe to a third-party mail filtering service or simply a 'mail bag' with your ISP or other service provider that will accept and queue your messages until you are able to accept them again internally.
If neither is an option, then messages will typically queue on the sending end for approximately four hours before the messages are considered undeliverable and NDRs sent to the senders.
