Quoting Craig Sanders (c...@taz.net.au):
> The domain itself needs, at minimum, an SOA record, two or more NS records,
> and an MX record.
This is very good, Craig. (I would want to also include appropriate SPF
I tried for a while to draft a 'how to write a zonefile' tutorial using
my prototype example RFC 1035 ('BIND') zonefile and configuration at
but found the task surprisingly difficult, because you have to not only
present an example in good form, but also explain why you did particular
things and avoided particular errors (e.g., avoiding NS'ing or MX'ing to
> $ORIGIN example.com
> $TTL 86400
ITYM '$ORIGIN example.com.'
The '$ORIGIN' line at the top is something I, likewise, prefer to do as
syntactic sugar, but it should be understood to be not functionally
necessary and to create some small pitfalls if you do it. (Once, I
copied an existing zonefile to populate a new zone, and forgot to edit
the '$ORIGIN' line in the new zonefile, creating briefly puzzling
dysfunction until I caught the error.
> BTW, having a matching reverse-DNS entry for the MX records hostname is nice,
> and definitely worth doing if you can, but it's not necessary. Very few mail
> servers reject mail because of something trivial like that - it's not common
> these days for people to have any control over the .in-addr.arpa zones for the
> tiny subnets they get allocated by their ISP.
It's still been my experience, FWIW, that significant numbers of
receiving SMTP domains consider sender's lack of a valid reverse to be
suspiciously spammy, even though it's not RFC-required.
So, personally, I would always ask my ISP to set an appropriate reverse in
the applicable *.in-addr.arpa zone. (For these purposes, it's not
necessary to have the .in-addr.arpa namespace delegated, just set
luv-main mailing list