The race to secure record-like information for domains

Securing domain names for application access remains a challenge. One classic solution involves adding configuration as TXT records using an underscored subdomain label to distinguish it from a hostname. However, this approach is not secure as DNS-based network interference is common. The recommended practice is DNSSEC, which employs cryptographic signing for security. Despite its advantages, DNSSEC adoption is not widespread, leaving many domains insecure.

When an application developer needs secure domain names, they often turn to HTTPS .well-known approach as their web-based application already has an HTTPS secured endpoint. Fetching records is a simple HTTP GET request. However, this solution doesn't apply to all protocols.

Email, an old protocol, faces challenges in securing hostname mis-matches. When an MTA relays an email, it must discover the destination MTA using an MX record, which typically isn't secured. This leads to insecure connections, allowing certificate validation to fail. Without trust, certificate validation cannot succeed, leaving email susceptible to both passive eavesdropping and active attacks.

The mismatch between the sending MTA's hostname and the recipient's email address prevents authenticated MTA-to-MTA transit encryption, which is crucial for secure email delivery.

Unlike the web, email doesn't have a direct analogy to solve this issue. Web browsers can show certificate warnings to users, but MTAs have no such mechanism. Email providers tout transit encryption, but the lack of certificate validation makes email transmission insecure. A secure solution for securing hostname mismatches in email would enhance email security significantly.