Are Salesforce Emails Encrypted? (w/Examples) + FAQs

Yes — but only partially by default. Salesforce uses Transport Layer Security (TLS) to encrypt emails while they travel between mail servers. However, Salesforce does not provide native end-to-end encryption for email content. Once an email leaves Salesforce and lands in a recipient’s inbox, Salesforce no longer controls how it is stored or accessed.

This distinction matters because federal laws like the Health Insurance Portability and Accountability Act (HIPAA) and the Gramm-Leach-Bliley Act (GLBA) require organizations to protect sensitive data both in transit and at rest. In 2025 alone, the Office for Civil Rights imposed over $6.6 million in HIPAA fines, with email security failures driving many of those penalties. A 2025 Paubox study of 180 healthcare email breaches found that 98.9% of breached organizations lacked basic email transport security protections.

Here is what you will learn in this article:

• 🔐 How Salesforce encrypts emails during transmission — and where that protection stops
• ⚖️ Which federal and state laws require email encryption and what penalties apply
• 🛡️ The differences between Classic Encryption, Shield Platform Encryption, and Marketing Cloud encryption
• ❌ Common mistakes that leave Salesforce emails exposed — and how to avoid them
• ✅ Step-by-step actions you can take today to strengthen your Salesforce email security

How Salesforce Handles Email Security

Salesforce protects emails through a combination of encryption protocols and sender authentication tools. These features work together to reduce the risk of interception and spoofing, but they operate within specific boundaries.

At its core, Salesforce attempts to use TLS to encrypt the connection between its mail servers and the recipient’s mail server when sending outbound email. TLS protects the transmission session — not the email content itself. This means the email is shielded while it moves across the internet, but it arrives at the recipient’s inbox in readable form.

Salesforce also relies on SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) to verify that emails genuinely come from your organization. SPF tells receiving servers which mail servers are authorized to send on behalf of your domain. DKIM attaches a cryptographic signature to each email so the recipient can confirm the message was not altered during transit. Without both protocols configured, even encrypted emails may be flagged as suspicious or rejected outright.

As of April 2020, Salesforce only supports inbound and outbound email connections using TLS 1.2 or higher. Salesforce has also recommended that customers transition to TLS 1.3 and discontinue the use of RSA key exchanges in favor of ECDHE key exchanges, following NIST guidance issued in September 2024.

Encryption in Transit vs. Encryption at Rest

Understanding the difference between these two types of encryption is critical for anyone managing sensitive data in Salesforce. They protect data at different stages, and a gap in either one can create legal exposure.

Encryption in Transit

When Salesforce sends an email to an external recipient, it attempts to establish a TLS-encrypted connection with the recipient’s mail server. If that server supports TLS, the email travels through an encrypted tunnel. If the server does not support TLS — and TLS enforcement is not turned on — the email may be delivered in plain text over an unencrypted connection.

This is known as opportunistic TLS. Salesforce tries to encrypt, but it does not guarantee it. The encryption depends entirely on the recipient’s server capabilities.

Encryption at Rest

Inside Salesforce, data stored on the platform is protected by the platform’s encryption infrastructure. This includes records, files, metadata, and email-related data. AES-256 encryption protects stored data from unauthorized access at the server level.

However, once an email is delivered to an external inbox, Salesforce has zero control over how that email is stored, forwarded, or accessed. Salesforce does not encrypt email content at rest in external inboxes. For teams in healthcare, finance, or insurance, this gap represents a significant compliance risk.

Using Shield Platform Encryption, organizations can encrypt Email Message and Email-to-Case fields stored within Salesforce — including subject lines, email bodies, headers, and email addresses. This encryption applies only to email records stored inside the Salesforce platform.

Salesforce TLS Settings: A Full Breakdown

Salesforce gives administrators five TLS options for outbound email encryption. Each setting carries different levels of security and different risks to email deliverability.

The default setting is “Preferred,” which means Salesforce will fall back to plain text delivery if the recipient server does not support TLS. For organizations handling sensitive data, this default is not sufficient. Administrators should evaluate whether “Required” or “Required Verify” is appropriate based on their compliance obligations.

When you select any setting other than “Preferred,” Salesforce allows you to restrict TLS to specific domains. This means you can enforce strict TLS for emails sent to regulated partners or clients while keeping the default “Preferred” setting for general correspondence. Wildcard domains (e.g., *.hospital.com) are supported.

