August 6, 2026

Sending Email from Salesforce Securely: SMTP Is Not Encrypted by Default

SMTP is cleartext by design and TLS is opportunistic. Why Preferred Verify still sends in the clear, and what to configure so email is actually protected.

TL;DR

SMTP is a cleartext protocol. Encryption is an optional upgrade negotiated at connection time (STARTTLS), not a property of the protocol, so "we send over TLS" is a statement about what usually happens rather than what is guaranteed.
Salesforce's email relay has four TLS settings: Off, Preferred, Preferred Verify, Required Verify. Only the last one guarantees encryption.
Preferred Verify is the trap. It rigorously validates certificates when TLS is offered, and continues without TLS when it is not offered at all. It is strict about bad encryption and permissive about no encryption.
SPF and DKIM can both pass while DMARC fails, because DMARC checks alignment between the authenticated domain and the domain your recipient actually sees in the From header.
Since April 2026, outbound mail from unverified domains fails to send, and the failure is quiet: Apex, Flow and alert emails are dropped with no bounce.
Email is an egress channel that access reviews skip. You audit who can export a report. You rarely audit who can email its contents to an arbitrary address.

What You'll Learn

Why opportunistic TLS is not a security control, and what an active attacker does with it
What each of Salesforce's four TLS settings actually does when the far end offers nothing
Why passing SPF and DKIM is not enough, and what alignment means in practice
How to treat email as an outbound data channel rather than a notification feature
Which failures are silent, and how to detect them

The Problem

Email feels solved. You turned on DKIM, deliverability is fine, nobody is complaining. The security question gets answered with "email is encrypted in transit", and everyone moves on.

That sentence is doing more work than it can support. SMTP was specified in an era that assumed a cooperative network, and it carries mail in the clear. TLS was added later as an in-band upgrade: the sending server asks whether the receiving server supports encryption, and if the answer is yes, the session is upgraded. If the answer is no, the mail goes anyway, in plaintext, and nothing anywhere logs that as a problem.

So "encrypted in transit" is conditional on the far end agreeing, every time, for every recipient domain, with no failure signal when it does not.

The second problem is scope. Email is the one outbound channel almost every Salesforce org leaves broadly available. Apex can send it, Flow can send it, and on a community a guest user can trigger it. A report export is audited, requires permissions, and now triggers step-up authentication. Emailing the same records to an external address does not.

Common questions this article answers:

Is Salesforce email actually encrypted in transit?
Why does mail fail DMARC when SPF and DKIM both pass?
Who in my org can actually send email, and how would I know if that was abused?

Quick Answer

Email leaves Salesforce over SMTP, which is cleartext with optional TLS negotiated per connection. If you use email relay, the TLS setting decides what happens when the receiving server does not offer encryption. Off sends in the clear. Preferred upgrades when TLS is available and continues without it when it is not. Preferred Verify additionally validates the certificate and common name, refusing delivery on a bad certificate, but still continues unencrypted when TLS is not offered at all. Required Verify is the only setting that will terminate the session and not deliver rather than send unprotected, and it is the one to choose where confidentiality matters. For authentication, configure SPF and DKIM, then verify DMARC alignment, because both can pass while DMARC fails if the authenticated domain does not match the visible From domain. Restrict relay to your own domains to stop the relay being usable for arbitrary destinations, and enable compliance BCC where you need an audit trail. Finally, treat sending as a permission: review what Apex, Flow and guest users can email, because that path exports data with none of the controls a report export now carries.

Why SMTP is not secure by default

Three properties of the protocol matter here.

Encryption is opportunistic. The sending server issues a STARTTLS command and the receiving server either supports it or does not. There is no requirement, and no negotiated minimum. The default behaviour on failure is to continue in the clear, because the alternative, refusing to deliver, was considered worse when the standard was written.

The upgrade is strippable. Because STARTTLS is negotiated in-band, over the plaintext connection that precedes it, an attacker positioned between the two servers can remove the capability announcement. Neither side sees an error. The sender concludes the receiver does not support encryption and proceeds unencrypted, exactly as designed. This is a downgrade attack, and it is invisible to both ends.

Encryption is hop by hop, not end to end. Even a fully encrypted delivery protects the connection to the next mail server, not the message at rest afterwards, and not subsequent hops. TLS on SMTP is transport protection between two servers, and it is often described in a way that implies more.

