1# Outbound delivery security23maddy implements a number of schemes and protocols for discovery and4enforcement of security features supported by the recipient MTA.56## Introduction to the problems of secure SMTP78Outbound delivery security involves two independent problems:910- MX record authentication11- TLS enforcement1213### MX record authentication1415When MTA wants to deliver a message to a mailbox at remote domain, it needs to16discover the server to use for it. It is done through the lookup of DNS MX17records for the recipient.1819Problem arises from the fact that DNS does not have any cryptographic20protection and so any malicious actor can technically modify the response to21contain any server. And MTA would use that server!2223There are two protocols that solve this problem: MTA-STS and DNSSEC.24Former requires the MTA to verify used records against a list of rules published25via HTTPS. Later cryptographically signs the records themselves.2627### TLS enforcement2829By default, server-server SMTP is unencrypted. If remote server supports TLS,30it is advertised via the ESMTP extension named STARTTLS, but malicious actor31controlling communication channel can hide the support for STARTTLS and sender32MTA will have to use plaintext. There needs to be a out-of-band authenticated33channel to indicate TLS support (and to require its use).3435MTA-STS and DANE solve this problem. In the first case, if policy is in36"enforce" mode then MTA is required to use TLS when delivering messages to a37remote server. DANE does pretty much the same thing, but using DNSSEC-signed38TLSA records.3940## maddy policy details4142maddy defines two values indicating how "secure" delivery of message will be:4344- MX security level45- TLS security level4647These values correspond to the problems described above. On delivery, the48established connection to the remote server is "ranked" using these values and49then they are compared against a number of policies (including local50configuration). If the effective value is lower than the required one, the51connection is closed and next candidate server is used. If all connections fail52this way - the delivery is failed (or deferred if there was a temporary error53when checking policies).5455Below is the table summarizing the security level values defined in maddy and56protection they offer.5758| MX/TLS level | None | Encrypted | Authenticated |59| ------------- | ---- | --------- | -------------------- |60| None | - | P | P |61| MTA-STS | - | P | PA (see note 1) |62| DNSSEC | - | P | PA |6364Legend: P - protects against passive attacks; A - protects against active65attacks6667- MX level: None. MX candidate was returned as a result of DNS lookup for the68 recipient domain, no additional checks done.69- MX level: MTA-STS. Used MX matches the MTA-STS policy published by the70 recipient domain (even one in testing mode).71- MX level: DNSSEC. MX record is signed.7273- TLS level: None. Plaintext connection was established, TLS is not available74 or failed.75- TLS level: Encrypted. TLS connection was established, the server certificate76 failed X.509 and DANE verification.77- TLS level: Authenticated. TLS connection was established, the server78 certificate passes X.509 **or** DANE verification.7980**Note 1:** Persistent attacker able to control network connection can81interfere with policy refresh, downgrading protection to be secure only against82passive attacks.8384## maddy security policies8586See [Remote MX delivery](/reference/targets/remote/) for description of configuration options available for each policy mechanism87supported by maddy.8889[RFC 8461 Section 10.2]: https://www.rfc-editor.org/rfc/rfc8461.html#section-10.2 (SMTP MTA Strict Transport Security - 10.2. Preventing Policy Discovery)