If you do not specify domains when using a non-default TLS setting, Salesforce applies that setting to all outbound emails. This can result in undelivered messages when recipient servers lack TLS support.

Classic Encryption vs. Shield Platform Encryption

Salesforce offers two built-in encryption frameworks: Classic Encryption and Shield Platform Encryption. They differ in strength, scope, cost, and functionality.

Classic Encryption

Classic Encryption is free and included with every Salesforce edition. It uses a 128-bit AES algorithm and allows you to encrypt custom text fields — but not standard fields like Email or Phone. Encrypted fields are limited to 175 characters, cannot serve as unique fields or external IDs, and cannot be used in workflow rules or formula fields.

Classic Encryption works well for basic data masking needs. But because it cannot encrypt standard fields and has severe character limits, it falls short for organizations that need to meet HIPAA, GLBA, or CCPA/CPRA requirements.

Shield Platform Encryption

Shield Platform Encryption is a paid add-on priced at roughly 20% of your total Salesforce spend for Platform Encryption alone, or about 30% if you purchase the full Shield bundle (which includes Event Monitoring and Field Audit Trail). It uses 256-bit AES encryption and supports both standard and custom fields, files, attachments, and Chatter data.

Shield Platform Encryption also offers two encryption modes. Probabilistic encryption generates a unique, random encrypted value for each record, making it the most secure option but preventing filtering and searching. Deterministic encryption produces the same encrypted output for identical input values, which allows for UI searches, lookups, and certain SOQL queries — a less secure but more operationally flexible option.

Organizations can also use Bring Your Own Key (BYOK) or Cache-Only Keys to maintain full control over the encryption key lifecycle. Cache-Only Keys, available at $4,000 per org per month, allow keys to exist entirely outside Salesforce.

Marketing Cloud Email Encryption

Salesforce Marketing Cloud handles encryption differently from Sales Cloud and Service Cloud. Marketing Cloud has its own set of tools and limitations that teams must understand before sending regulated communications.

TLS for Outbound Marketing Emails

Marketing Cloud uses opportunistic TLS by default for all outbound emails. This means it attempts a TLS connection, but sends in plain text if TLS is unavailable. To enforce TLS on all outbound emails, organizations must contact Salesforce Support to submit an internal engineering request. TLS enforcement is configured at the account level — it cannot be applied to individual emails.

Field-Level Encryption (FLE)

Marketing Cloud supports Field-Level Encryption using AES-256 for data extensions. This feature encrypts specific fields at the data level so that personal information like email addresses cannot be read directly in the database. However, FLE comes with significant limitations: you cannot segment, filter, or query encrypted fields; encrypted data appears encrypted in reports; and you cannot turn off FLE after enabling it.

Data at Rest Encryption

Marketing Cloud also offers a separate Data at Rest Encryption feature that protects underlying files stored in the file system. This is a transparent, infrastructure-level feature. Data appears as plain text at the application layer while the file system is encrypted underneath. It does not use field-level or application-layer encryption.

The January 2026 Encryption Incident

In January 2026, Salesforce Marketing Cloud experienced a major security incident when three vulnerabilities (CVE-2026-22582, CVE-2026-22583, and CVE-2026-22586) exposed hard-coded cryptographic keys and argument injection flaws across CloudPages, click tracking, and unsubscribe centers. Salesforce responded by migrating all link encryption to AES-GCM authenticated encryption.

The fix was technically sound but not backward compatible. Every link generated before January 21 expired and stopped working, including unsubscribe links, preference centers, and “View as Web Page” links. The new encryption also more than doubled URL lengths — from approximately 180–255 characters to as many as 580 characters. These longer URLs triggered DKIM signature failures on Microsoft domains (Outlook, Hotmail, Live.com), causing bounce rates that approached 99% for some senders between January 21 and January 25.

The broken unsubscribe links created a compliance problem under CAN-SPAM, GDPR, and CASL, all of which require functioning opt-out mechanisms. Salesforce now recommends a maximum 60-day lifetime for encrypted links.

Federal Laws That Require Email Encryption

HIPAA (Healthcare)

HIPAA’s Security Rule (45 CFR §164) requires covered entities and business associates to implement safeguards that protect electronic protected health information (ePHI) during transmission and storage. Encryption is classified as an addressable specification under HIPAA — not mandatory — but organizations that choose not to encrypt must document an equivalent alternative and the reasons for that decision.

In practical terms, most enforcement actions treat unencrypted ePHI as a violation. In 2025, Evergreen Behavioral Health paid $725,000 for failing to encrypt data on a stolen laptop containing 80,000 patient records. HIPAA civil penalties can reach $2,134,831 per year per violation tier, and criminal penalties can result in up to 10 years in prison and $250,000 in fines for knowingly misusing PHI.

Salesforce is not HIPAA-compliant out of the box. Organizations must request a Business Associate Agreement (BAA) from Salesforce, and the BAA only covers selected products and services. Shield Platform Encryption, access controls, and audit trails are all required to achieve compliance.

GLBA (Financial Services)

The Gramm-Leach-Bliley Act’s Safeguards Rule requires financial institutions to develop a written information security program that protects nonpublic personal information (NPI). The updated Safeguards Rule, effective June 9, 2023, broadened the definition of “financial institution” to include mortgage lenders, loan brokers, debt collectors, real estate appraisers, and even higher education institutions participating in federal student financial aid.

Encryption is not explicitly named in the GLBA statute, but Section 501(b) requires institutions to ensure the security and confidentiality of customer information. Encrypting emails that contain NPI is considered an industry best practice and is a common expectation during FTC enforcement actions. The FTC enforces GLBA compliance through the FTC Act rather than through civil penalties, which means violations can result in consent decrees, mandatory corrective action plans, and significant reputational damage.

FTC Act Section 5 (All Industries)

The Federal Trade Commission uses Section 5 of the FTC Act to bring enforcement actions against any company that engages in unfair or deceptive practices related to data security. If a company’s privacy policy promises to “encrypt” or “protect” customer data — and then sends unencrypted emails through Salesforce — the FTC can treat that as a deceptive trade practice.

The FTC has imposed penalties in cases like CafePress ($500,000) for failing to protect consumer data and notify affected parties. The FTC’s position is that even if no specific encryption law applies to your industry, a failure to implement reasonable data security measures can still constitute an unfair practice under Section 5.

State Laws: CCPA and CPRA (California)

The California Consumer Privacy Act (CCPA), as amended by the California Privacy Rights Act (CPRA), does not explicitly mandate encryption. However, it introduces the category of Sensitive Personal Information (SPI) — which includes Social Security numbers, financial account information, precise geolocation, health data, and the content of personal email communications.

Businesses that collect SPI must implement stricter security measures, provide clear notice of collection and use, and offer consumers the right to limit the use of their sensitive data. California’s data breach notification statute also provides a safe harbor for encrypted data: if breached data was encrypted and the encryption keys were not compromised, notification may not be required. This creates a powerful financial incentive to encrypt.

The CCPA applies to for-profit businesses in California with gross revenue over $25 million, or those that buy, sell, or share the personal information of 100,000 or more California residents.

Three Common Scenarios

Scenario 1: Healthcare Organization Sending Patient Information

A home health agency uses Salesforce Service Cloud to email care instructions to patients. The emails contain diagnosis codes, medication lists, and appointment details — all classified as ePHI under HIPAA.

Scenario 2: Financial Advisor Sending Account Statements

A financial advisory firm uses Salesforce Sales Cloud to email quarterly account statements containing Social Security numbers and account balances.

Scenario 3: E-Commerce Company Emailing California Customers

An online retailer uses Salesforce Marketing Cloud to send promotional emails to California customers. The emails contain personalized product recommendations based on browsing history, which qualifies as personal information under the CCPA.

Real-World Examples

Example 1: Maria, the Clinic Administrator

Maria manages a 50-person medical clinic that recently migrated to Salesforce Health Cloud. She assumed Salesforce “handled encryption” because the platform uses HTTPS. During a HIPAA audit, the auditor found that TLS was set to “Preferred” and no BAA had been signed. Maria’s clinic received a corrective action plan and was warned that future violations could result in fines starting at $141 per violation and scaling up to over $2 million per year.

Example 2: James, the Marketing Director

James runs email campaigns through Salesforce Marketing Cloud for a mid-size insurance company. After the January 2026 encryption update, every link in his company’s archived emails stopped working — including unsubscribe links in emails sent to 200,000 policyholders. His compliance team flagged a CAN-SPAM risk because recipients could not opt out. James had to resend campaigns with fresh links and build a standalone preference page on the company’s website as a backup.

Example 3: Priya, the Salesforce Admin

Priya manages a Salesforce org for a wealth management firm. She enabled Shield Platform Encryption using deterministic mode so that advisors could still search for client records by email. However, she encrypted the Account Name field using probabilistic mode, which broke a critical workflow that routed cases based on account names. The workflow silently failed for three weeks before anyone noticed, delaying responses to 400+ client inquiries.

Mistakes to Avoid

1. Assuming “Preferred” TLS is sufficient for compliance. The default TLS setting does not guarantee encryption. If a recipient’s server does not support TLS, the email is sent in plain text. For regulated industries, enforced TLS is the minimum standard.

2. Confusing platform encryption with email encryption. Shield Platform Encryption protects data stored inside Salesforce. It does not encrypt the email message that arrives in a recipient’s inbox. These are two different protections that solve two different problems.

3. Failing to sign a Business Associate Agreement. Salesforce will not automatically provide a BAA. You must request one from your account team, and it only covers specific products. Using a non-covered product to handle ePHI means you are out of compliance even if encryption is enabled.

4. Encrypting fields that break workflows. Probabilistic encryption prevents filtering and querying. If your workflows, approval processes, or Einstein models depend on encrypted fields, they may silently fail. Always test encryption changes in a sandbox before deploying to production.

5. Ignoring Marketing Cloud’s separate encryption requirements. Marketing Cloud is a different platform with its own encryption tools. TLS enforcement in Sales Cloud does not carry over to Marketing Cloud. You must contact Salesforce Support separately to enforce TLS in Marketing Cloud.

6. Not configuring SPF and DKIM. Without sender authentication, even encrypted emails can be flagged as suspicious or rejected by recipient mail servers. Encryption and authentication must work together.

7. Overlooking third-party AppExchange integrations. Salesforce’s BAA does not cover third-party apps installed from AppExchange. If an integration handles sensitive data, it needs its own security review and possibly its own BAA.

Do’s and Don’ts

Do’s

• Do enforce TLS for all regulated email domains. Use “Required” or “Required Verify” and restrict TLS to specific domains that handle sensitive data. This prevents accidental plain-text delivery.
• Do configure SPF, DKIM, and DMARC together. All three protocols work as a unified sender authentication framework. Missing one weakens the others.
• Do test encryption settings in a sandbox first. Encrypting fields in production without testing can break workflows, reports, and integrations.
• Do enable Compliance BCC for regulated industries. Compliance BCC sends a hidden copy of every outbound email to a designated address, creating an audit trail for SEC, FINRA, and HIPAA reviews.
• Do review Salesforce’s BAA scope before handling ePHI. Not all Salesforce products are covered under the BAA. Verify coverage for each product you use.

Don’ts

• Don’t assume Salesforce emails are fully encrypted by default. The default “Preferred” TLS setting is opportunistic, not guaranteed.
• Don’t use Classic Encryption for standard fields. Classic Encryption only supports custom text fields with a 175-character limit. It cannot encrypt email addresses, phone numbers, or names.
• Don’t encrypt every field with Shield. Salesforce recommends encrypting as few fields as necessary because encryption can affect performance, search, and reporting.
• Don’t rely on Salesforce alone for end-to-end email encryption. Third-party tools from AppExchange or external providers are needed to encrypt email content inside the recipient’s inbox.
• Don’t forget to rotate encryption keys. Salesforce allows you to generate, rotate, export, and destroy keys. Stale keys increase the risk of compromise.

Pros and Cons of Salesforce’s Native Email Encryption

Pros

• TLS is enabled by default. Every Salesforce org attempts TLS encryption on outbound emails without any configuration.
• Shield Platform Encryption uses military-grade AES-256. This meets the encryption standards required by HIPAA, PCI-DSS, and GLBA.
• Granular field-level control. Administrators can choose exactly which fields to encrypt, balancing security with performance.
• BYOK and Cache-Only Keys give organizations full key ownership. This satisfies compliance requirements that demand customer-controlled encryption keys.
• Compliance BCC creates a built-in audit trail. This feature meets SEC, FINRA, and HIPAA archiving requirements without third-party tools.

Cons

• No native end-to-end email encryption. Salesforce cannot encrypt email content inside the recipient’s inbox.
• Shield Platform Encryption is expensive. At 20-30% of total Salesforce spend, Shield can add tens of thousands of dollars per year to your licensing costs.
• Encryption can break functionality. Probabilistic encryption prevents filtering, searching, and querying on encrypted fields. Deterministic encryption allows some queries but is less secure.
• Marketing Cloud has separate encryption tools and limitations. FLE in Marketing Cloud cannot be turned off once enabled and prevents segmentation on encrypted fields.
• TLS depends on the recipient. If the recipient’s mail server does not support TLS, encryption simply does not happen under the default setting — and you may not even know it.