None of this makes email unusable. It means the guarantee is weaker than the phrase "encrypted in transit" suggests, and that the strength of the guarantee is a configuration choice you make rather than a property you inherit.

The four TLS settings, and the one that lies to you

If you route outbound mail through your own infrastructure with email relay, Salesforce gives you four choices. In Salesforce's own terms:

Setting	What happens when TLS is offered	What happens when it is not
Off	No TLS. Session continues insecure.	Sends in the clear
Preferred	Session is upgraded to TLS	Continues without TLS
Preferred Verify	Upgraded, and the certificate must be signed by a valid CA with a matching common name, or the session is dropped and mail is not delivered	Continues without TLS
Required Verify	Upgraded, with the same certificate and common name checks	Terminates the session, does not deliver

Read the right-hand column, because that is the one that decides whether you have a security control or a preference.

Preferred Verify is the setting most likely to be chosen for the wrong reason. It looks like the careful option: it checks certificate authorities, it validates common names, it refuses to deliver when something is wrong with the encryption on offer. All true, and all irrelevant to the attack that matters. Against an active attacker who strips the STARTTLS announcement, there is no certificate to validate, so none of the strictness engages, and the message is delivered in plaintext.

It is strict about bad TLS and permissive about no TLS. An attacker chooses the second.

Required Verify is the setting that makes the guarantee real, and it comes with a genuine operational cost you should decide on deliberately rather than discover: mail to a recipient domain whose servers do not offer valid TLS will not be delivered at all. That is the correct behaviour for confidential content and a real problem if a significant counterparty runs a badly configured mail server. It is a business decision about which failure you prefer, not a checkbox, and it should be made by someone who can accept undelivered mail as an outcome.

While you are in the relay configuration, Restrict Relay to Domains limits which recipient domains the relay will handle, with wildcard support such as *.subdomains.com. An unrestricted relay is a more useful thing to compromise than a restricted one.

Passing SPF and DKIM is not passing DMARC

The three mechanisms are usually described as a checklist, which hides how they relate.

SPF publishes which servers may send for your domain. DKIM signs the message so the recipient can verify it was not altered and that the signing domain authorised it. DMARC tells recipients what to do when those checks fail, and this is the part with the subtlety.

DMARC does not simply ask "did SPF or DKIM pass". It asks whether the domain that passed aligns with the domain in the From header your recipient actually sees. That is the whole point: an attacker can trivially pass SPF for a domain they control while displaying yours in the From line. Alignment is what closes that gap.

The practical consequence is a failure mode that confuses people every time. SPF passes. DKIM passes. DMARC fails. Nothing is broken in either underlying check; the authenticated domain and the visible domain simply are not the same, which commonly happens when mail is sent from a subdomain, relayed through a third party, or signed with a key belonging to a vendor's domain rather than yours.

So the verification step is not "is DKIM enabled". It is: send a real message to an address you control, view the original, and confirm that DMARC reports pass with the aligned domain being yours. Anything else is an assumption.

Two operational notes. Rotate DKIM keys periodically, since a key you generated once and forgot is a long-lived secret with no rotation story. And if you send in volume, the major mailbox providers now require SPF, DKIM, DMARC, one-click unsubscribe and a spam complaint rate below 0.3%, which turns deliverability hygiene into a hard requirement rather than a nicety.

The failure that does not announce itself

Since April 2026, Salesforce enforces email domain verification: outbound mail from an unverified domain fails to send. We covered the wider enforcement wave in Salesforce security enforcement in 2026.

The dangerous part is not the enforcement, it is the shape of the failure. Apex, Flow and workflow alert emails are dropped with no bounce. The automation reports success, the record updates, the log is clean, and the notification simply never arrives. An escalation alert that silently stops firing looks identical to an escalation that never triggered.

This is worth a deliberate check rather than trust, because the symptom only appears as an absence. Verify every sending domain, including the ones used by automation rather than people, and confirm at least one automated send actually lands.

Related, and often missed in the same audit: the ability to change a user's email address at scale is itself being tightened, which we cover in the authorized email domains change.

Email is an egress channel nobody audits

Here is the framing that changes what you do about this.

Your org has controls on data leaving through reports. Export permissions, step-up authentication on report actions, transaction security policies on large exports. All of that is because bulk export is understood as an exfiltration path.

Email is the same path with almost none of the controls. Consider what can send:

