Mastering Salesforce Administration: Part 5 - Email Templates & Deliverability

Updated 20/04/2026

---

You have now worked through org health, user experience, automation, and approvals: the foundations that make Salesforce usable and governable. Part 5 moves into the communication layer, where those foundations start reaching people directly through approval notifications, case updates, reminders, confirmations, and operational alerts.

Email looks simple until it fails. A broken merge field can confuse a customer, a deliverability setting can stop business critical messages, and a missing DNS record can make Salesforce look unreliable even when the automation behind it is sound. This article shows how to design email templates and deliverability practices that users trust, admins can govern, and teams can troubleshoot before small issues become noisy incidents.

---

📧 Email Templates & Deliverability

📝 Why Email Templates Matter

Some Salesforce orgs sends hundreds maybe thousands of emails in a day: approval notifications, case acknowledgements, integration confirmations, marketing campaigns. Each one is a user experience touchpoint. But email is a fragile channel: DNS misconfigurations reject messages, bounces clog inboxes, regulatory compliance creeps up on you. Smart admins design email as a first class citizen in their automation, not a forgotten feature.

Email templates are the foundation. They separate message design from sending logic, allow merge fields to personalise content, and provide audit trails. Whether you’re sending approval notifications or routing cases, templates create consistency, testability, and maintainability.

⚡ Lightning Email Templates vs. Classic Email Templates

Salesforce has two distinct email template systems. Understanding the difference is critical: they have different builders, different capabilities, and different use cases.

Feature	Lightning Email Templates	Classic Email Templates
Builder	Drag-and-drop Lightning builder	HTML/text editor
Experience	Lightning Experience only	Classic + Lightning (limited)
Enhanced Letterheads	✅ Supported	❌ Not supported
Related List Merge Fields	✅ Supported	❌ Limited
Merge Fields	Handlebars-style {{{Recipient.Name}}}	Classic {!Recipient.Name} syntax
Navigation	Setup → Email → Lightning Email Templates (or App Launcher → Email Templates)	Setup → Email → Classic Email Templates
Used by	Flow Email actions, Email Alerts, Inbox	(Legacy) Workflow Email Alerts, Classic Send Email, some Flows via actions
Folder sharing	Enhanced folder sharing model	Legacy folder model
HTML editing	Limited (drag-and-drop blocks)	Full raw HTML control
Plain text fallback	Auto-generated or manually set	Manually authored
Best for	Modern orgs running purely Lightning	Legacy orgs, or complex HTML templates

When to Use Lightning Email Templates

For new orgs and automation built in Flow, Lightning Email Templates are the natural fit. They integrate natively with Flow Email actions, support Enhanced Letterheads, and receive Salesforce’s ongoing feature investment. Classic Email Templates remain fully functional and are the right tool when you need complete HTML control or are maintaining Workflow-based automation. Salesforce positions Lightning as the forward looking system, but Classic is not deprecated and continues to be supported.

Choose Lightning Email Templates when:

• Your org runs Lightning Experience only
• You want drag-and-drop template authoring without writing HTML
• You need Enhanced Letterheads (logos, branded headers/footers)
• You’re using Flow’s Send Email action or Email Alerts in modern automations
• You want related list merge fields (e.g., showing all open cases on a contact)

When to Use Classic Email Templates

Choose Classic Email Templates when:

• Your org has legacy Workflow Rules using Email Alert actions
• You need full raw HTML control over the email body
• You’re maintaining existing templates built before Lightning was available
• You’re working in a Classic-only org or a mixed environment
• The template is used by old-school mass email sends

Caution

Lightning Email Templates use Handlebars merge syntax ({{{Recipient.FirstName}}}), which is different from Classic’s {!Recipient.FirstName} syntax. You cannot mix the two. Templates must be consistent within their system. If you copy HTML from a Classic template into a Lightning template, merge fields will break.

---

🔑 Building Email Templates: Core Components

Regardless of which system you use, Salesforce email templates share three layers:

1. Template metadata: folder, name, description, language, encoding
2. Content: plain text and/or HTML body, merge fields, attachments, conditional blocks
3. Merge fields: dynamic data from records, related lists, custom fields

Note

Templates live in Setup → Email → Lightning Email Templates (modern) or Setup → Email → Classic Email Templates (legacy). You can also create Classic templates programmatically via Apex, but the Setup UI is the admin home for both.

When you build a template, you’re creating a reusable artefact. Approval notifications live in their own folder (e.g., Approvals). Case routing notifications in another (Cases). Naming consistency makes templates discoverable:

• Approval - Expense Denied
• Approval - Expense Approved (with Budget Owner Escalation)
• Case - New Case Acknowledgement

HTML Template Rendering Best Practices

Email clients are notoriously inconsistent in how they render HTML. Templates that look perfect in Gmail can break completely in Outlook. Follow these guidelines to avoid the most common rendering failures:

• Use a single-column layout. Multi column designs frequently break on mobile devices and in many Outlook versions. A single column renders reliably across virtually all clients.
• Inline your CSS. Many email clients (especially Outlook desktop) strip <style> blocks entirely. Use inline style="" attributes directly on elements, or use a tool like Juice to inline styles at build time if you’re working with Classic HTML templates.
• Keep template width between 600–700px. This range renders well across desktop and mobile clients without triggering horizontal scrolling.
• Use web-safe fonts (Arial, Georgia, Verdana, etc.) unless you’ve specifically tested custom font rendering across your target clients. Most email clients ignore @font-face declarations.
• Include alt text on all images. Many email clients block images by default. The alt text is what recipients see first, so make it descriptive enough to convey meaning without the image.
• Always provide a plain text version. Spam filters and some corporate environments prefer plain text. Lightning templates auto-generate a plain text fallback, but Classic templates require you to author one manually. In either case, review the plain text version to ensure it reads cleanly rather than relying on auto-generation.

✉️ Step-by-Step: Creating an Approval Notification Template

Let’s build a concrete approval notification template, one that informs an approver of a pending expense request and includes key decision data. We’ll cover both template systems.

Option A: Lightning Email Template (Recommended)

1. Navigate to Lightning Email Templates

   • Go to App Launcher → Email Templates
   • Click New Email Template

2. Set Template Details

   • Name: Approval - Expense Request Pending
   • Description: Notification sent to manager when an expense request is pending approval
   • Related Entity Type: Expense_Claim__c (the object this template merges from)
   • Folder: Approvals
   • Subject: Expense Request Pending: {{Expense__c.Name}}

3. Add an Enhanced Letterhead (Optional)

   • Search and select an Enhanced Letterhead, This adds your org’s branded header and footer automatically

4. Build the Body Using the Lightning Builder

   • Use the drag-and-drop editor to add text blocks, buttons, and images
   • Insert merge fields using the merge field picker (Handlebars syntax is auto-inserted)
   • Example body (simplified):

   Hi {{{Recipient.FirstName}}},
   
   An expense request from {{{Expense_Claim__c.Employee__r.Name}}} is waiting for your approval.
   
   Amount: ${{{Expense_Claim__c.Amount__c}}}
   Category: {{{Expense_Claim__c.Category__c}}}
   Purpose: {{{Expense_Claim__c.Purpose__c}}}
   Submitted: {{{Expense_Claim__c.CreatedDate}}}

5. Save and Test

   • Click Save
   • Lightning Email Templates have no preview button in the builder. To test, navigate to a relevant record (e.g., an Expense Claim), open the Send Email action, and select your template
   • Use the eye icon in the email composer to preview how merge fields will render before sending
   • Verify in sandbox with real records — null values on related fields are a common gotcha

The Customize an Org to Support a New Business Unit project includes a step, Configure an Email Letterhead and Template, that walks you through building a Lightning email template from the letterhead onward.

Configure an Email Letterhead and Template Configure a template and letterhead that can be used by all team members for their day-to-day email needs

Option B: Classic Email Template (Legacy)

