Mail Transport Security Audit

Comprehensive evaluation of SMTP transport security, validating MTA-STS, DANE, and STARTTLS configurations against RFC 8461, RFC 6698, and RFC 3207 for defense against active downgrade and Man-in-the-Middle (MitM) attacks.

No signup

Instant results

100% free

What Is Mail Transport Security?

Mail transport security encompasses the cryptographic protocols and enforcement mechanisms—specifically Opportunistic TLS, MTA-STS, and DANE—designed to protect SMTP communications in transit. By default, SMTP transmits data in plaintext, exposing sensitive email contents to interception. Transport security ensures that MTAs encrypt the data channel using TLS before exchanging messages.

Why It Matters

Opportunistic TLS (RFC 3207) leaves email transport vulnerable to STRIPTLS attacks, where active adversaries strip the STARTTLS command and force plaintext fallback. Without enforced transport security mechanisms like MTA-STS (Mail Transfer Agent Strict Transport Security) or DANE (DNS-based Authentication of Named Entities), MTAs cannot cryptographically verify the destination server's identity or enforce encrypted delivery, compromising confidentiality and integrity of email data in transit.

Common Mistakes

Failure to implement MTA-STS or DANE, relying solely on Opportunistic TLS.

SENDING_MTA

DNS_RESOLVER_(DNSSEC_VALIDATED)

MTA-STS_POLICY_SERVER_(HTTPS)

RECEIVING_MTA_(TLS_1.3)

ENGINE_V2

STARTTLS_COMMAND

How It Works

Step 1

DNS Interrogation: The tool fetches MX records and checks for the presence of DNSSEC, _mta-sts TXT records, and TLSA records on port 25.

Step 2

MTA-STS Policy Validation: We attempt to retrieve the MTA-STS policy via HTTPS from mta-sts.[domain] and validate its syntax, max_age, and mx host constraints against RFC 8461.

Step 3

DANE Authentication: For domains with DNSSEC and TLSA records, we cryptographically verify the certificate hash and usage types (e.g., 3 1 1) per RFC 6698.

Step 4

STARTTLS Handshake Simulation: A connection is established to the MX hosts to verify TLS capabilities, cipher suites, and certificate validity chains.

MTA-STS Policy Validation

Deep inspection of _mta-sts TXT records and HTTPS policy endpoints, checking for syntax validity, caching directives, and matching MX hosts.

DANE TLSA Record Verification

Validates DNSSEC chains of trust and verifies TLSA records against the actual X.509 certificates presented by the SMTP server.

STARTTLS Handshake Analysis

Analyzes the STARTTLS implementation for supported TLS versions (TLS 1.2/1.3), cipher suite strength, and certificate validity.

DNSSEC Status Checking

Ensures the domain's DNS zones are signed with DNSSEC, a prerequisite for DANE to prevent DNS spoofing attacks.

Downgrade Attack Resistance

Evaluates the domain's susceptibility to STRIPTLS and active Man-in-the-Middle attacks based on current transport enforcement mechanisms.

RFC Compliance Reporting

Provides actionable remediation guidance mapped directly to RFC 8461, RFC 6698, and RFC 3207 standards.

Frequently Asked Questions

What is the difference between MTA-STS and DANE?

Both enforce TLS for SMTP, but they use different mechanisms. DANE (RFC 6698) relies on DNSSEC to secure TLSA records containing certificate fingerprints. MTA-STS (RFC 8461) uses a combination of DNS TXT records and an HTTPS-hosted policy file. DANE provides stronger cryptographic guarantees but requires DNSSEC, while MTA-STS is often easier to deploy for domains without DNSSEC support.

How does Opportunistic TLS fail to protect email?

Opportunistic TLS (RFC 3207) attempts to negotiate a secure connection via the STARTTLS command but will fall back to plaintext if the negotiation fails. Active adversaries can intercept the connection, strip the STARTTLS command, and force the sending MTA to transmit the email in plaintext (a STRIPTLS attack), completely bypassing the encryption.

Why is DNSSEC required for DANE?

DANE publishes certificate hashes in DNS via TLSA records. Without DNSSEC to cryptographically sign these records, an attacker could spoof the DNS response, providing their own TLSA record and routing the email to a malicious server. DNSSEC ensures the integrity and authenticity of the TLSA records.

What happens if my MTA-STS policy is unreachable?

If the HTTPS endpoint hosting your MTA-STS policy (e.g., mta-sts.yourdomain.com) becomes unreachable, sending MTAs will rely on their cached policy up to the max_age duration. If the cache expires, they may fail open (reverting to opportunistic TLS) or fail closed (refusing delivery), depending on the sender's strictness. High availability of the policy server is critical.

Can I use both MTA-STS and DANE simultaneously?

Yes, implementing both MTA-STS and DANE provides defense-in-depth. If one mechanism fails (e.g., a DNSSEC validation error or an unreachable MTA-STS policy server), the other can still enforce secure transport. Major email providers like Google and Microsoft support evaluating both standards.

What is a TLS reporting (TLS-RPT) record?

TLS-RPT (RFC 8460) works alongside MTA-STS and DANE to provide diagnostic reporting. By publishing a _smtp._tls TXT record, domain owners can receive daily JSON reports from sending MTAs detailing successful and failed TLS connections, helping identify misconfigurations or active attacks.

How do I fix a 'Certificate Name Mismatch' error in MTA-STS?

A certificate name mismatch occurs when the X.509 certificate presented by your receiving MTA does not contain a Subject Alternative Name (SAN) that matches the MX hostnames listed in your MTA-STS policy. To fix this, update your MTA's certificate to include the exact MX hostnames, or update your MTA-STS policy to list the hostnames currently secured by the certificate.