Apex. Any class that can run can construct a message with arbitrary content and arbitrary recipients. There is no per-recipient control and no equivalent of a report export policy.
Flow. Same reach, lower barrier, often built by someone who is not thinking about egress at all.
Guest users. On an Experience Cloud site, an unauthenticated visitor can trigger flows that send. Salesforce provides a control to block guest-user sends from unverified addresses, which is worth having on, and guest-triggered sends should use a verified organisation-wide address rather than the guest user's own. Guest exposure generally is covered in grading guest user exposure by real reachability.

So the questions for a review are not about deliverability at all:

What in this org can send email, and who wrote it?
Can any of it be triggered by an unauthenticated user?
Does any of it put record data into the body, and could the recipient address be influenced by input?

That third question is the one that finds real problems. A flow that emails a case summary to an address taken from a field is an exfiltration primitive if that field can be set by the person filing the case.

Compliance BCC is the mitigation worth knowing about: it sends a hidden copy of every outbound email to a designated archive address, which gives you an audit trail rather than an assumption. It is a common requirement in regulated environments and it is equally useful as a detection control, because it is the only place a complete record of what left your org by email exists.

What to actually check

In rough order of value:

Confirm your DMARC result on a real message, aligned to your domain, rather than confirming that DKIM is switched on.
Decide your TLS posture deliberately. If confidentiality matters, Required Verify, with someone senior accepting that undeliverable mail is the trade. If you are on Preferred Verify because it sounded strict, that was not a decision.
Verify every sending domain, including automation-only senders, and prove one automated send arrives.
Restrict relay to your domains if you run a relay.
Inventory what can send: Apex classes, flows, and anything reachable by a guest user. Ask whether any of them take a recipient address from data.
Turn on compliance BCC where you need the audit trail, and treat it as detection rather than paperwork.
Put DKIM key rotation on a calendar.

Frequently Asked Questions

Q: Is Salesforce email encrypted in transit or not?

A: Usually, and not guaranteed. Salesforce attempts TLS, and most major receiving providers support it, so in practice most mail is encrypted. The guarantee depends on the far end offering TLS and on your configuration deciding what to do when it does not. Only Required Verify converts "usually encrypted" into "encrypted or not delivered".

Q: We use Preferred Verify. Is that not the secure option?

A: It is the secure option against a badly configured receiving server, and not against an active attacker. Preferred Verify rejects invalid certificates but still sends in plaintext when the receiving server offers no TLS at all, which is exactly the state an attacker creates by stripping the STARTTLS announcement. The verification never engages because there is nothing to verify.

Q: SPF and DKIM both pass. Why is DMARC failing?

A: Because DMARC checks alignment, not just whether the underlying mechanisms passed. The domain authenticated by SPF or DKIM has to match the domain in the visible From header. Sending from a subdomain, relaying through a third party, or signing with a vendor's key are all common ways to pass both checks and still fail alignment.

Q: Does Shield Platform Encryption protect email?

A: No. Shield encrypts data at rest in your org. It has no bearing on what happens to a message once it leaves over SMTP. The two protect different things and are often conflated in the same conversation.

Q: Our alerts stopped arriving but nothing is failing. What is that?

A: Most likely the domain verification enforcement. Since April 2026, mail from unverified domains is dropped, and Apex, Flow and workflow alerts fail with no bounce. The automation succeeds and the message never lands, so the only symptom is an absence nobody is monitoring. Check that every sending domain is verified.

Key Takeaways

SMTP is cleartext with an optional upgrade. Encryption is negotiated per connection and fails open by default.
Preferred Verify is strict about bad TLS and permissive about no TLS. Against a downgrade attack, its certificate checks never run.
Required Verify is the only setting that guarantees encryption, and the trade is undelivered mail to badly configured recipients. Decide that deliberately.
DMARC is about alignment. SPF and DKIM passing tells you nothing on its own.
The 2026 domain verification failure is silent. Automated email is dropped with no bounce, so it presents as an absence.
Email is an unaudited egress channel. Apex, Flow and guest users can all send, and a recipient address taken from data is an exfiltration primitive.

What's Next?

Recommended Reading:

Action Items:

Send a real message to an address you control, view the original, and confirm DMARC passes with your domain aligned.
Look up your relay's TLS setting. If it is Preferred or Preferred Verify, decide consciously whether that is the posture you want.
Inventory every Apex class, flow and guest-reachable path that can send email, and check whether any takes its recipient address from data.

Resources & References

Written by the team at CloudCounsel — builders of Paywren and Mehfil.

Responses

Checking your session.

Loading responses.