Quoting Craig Sanders (cas@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 TXT RRs.) 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 http://linuxmafia.com/pub/linux/network/bind9-examples-linuxmafia.tar.gz, 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 a CNAME).
$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 appropriately.)