1. Navigate to Classic Email Templates

   • Go to Setup → Email → Classic Email Templates
   • Click New Template

2. Choose Template Type

   • Select HTML (using Classic Letterhead) for branded HTML, or Custom (without using Classic Letterhead) for raw HTML control
   • Click Next

3. Set Template Details

   • Folder: Approvals
   • Available for Use: ☑ (checked)
   • Email Template Name: Approval - Expense Request Pending
   • Template Unique Name: Approval_Expense_Request_Pending
   • Classic Letterhead: [Select Letterhead]
   • Email Layout: [Select Layout]
   • Description: Notification sent to manager when an expense request is pending approval
   • Subject: Expense Request Pending: {!Expense_Claim__c.Name}
   • Template Encoding: UTF-8

4. Add HTML Content Build the HTML body with Classic merge fields ({!Object.Field} syntax):

   <p>Hi {!Recipient.Name},</p>
   <p>An expense request from <strong>{!Expense_Claim__c.Employee__r.Name}</strong> is waiting for your approval.</p>
   <h3>Expense Summary</h3>
   <ul>
     <li><strong>Amount:</strong> ${!Expense_Claim__c.Amount__c}</li>
     <li><strong>Category:</strong> {!Expense_Claim__c.Category__c}</li>
     <li><strong>Purpose:</strong> {!Expense_Claim__c.Purpose__c}</li>
     <li><strong>Submitted Date:</strong> {!Expense_Claim__c.CreatedDate}</li>
   </ul>
   <p><a href="{!Expense_Claim__c.Link__c}">Review Request</a></p>

5. Add Plain Text Fallback For email clients that don’t render HTML:

   Hi {!Recipient.Name},
   
   An expense request from {!Expense_Claim__c.Employee__r.Name} is waiting for your approval.
   
   Amount: ${!Expense_Claim__c.Amount__c}
   Category: {!Expense_Claim__c.Category__c}
   Purpose: {!Expense_Claim__c.Purpose__c}
   
   Review: {!Expense_Claim__c.Link__c}

6. Attach Documents (Optional)

   • To attach a static file, first save the template, then open the template detail page
   • In the Attachments section at the bottom of the detail page, click Attach File
   • Select a file from your computer or Salesforce Documents, this file will be included every time the template is used
   • Note: for mass email sends, attachments are sent as a link rather than a file so plan accordingly

7. Save and Test

   • Click Save
   • Click Send Test and Verify Merge Fields → select a test record → send to your email to validate rendering

Tip

Merge fields are context sensitive in both Lightning and Classic email template systems. In Lightning templates, {{{Recipient.FirstName}}} and in Classic {!Recipient.FirstName} dynamically resolve based on the email action’s recipient context (e.g., approval process responder, flow target record owner, or case contact). Always test merge fields with real sandbox records before promoting to production; null values on related fields are a common gotcha when the context shifts!

🚚 Email-to-Case and Inbound Email Routing

Email-to-Case bridges the gap between customer emails and Salesforce case management. Setting it up requires configuring two main components:

1. Inbound Address Configuration: Designating a public facing inbox (e.g., support@company.com) for incoming emails that are forwarded into Salesforce for processing.
2. Case Routing Logic: Defining rules that evaluate email properties to automatically assign new cases to the appropriate queue, owner, and priority.

When a customer emails support@company.com:

1. Salesforce receives the forwarded email and creates a Case record, mapping key properties (sender, subject, body) to case fields.
2. The original email is stored as an EmailMessage record related to the Case.
3. Case Assignment Rules evaluate the standard case fields populated from the email.
4. The case is assigned to the appropriate owner or queue based on those rules.
5. Case Auto-Response Rules trigger an automated confirmation email back to the customer.
6. The case becomes visible to agents in Service Cloud.

Setting up Email-to-Case:

