Here's why implicit MX for IPv6 is a bad idea.
Summary:
a domain with no MX _and_ no A record, is not a maildomain.
a domain with no A record in its MX set, is in error.
Interoperability in combination with the least surprise principle
dictates that IPv6 AAAA RR cannot function as implicit MX.
(only MX, A and AAAA RR are relevant to this discussion)
Consider a sender $sender which is IPv4 only, has no clue about IPv6:
When asking for an MX RR, it gets zero answers. It will then ask for
an A record and still get zero answers. It ends here.
1) no MX record, no A, no AAAA
or
2) no MX record, no A, only AAAA
According to $sender, these scenario's are the same. $sender will
ignore AAAA records:
1) no MX record, no A
2) no MX record, no A
Apparently this domain is not a maildomain. It doesn't matter if the
AAAA record is present or not.
IMPORTANT: a domain with no MX _and_ no A record, is not a maildomain.
This means an AAAA record is not an implicit MX record.
Similar reasoning but now with MX records:
One or more MX records are found, thus a list of hostnames are built
from it/them. All AAAA records will be ignored, leaving only a set
of A records and priorities.
If that set is empty, this is an error condition.
IMPORTANT: a domain with no A record in its MX set, is in error.
This means the only valid setup for IPv6 hosts which want to receive
mail is to have one or more MX records, with at least one A record in
them. That A record will point to a gateway.
Any different setup will destroy email reliability.
The other way around, an IPv6-only sender trying to send mail to an
IPv4-only maildomain, is a problem which the IPv6 host must resolve
by using the gateway again. IPv4-only receivers should not be bothered
with this.