I wonder how long it'll be before large companies require DNSSEC (and verify) + TLS for delivering email 2FA codes.
My guess is never, despite the relative ease that those codes can be spied upon.
Conversation
Replying to
Need TLSA records (DANE) in addition to DNSSEC to provide TLS authentication for email.
MTA-STS is a much weaker approach. Requires DNS records and an HTTPS web server which it uses to fetch an mta-sts.txt file similar to dynamic (no preload) HSTS if you only used http:// URLs.
2
9
Replying to
Yes, I was thinking of mentioning TLSA records, but so many people don't even do the few I mentioned. (I have TLSA records deployed for my mail server, but I don't know if my MTA will check and verify the TLSA record?).
2
Replying to
Enabling it for Postfix simply requires setting up unbound as your resolver and then enabling 2 configuration options:
smtp_dns_support_level = dnssec
smtp_tls_security_level = dane
Enables opportunistic dane where it uses it when there are TLSA records and prevents downgrades.
3
2
5
Replying to
Nice, I may have to finally switch after figuring out how hard it is to deploy w/ my current MTA.
1
1
Replying to
Postfix has really good support for DANE and it's fairly easy to set up proper SPF / DKIM / DMARC verification to prevent mail spoofing from domains with an enforcing DMARC policy. We partially publish our configs at github.com/GrapheneOS/mai.
1
1
3
Note: we enforce soft fail SPF, enforce DKIM when it's set and require STARTTLS for the SMTP federation port mainly to reduce spam. Those can result in missed emails from people who don't set up their domains properly. For example, not setting DKIM record for Google Workspace.
1
2
Enforcing DMARC is what prevents spoofing and that uses the results from SPF / DKIM without needing to strictly enforce them on their own but most people don't enable p=reject or p=quarantine for their domains. We prefer also enforcing SPF and DKIM on their own to drop spam...