Do I really need an MX record? (for e-mail to work)
Barry Margolin
barmar at alum.mit.edu
Wed Dec 21 21:01:45 UTC 2005
In article <doc7eg$1jbh$1 at sf1.isc.org>, sm5w2 at hotmail.com wrote:
> Because of a recent change to our internet connection, I discovered
> that our MX record has been essentially non-existant for the past 2 or
> 3 weeks. Our A record is fine.
>
> It's easy enough to configure our MX record, but I'm reluctant to do so
> because:
>
> 1) We are getting e-mail, and there is no indication that anyone trying
> to send us e-mail is encountering any difficulty
>
> 2) The lack of an MX record seems to result in a fall-back to the A
> record (which explains why we are getting e-mail).
That's what's supposed to happen. MX is an override, it means "instead
of sending directly to the host in the email address, send to this host."
> 3) I've noticed a huge reduction in the amount of "zombie" or trojan
> spam being received by several of our well known addresses.
I wouldn't be surprised if some of the spam cannons don't properly
implement the protocol.
>
> Because of all three of the above (especially item 3) I think I'll be
> letting this experiment go a while longer and see if not having an MX
> record turns out to be a great way to prevent spam from finding us.
>
> Anyone care to comment?
It's generally recommended to have MX records. I've heard anecdotal
tales of SMTP implementations that don't properly fall back to A
records, although I don't really have much sympathy for them. There's
also a small DNS performance benefit, as it means only one lookup (MX)
rather than two (MX followed by A).
> ps: There seems to be no SMTP-specific newsgroup for talking about the
> benefits and pitfalls of not having an MX record (and no, NANAE does
> not seem relavent). Are there any web forums for SMTP discussions?
There's a comp.mail.* hierarchy.
--
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
More information about the bind-users
mailing list