• Enable the Feature: Navigate to Setup → Feature Settings → Service → Email-to-Case and click Enable. (Note: Once enabled, it cannot be disabled).
• Add a Routing Address: Enter your public facing email (e.g., support@company.com). Salesforce will map this and generate a long, unique Email Services Address.
• Configure Email Forwarding: In your corporate email provider (Exchange, Gmail, etc.), define a rule to auto-forward incoming emails from your public address to the long Salesforce generated address.
• Configure Rules: Set up Case Assignment Rules to route the newly created cases and Auto-Response Rules to instantly send customers a confirmation email containing their Case ID.

For higher volume or security sensitive implementations, evaluate On-Demand Email-to-Case vs. Email Relay and ensure Enhanced Email is enabled to leverage the EmailMessage data model.

Caution

Email-to-Case is a core platform feature available across most standard Salesforce licenses (including Service Cloud, Sales Cloud, and Industry Clouds). Each routing address must be unique within your org. For scalable routing, consider using multiple routing addresses (e.g., support@, billing@) combined with assignment rules rather than relying solely on subject line parsing.

🔐 Deliverability Essentials: Authentication, Bounces & Compliance

Email deliverability rests on three pillars:

1. Sender authentication (DKIM, SPF, DMARC): Proving emails come from trusted infrastructure
2. Bounce handling: Monitoring failed deliveries and cleaning bad addresses
3. Compliance: Consent management, unsubscribe flows, and suppression hygiene

Sender Authentication: DKIM, SPF, and DMARC

Mail servers check every inbound email: “Does this sender have permission to use this domain?” DKIM, SPF, and DMARC provide the proof.

• SPF: Lists authorized mail servers via DNS TXT records (add include: entries for Salesforce)
• DKIM: Salesforce cryptographically signs your emails; receivers verify against your public DNS key
• DMARC: Sets policy for SPF/DKIM failures and routes delivery reports

Enable DKIM in 3 steps:

1. Setup → Quick Find → “DKIM” → Create key for your verified domain
2. Copy Salesforce provided CNAME records to your DNS provider
3. Wait for propagation (1-48 hours), then activate in Salesforce

For SPF, append Salesforce’s approved include: mechanisms to your existing domain SPF record. Never publish multiple SPF TXT records.

DMARC Policy Progression

DMARC ties SPF and DKIM together by telling receiving servers what to do when authentication fails. Always start with a monitoring only policy and tighten gradually once you’ve confirmed all legitimate senders pass authentication:

Policy	Effect	When to Use
p=none	Monitor and report only; take no action on failures	Start here. Collect reports to identify all legitimate sending sources
p=quarantine	Failed messages are routed to the recipient’s spam folder	Move here once reports confirm all legitimate mail passes SPF/DKIM
p=reject	Failed messages are dropped entirely; never delivered	Final state for maximum protection against spoofing

A typical DMARC record looks like:

_dmarc.acme.com   TXT   "v=DMARC1; p=none; rua=mailto:dmarc-reports@acme.com"

The rua tag specifies where aggregate reports are sent. Tools like DMARC Analyzer or Postmark’s DMARC Digests convert these raw XML reports into readable dashboards. Read your reports regularly: they reveal which services are sending on behalf of your domain and whether authentication is passing. For production grade deliverability, aim for DKIM + SPF with DMARC at p=quarantine or stronger.

Bounce Handling

Bounces fall into two categories:

Type	Cause	Action
Soft Bounce	Mailbox full, greylisted, temporary server issues	Retry (usually recovers)
Hard Bounce	Invalid address, nonexistent domain	Remove immediately; no retry

Salesforce captures bounce data across sending features (email logs, activity records, campaign members). Weekly monitoring catches data quality issues early:

1. Build “Bounced Emails” report (filter hard bounces by reason)
2. Create suppression list (block future sends to hard bounces)
3. Alert on bounce rate spikes (>2-5% signals trouble)

Rate Limits & Compliance

Salesforce enforces feature-specific sending limits by edition:

• Single emails, mass sends, and automation all count differently
• Internal vs external recipients have separate quotas
• Daily/monthly caps reset at midnight UTC

