Messaging.SingleEmailMessage, an email template, and your company's support@ Org-Wide Address. But what if your Marketing team wants to blast 300,000 promotional emails on Black Friday? Do not use Apex for this. Daily send limits exist specifically to force bulk marketing traffic out of core Salesforce and into tools like Marketing Cloud or Account Engagement (Pardot).
๐ฏ Key Points: The Pillars of Salesforce Email
Salesforce email architecture is cleanly split into outbound sending and inbound processing. Understanding the boundaries of each is critical for scalable org design.
- Outbound Architecture: Powered by Apex (
Messaging.SingleEmailMessage), declarative Email Alerts (Flows), and Org-Wide Email Addresses (shared sender identities). - Inbound Architecture: Powered natively by Email-to-Case (for standard routing) or custom Email Services utilizing the
InboundEmailHandlerinterface for complex parsing. - Deliverability Standards: Hitting the inbox requires strict alignment with modern email security protocols: SPF, DKIM, and DMARC, plus active bounce management.
- Governor Limits: Salesforce strictly caps both per-transaction and daily single-email sends. Marketing volume will instantly breach these limits.
๐งญ The 360 Card: Email Architecture & Deliverability
Rule: Keep transactional, record-triggered emails native. Push bulk, promotional, and newsletter emails to a marketing platform.
Gain: By keeping transactional emails native, you get easy access to Lightning Email Templates, Org-Wide Addresses, and Salesforce merge data without building external integrations.
Price: Your domain's sender reputation is directly impacted by whatever your Salesforce org sends. Bad sending practices can blacklist your entire company.
Limits: Daily limits are hard caps. When writing Apex, always construct a single list of messages and call Messaging.sendEmail() exactly once. Never put it inside a for loop.
๐ฌ Core Q&A & Interview Prep
Q: You need to send a templated confirmation email from Apex using a shared support address while respecting governor limits. How do you build this?
Messaging.SingleEmailMessage combined with an Org-Wide Email Address and a Lightning Template. Most importantly, I would bulkify the code by gathering all messages into a list and issuing a single send command."
To build this properly, instantiate a Messaging.SingleEmailMessage for each recipient. Use setTemplateId() so the actual wording is maintained declaratively by admins, not hardcoded in Apex. Use setOrgWideEmailAddressId() to ensure the email comes from a verified, shared address like support@company.com.
Set the targetObjectId (the recipient) and the whatId (the record providing context for merge fields). Crucially, add all these messages to a single List and call Messaging.sendEmail(messageList) outside of any loops. If volume gets too high, this logic must be moved to an asynchronous Batch Apex job to respect transaction limits.
// 1. Create a list to hold all outgoing emails. NEVER send inside a loop.
List<Messaging.SingleEmailMessage> msgs = new List<Messaging.SingleEmailMessage>();
for (Case c : newCases) {
Messaging.SingleEmailMessage m = new Messaging.SingleEmailMessage();
m.setTargetObjectId(c.ContactId);
// 2. Use a template so admins can update the text without a deployment.
m.setTemplateId(templateId);
m.setWhatId(c.Id); // Provides context for merge fields
// 3. Send from a verified shared address, not the user triggering the code.
m.setOrgWideEmailAddressId(owaId);
msgs.add(m);
}
// 4. ONE bulk call sends them all, protecting your governor limits.
Messaging.sendEmail(msgs);
Q: Emails from your Salesforce org are landing in customers' spam folders. What deliverability factors do you check to fix this?
First, check your domain's cryptographic authentication. Major providers like Google and Yahoo now strictly enforce these:
- SPF (Sender Policy Framework): Does your company's DNS record explicitly authorize Salesforce's IP addresses to send mail on your behalf?
- DKIM (DomainKeys Identified Mail): Are you utilizing Salesforce's DKIM key feature to cryptographically sign outbound emails?
- DMARC: Are SPF and DKIM properly aligned with your DMARC policy?
Next, check the Salesforce Org settings. Go to Setup > Deliverability. In a Production environment, this should be set to "All email". (Note: Sandboxes default to "System email only" to prevent accidental test emails from reaching real customers). Finally, verify that Bounce Management is enabled so Salesforce can stop attempting to send to dead addresses, which damages your sender reputation.
Q: Design an inbound email process that creates records and handles attachments. Should you use native tools or write custom Apex?
If the inbound email maps cleanly to a standard support process, always use native Email-to-Case. It automatically handles email threading, routes attachments correctly, and creates or updates Cases without a single line of code.
However, if you need to parse the body of a structured email to populate custom objects, trigger a complex third-party integration, or route data dynamically based on regex patterns, use a custom Email Service. You will write an Apex class that implements the Messaging.InboundEmailHandler interface. This gives you programmatic access to the plain text body, HTML body, headers, and binary attachments. Just remember that Email Services run as an automated process user, so you must carefully validate inputs and respect Field-Level Security.
๐ Connecting the Dots: Follow-Up
Q: How does Salesforce "Email Relay" fit into this architecture if your IT team demands that all outbound emails route through their corporate Office 365 or Google Workspace servers?
Email Relay acts as a secure bridge. Instead of Salesforce delivering emails directly to the recipient's inbox (and thus requiring Salesforce IPs to be added to your SPF records), Salesforce routes all outbound emails securely to your company's own mail servers (like Exchange or Google Workspace). Your corporate mail server then applies its own compliance filters, virus scanning, and DKIM signatures before sending the email to the final recipient. This centralizes IT security and simplifies DNS management.