> The Simple Mail Transfer Protocol (SMTP) relies on MX records in the DNS to identify which server(s) it should hand the mail off to.
Not necessarily (this statement is corrected later in the post). One of my domains have no MX records and I use it for email extensively. As per RFC2821, SMTP falls back to A (and AAAA which have not existed back then) when the FQDN does not have corresponding MX record [1]. I have only found it to be an issue with one web service which utilizes hunter.io, which marks my email address as invalid due to lack of an MX record. Real mail services work perfectly fine. They (hunter.io) have the following untruthful statement in their FAQ [2]:
>> We check if there are MX records on the domain. If there aren't, the email address can't receive emails.
Linked post reflects lack of requirement for the MX record correctly:
> As it turns out, no explicit MX record is indeed the most widely found configuration: almost 119 million domains (58% of all domains) are lacking any such resource record. Of those, 76 million (64%) do have an IP address and thus could at least theoretically receive mail
I think of it the other way around.
Originally, people would specifically say which computer it would be sent to when sending mail, right?
And then later came MX records.
So in my mind it’s like, ok send mail to this host, except if there are any MX records. If there are, then use those instead.
Ah yeah, these clowns. I distinctly recall, when rewriting the DNS record cache used internally at Google (note: not the resolver), thinking that surely no MX response would need more than 8KiB, and finding these jokers.
SMTP (the delivery email protocol) began supporting encrypted transport in 2002, which means that for over a decade most email has been encrypted in transit [5] (as well as during retrieval, because of POPS/IMAPS and HTTPS-secured webmail). The method is TLS (same protocol used by HTTPS, all of our web browsing traffic). Competent mail servers and services, such as exim [1] and GMail [2], let you choose to abort delivery if the destination server does not support encryption (or, since you are concerned about state actors, if there's a STARTTLS-stripping server in the middle).
Furthermore, DANE [3] and TLSA [4] can be used (requiring DNSSEC to be set up for the domain) to bind a mail server record to a specific TLS certificate, further reducing meddling opportunities by state-level actors and allowing a "we do allow insecure mail delivery, but since this destination has DANE it is implied they have TLS and we will fail delivery if TLS cannot be established with this destination with the DANE-specified parameters".
[1] https://www.skytale.net/blog/archives/32-Outgoing-TLS-verifi...
[2] https://support.google.com/a/answer/2520500?hl=en
[3] https://www.rfc-editor.org/rfc/rfc6698
[4] https://www.rfc-editor.org/rfc/rfc7671
[5] https://www.eff.org/deeplinks/2020/04/winding-down-starttls-...
https://mako.cc/copyrighteous/google-has-most-of-my-email-be...
A lot of it ... not me!
> pretty much boils down to "Google and Microsoft". Even if your domain doesn't use one of their mail servers, chances are that whoever you are sending mail to does.