Check your actual limits: Setup → Quick Find → “Email Log Files” or “Deliverability” status. Monitor trends before bulk campaigns and don’t guess. Always include unsubscribe links and honor opt-outs to maintain sender reputation.

For further reading, take a look at Email Deliverability Essentials. Although this is a Marketing Cloud badge, it covers the core email deliverability fundamentals clearly.

Email Deliverability Essentials Improve your email deliverability to generate more email marketing revenue.

🩺 Troubleshooting Email Delivery & Bounce Management

When emails fail to reach users, troubleshoot systematically: platform → sender → recipient → evidence.

Practical 6-step sequence

1. Org deliverability: Setup → Deliverability → Confirm Access Level allows outbound user email for your send scenario (not restricted to system email only)
2. Sender setup: Verify Org-Wide Email Address, verified domain, and Email Relay settings (if using a custom relay)
3. Authentication: Check SPF/DKIM/DMARC alignment for sending domain
4. Recipient quality: Validate email syntax, opt-out status, prior bounces
5. Send evidence: Review Email Logs + EmailMessage/Activity records for rejection reasons
6. Controlled retest: Send to known-good mailbox before broad rollout

Common Delivery Issues

Issue	Root Cause	Fix
Restricted deliverability	Access Level blocks user email	Setup → Deliverability -> set Access Level to allow outbound user email
Sender mismatch	From/Reply-To/domain don’t align	Verify Org-Wide Email + domain auth
Bad recipient data	Invalid syntax, abandoned accounts	Add validation + suppression list
Permission gap	User/automation lacks send perms	Check running user + template access
Post-migration spikes	Stale test data after refresh/import	Clean historic addresses pre-send

Bounce Management Dashboard

Build reporting for your send path (service, CRM, marketing):

1. Operational: Failed/sent EmailMessage + activity records
2. Data quality: Lead/Contact bounce flags + opt-out status
3. Trends: Group by reason/domain/time to spot systemic issues
4. Action queue: Hard bounces → cleanup tasks + suppression updates

Pro tip: Email Logs show raw SMTP responses. Combine logs with object-level signals (for example Lead/Contact bounce indicators, email activity records, and campaign member outcomes where relevant) for a complete picture.

Post-Send Health Metrics

Beyond dashboards, establish concrete benchmarks so your team knows when to act. The following thresholds are industry standard starting points:

Metric	Healthy Range	Action if Outside Range
Delivery rate	> 98%	Investigate bounce reasons; check authentication and recipient quality
Hard bounce rate	< 0.5%	Clean your list immediately; suppress invalid addresses
Spam complaint rate	< 0.1%	Critical — pause sending and investigate. Google and Yahoo enforce this threshold; exceeding 0.3% can trigger bulk filtering or blocks
Unsubscribe rate	< 0.5% per send	Review content relevance, send frequency, and audience targeting

Caution

Spam complaint rate is the single most important deliverability metric. Major inbox providers now enforce hard thresholds. If your complaint rate consistently exceeds 0.1%, your domain reputation will degrade and legitimate emails (including transactional notifications and approval alerts) will start landing in spam.

If deliverability suddenly drops, work through this sequence: check if your sending domain or relay IP has been blocklisted (use MXToolbox or similar), verify SPF/DKIM/DMARC records are still valid, review recent list additions for suspicious addresses, and check your complaint rate in Google Postmaster Tools.

⚠️ Email Limits, Gotchas & Security

Salesforce enforces multiple layers of limits on emails: body size, attachments, recipients, and daily sending capacity. The exact numbers vary by feature (single email, list email, Email-to-Case, marketing tools), edition, and org configuration, so always confirm current limits in Salesforce Help before implementing processes or making assumptions.

Limits to know

• Body length caps: Different send paths (single emails, list emails, email services, Email-to-Case) have different maximum body sizes. Very long templates, heavy signatures, and rich HTML can hit these limits and be truncated.
• Attachments and total size: Outbound emails have a total message size ceiling (body + headers + attachments). Large or multiple attachments, plus Base64 overhead, can cause silent failures if you’re close to the cap.
• Recipients and daily sends: Orgs have daily external recipient caps, and list/mass emails count against separate allocations. Trial and Developer Edition orgs are more restrictive. Check Email Allocations per Edition and feature specific docs before bulk sends.
• Merge fields and encoding: Merge fields consume characters and use hidden encoding. Complex HTML templates with many merge fields can hit subject/body limits sooner than expected, especially with dynamic content.

