TLS and Security

All email traffic through PostMTA is encrypted in transit using TLS 1.2 or higher. PostMTA enforces TLS on outbound delivery (SEC-019) and supports TLS for inbound SMTP submission (SEC-018). Certificates are managed automatically via ACME/Let's Encrypt (SEC-020).

Supported TLS Versions

Outbound connections to major providers (Gmail, Microsoft, Yahoo, Apple) always negotiate TLS 1.3 where available.

Outbound Delivery (SEC-019)

PostMTA establishes a TLS connection directly to the recipient's mail server for every message. Connections are encrypted end-to-end with no intermediate proxies. TLS 1.3 is negotiated by default; TLS 1.2 is used as a fallback.

Inbound SMTP Submission (SEC-018)

When you configure PostMTA as your mail submission agent (MSA), inbound TLS is supported on port 587 (submission) and port 465 (SMTPS). Clients that connect over TLS can submit email for relay through PostMTA's outbound infrastructure.

Inbound STARTTLS is advertised on port 587. Port 465 provides implicit TLS (TLS is negotiated immediately on connection, before any SMTP protocol exchange).

Certificate Management (SEC-020)

PostMTA manages TLS certificates automatically for all outbound delivery using ACME (Automatic Certificate Management Environment) in partnership with Let's Encrypt. Certificates are provisioned and renewed without any manual intervention.

• Certificate type: RSA 2048-bit (minimum) or ECDSA P-256
• Renewal: Automatically 30 days before expiry
• Domain validation: ACME HTTP-01 challenge
• No client certificates required for sending email

For inbound SMTP (port 465), your domain's certificate is loaded from the PostMTA certificate store upon domain verification.

Cipher Suites

PostMTA uses a modern, minimal cipher suite list optimized for both security and compatibility:

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384

All listed ciphers provide perfect forward secrecy (PFS) via ECDHE or DHE key exchange. RC4, 3DES, and all CBC-mode ciphers on TLS 1.2 are excluded.

Perfect Forward Secrecy

Every TLS session uses an ephemeral key exchange (ECDHE or DHE), ensuring that compromising a long-term private key does not retroactively decrypt captured traffic. ECDHE with P-256 or X25519 is preferred; DHE-2048 is the minimum fallback.

TLS Reporting (TLSRPT)

Publish a TLSRPT DNS record to receive aggregate TLS failure reports from other domains that receive your email:

v=TLSRPTv1; rua=mailto:tls-reports@postmta.com

Add this as a TXT record at _smtp._tls.yourdomain.com. Reports are sent to the mailto address in the record, typically tls-reports@postmta.com so our operations team can monitor TLS delivery success on your behalf.

MTA-STS Policy

MTA-STS (RFC 8461) allows your domain to declare that mail servers must connect over TLS and present a valid certificate. PostMTA supports MTA-STS for inbound policy enforcement by recipient servers.

Host the MTA-STS policy file at:

https://mta-sts.yourdomain.com/.well-known/mta-sts.json

Policy file content:

version: STSv1
mode: testing
mx: mail.postmta.com
max_age: 86400

Publish the DNS TXT record to announce MTA-STS support:

mta-sts.yourdomain.com.  IN  TXT  "v=STSv1; id=20260101"

DANE (DNSSEC-Validated TLSA Records)

DANE (RFC 6696) binds your TLS certificate to a DNSSEC-signed TLSA record, providing a cryptographically verifiable path from DNS to your certificate without relying on commercial CAs.

TLSA record format for port 587 with STARTTLS:

_587._tcp.mail.example.com.  IN  TLSA  3  1  1  ( HASH_OF_CERTIFICATE )

STARTTLS Requirements by Provider

Some major mailbox providers require TLS or will mark unencrypted mail as spam:

Zero-Trust API Access

• All API calls require valid TLS 1.2+ (enforced at the load balancer)
• API keys are stored as bcrypt hashes — never returned in plain text after creation
• IP allowlisting available on Growth plans and above
• Short-lived JWT tokens available for enterprise via OAuth 2.0
• All API access is logged and auditable; logs retained 90 days

Security Best Practices

• Enforce MTA-STS for your sending domains to guarantee TLS on inbound connections from other mail servers
• Enable TLSRPT to receive daily reports on TLS negotiation failures — early warning of MITM or misconfiguration
• Use DANE where DNSSEC is available for cryptographically verifiable certificate binding
• Rotate certificates automatically (handled by PostMTA via ACME — no action needed)
• Monitor reputation via the analytics dashboard; sudden TLS failures may indicate an attack
• Review cipher suites quarterly; PostMTA maintains a current minimal list but you can request custom policy for compliance

Compliance Notes

PostMTA's TLS implementation meets the following standards: