Encrypting (and decrypting) emails sent from v7

Hi @rntrp 
Let’s clarify how TLS works in the context of Adobe Campaign email delivery, what the "smtpEnableTLS" option does, and how decryption/key exchange works for recipients.

How TLS Works in Email Delivery

• TLS (Transport Layer Security) is used to encrypt the connection between two mail servers (i.e., Adobe Campaign’s MTA and another domain’s SMTP) during email transmission.
• Enabling smtpEnableTLS in serverConf for Adobe Campaign means, the outbound connection FROM Campaign’s server to the recipient’s mail server will attempt (or require, depending on config) to use TLS for that SMTP session.

Important: This secures the “mail in transit” between the two servers, not the email message itself. If a recipient downloads their email via an insecure connection (e.g., POP3/IMAP without SSL), the message can still be vulnerable after it reaches their mailbox.

1. How Does Decryption Work in TLS Email Delivery?

• TLS does not encrypt the actual email file. Instead, it creates a secure “tunnel” for the SMTP conversation.
• When the Adobe Campaign server connects to a recipient domain that supports STARTTLS, both servers negotiate a TLS session using standard X.509 certificates (just like HTTPS).
• All email content transmitted over this session is encrypted “on the wire.”
• The recipient server receives the email, decrypts the session with its private key, and stores/delivers the plain email to the end-user’s mailbox.
• There are no unique symmetric keys exchanged for every domain or per-message. Instead, TLS handshake establishes temporary session keys just for the duration of that SMTP connection.

Key Points:

• The encryption is ephemeral: It applies only to the connection/session, not the message at rest.
• Recipient servers don’t need a special key from Adobe Campaign: They just use publicly trusted TLS certificates to negotiate the connection.
• There is no per-recipient key exchange or custom key sharing as you might see with message-level encryption such as S/MIME or PGP.

2. How Are Keys Shared with Receiving Domains?

• SSL/TLS relies on certificate trust, not key sharing.
• Adobe Campaign’s MTA trusts standard Certificate Authorities (CAs) to verify the recipient server’s identity.
• The session encryption key is negotiated on the fly during the handshake using public/private key pairs and ephemeral session keys.
• If the recipient mail server requires a client-side certificate to complete SMTP over TLS (rare outside of high-security closed environments), then a specific key/cert might be needed but typical consumer ISPs just demand a valid TLS handshake with a trusted CA, not custom sharing.

3. Limitations of TLS in Email

• If the recipient’s MX server does not support TLS and you have forced TLS enabled, the message will not be delivered (it will hard-fail).
• If TLS is optional (opportunistic), the message will be delivered without encryption if the recipient server doesn’t support STARTTLS.
• TLS only protects in-transit: It does not provide end-to-end encryption. Once the email reaches the recipient’s mail server and is placed in their inbox, it is no longer protected by the session’s encryption.
  
  

Hope this helps.