Common gotchas

1. Attachments and storage: Attachments or Files stored in Salesforce still consume org storage, even if they originated as email attachments. For high-volume processes, consider linking to externally stored files instead of attaching copies.
2. Context sensitive merge fields: A merge field that works perfectly in one context (for example {!Expense__c.Employee__r.Name} in an Expense flow) can resolve to blank in another. Always test templates in the exact automation and record context you’ll use in production.
3. Encoding and character sets: Emojis and non‑ASCII characters can mis-render if the template, org default encoding, or downstream mail systems are misaligned. Test with real data and target domains in a sandbox before broad rollout.
4. Unsubscribe behavior: Modern email ecosystems expect Unsubscribe headers and clear opt‑out options. Salesforce native mass email features generally handle this for you, but custom sends (Apex, custom services) must implement compliant unsubscribe logic explicitly.

Email security risks

• Header injection: If you ever construct email headers from user input (for example, in custom integrations or email services), sanitize aggressively. Never allow raw user data into To, Cc, Bcc, Reply-To, or Subject without validation to prevent SMTP header injection.
• Attachments as attack vectors: Treat user uploaded attachments as untrusted input. Enforce strict file-type allowlists, size limits, and run malware scanning both before opening and before sending files out from Salesforce related processes.
• Plain text vs HTML: Plain text emails have a smaller attack surface but limited UX. HTML templates enable rich content and tracking but increase the risk of XSS like issues in custom frontends and require more careful encoding. Balance user experience against complexity and validate any user derived content before rendering.

📋 Email Governance & Audit

Deliverability is not just a technical setup problem, it is an operating model problem. Orgs that treat templates as shared production assets usually avoid the worst issues: duplicate messages, orphaned templates, and broken sends after process changes.

Start by standardising naming so teams can quickly find the right template and understand intent without opening it. A consistent pattern such as [Type] - [Business Process] - [Audience/Outcome] works well in practice (Notification - Case - Auto-Acknowledged, Approval - Expense - Manager Review, Alert - Order - Fulfillment Delay).

Then establish ownership and lifecycle rules. Each folder should have a clear business owner, every template should include a short purpose statement in its description, and a periodic review should remove obsolete templates and merge duplicates. This one habit prevents long term sprawl and reduces mistakes during urgent changes.

For auditability, combine platform logging with a simple recurring health report. Review relevant email activity records for send failures, bounce trends, and unsubscribe behavior, then track those metrics monthly so regressions are visible early rather than after customer complaints.

Finally, keep testing discipline strict: test in sandbox first, use safe test addresses, validate merge field rendering with representative records, and check output across major mail clients (Outlook, Gmail, Apple Mail, mobile). Reliable email delivery comes from repeatable process, not onetime configuration.

---

Final Thoughts

Email is infrastructure, not just communication. In this part, you looked at how Lightning and Classic templates differ, how merge fields and letterheads shape maintainable messages, and why deliverability settings, DNS authentication, bounce handling, limits, and audit habits all matter once email becomes part of your business process.

The key lesson is that reliable email does not come from one perfect template. It comes from a system: clear ownership, tested merge fields, monitored failures, secure sending practices, and enough governance that teams can change messages without breaking trust.

Next steps

Next, we move from communication to configuration. In Part 6 — Custom Metadata Types & Custom Settings, you will learn how to take rules, flags, defaults, and routing logic out of hard-coded automation and put them into structures admins and developers can manage safely as the org grows.

Resources

Configure an Email Letterhead and Template Configure a template and letterhead that can be used by all team members for their day-to-day email needs

Email Deliverability Essentials Improve your email deliverability to generate more email marketing revenue.