Compliance BCC and Email Archiving

For industries that require a record of every outbound email — including finance, insurance, and healthcare — Salesforce provides Compliance BCC. This feature automatically sends a hidden copy of every outbound email to a designated compliance email address. When enabled, it disables all manual BCC editing for users, creating a tamper-resistant audit trail.

To enable Compliance BCC, navigate to Setup → Compliance BCC Email, check the Enable box, enter your compliance email address, and save. This is a quick, organization-wide setting that applies to all outbound emails.

Marketing Cloud offers a separate BCC Email Compliance feature for Account Engagement (Pardot) that works with third-party archival systems. Marketing Cloud’s Email Studio also supports email archiving in EML format, which can be encrypted and placed on your enhanced FTP. However, archived files are deleted after 21 days, making this unsuitable for long-term compliance storage.

For SEC and FINRA recordkeeping requirements, many organizations pair Compliance BCC with third-party archiving solutions like Smarsh that provide long-term, tamper-proof storage.

Key Entities and Their Roles

Understanding who controls what in the Salesforce email encryption ecosystem helps you assign responsibilities and close gaps.

• Salesforce (the platform): Provides TLS for emails in transit, Classic and Shield encryption for data at rest, and Compliance BCC. Salesforce will sign a BAA for selected products only.
• The Salesforce Administrator: Configures TLS settings, SPF, DKIM, encryption policies, Compliance BCC, and user permissions for encrypted data.
• HHS Office for Civil Rights (OCR): Enforces HIPAA compliance and issues fines for email security failures involving ePHI.
• Federal Trade Commission (FTC): Enforces Section 5 of the FTC Act and GLBA Safeguards Rule compliance against deceptive or unfair data security practices.
• California Privacy Protection Agency (CPPA): Enforces CCPA/CPRA requirements, including security obligations for sensitive personal information.
• Third-Party AppExchange Vendors: Provide additional email encryption tools that can encrypt content and attachments before emails leave Salesforce. These vendors are not automatically covered by Salesforce’s BAA.

FAQs

Are Salesforce emails encrypted by default?
Yes, but only partially. Salesforce uses opportunistic TLS to encrypt emails during transmission, but falls back to plain text if the recipient’s server does not support TLS.

Does Salesforce offer end-to-end email encryption?
No. Salesforce does not natively encrypt email content inside the recipient’s inbox. Third-party tools are required for end-to-end encryption.

Is Salesforce HIPAA-compliant out of the box?
No. HIPAA compliance requires a signed Business Associate Agreement, Shield Platform Encryption, access controls, and audit trails — none of which are enabled by default.

What encryption does Salesforce Shield use?
AES 256-bit encryption. Shield Platform Encryption supports standard and custom fields, files, and attachments with industry-standard AES-256.

Can I enforce TLS in Salesforce Marketing Cloud?
Yes, but you must contact Salesforce Support to enable it. Marketing Cloud does not offer a self-service TLS enforcement toggle.

Is encryption required under HIPAA?
No, encryption is an addressable specification. But organizations that skip encryption must document an equivalent alternative, and most enforcement actions treat unencrypted ePHI as a violation.

How much does Salesforce Shield cost?
Shield is priced at 20-30% of your total Salesforce spend. Platform Encryption alone costs about 20% of net spend. Components can be purchased separately.

Does Classic Encryption protect email fields?
No. Classic Encryption only works on custom text fields limited to 175 characters. It cannot encrypt standard fields like Email, Phone, or Name.

What happened to Marketing Cloud links in January 2026?
Salesforce expired all pre-existing links after migrating to AES-GCM encryption to fix critical vulnerabilities. This broke unsubscribe links, tracking URLs, and CloudPages globally.

Does the CCPA require email encryption?
No, not explicitly. But the CCPA’s breach notification law provides a safe harbor for encrypted data, making encryption a strong protective measure for businesses handling California residents’ information.

Can I encrypt emails sent from Email-to-Case?
Yes, with Shield Platform Encryption. You can encrypt Email Message fields like subject, body, and headers that are stored inside Salesforce.

Does Compliance BCC encrypt the archived email?
No. Compliance BCC sends a copy of the outbound email to a designated address. The encryption of that copy depends on the recipient archival system, not Salesforce.