Email Services
Email Services is the Salesforce framework that lets the platform receive inbound email and process it through Apex code.
Definition
Email Services is the Salesforce framework that lets the platform receive inbound email and process it through Apex code. Each Email Service is a configuration linking a generated Salesforce email address to an Apex class implementing the Messaging.InboundEmailHandler interface. When mail arrives at the address, the platform parses the headers, body, and attachments, constructs an InboundEmail object, and invokes the Apex handler. The handler returns an InboundEmailResult indicating whether to acknowledge or reject the message.
Email Services predate Email-to-Case and remain the foundation for custom inbound email processing. Where Email-to-Case is a packaged feature for converting mail into Case records with limited customization, Email Services is the raw building block: any inbound email logic that does not fit the Email-to-Case model lands here. Common uses include parsing structured email from external systems (purchase orders, automated notifications), building custom case routing logic, and integrating with mail-based workflows that Email-to-Case cannot handle.
How Email Services process inbound mail
The InboundEmailHandler interface
An Apex class implementing Messaging.InboundEmailHandler exposes a single method: handleInboundEmail(InboundEmail email, InboundEnvelope envelope). The InboundEmail object surfaces headers, plain-text body, HTML body, binaryAttachments, textAttachments, FromAddress, ToAddresses, Subject, and the In-Reply-To header for threading. The handler returns an InboundEmailResult with success/failure status and an optional message. The platform routes responses based on the result: success acknowledges to the sender, failure can bounce.
Email Service addresses
Each Email Service generates one or more addresses of the form local-part@hash.region.apex.salesforce.com. The local-part is user-defined and unique within the service; the hash and domain are platform-assigned. Multiple addresses can be assigned to a single service, useful for routing different inbound streams (purchase-orders, support, notifications) through the same handler with different processing logic based on the To address.
User context and execution limits
Each Email Service runs as a specific Salesforce User (the Run As user). Apex executes with that user permissions, sharing, and field visibility. All standard governor limits apply: SOQL queries, DML statements, CPU time. The platform limits inbound email volume per organization based on the user license count, with bounces or queuing if the limit is exceeded. Plan handler code to handle bursts; a daily report sent to your address as a batch will burn through limits quickly.
Attachments and 25 MB cap
Inbound messages including attachments cap at 25 MB total per message. Attachments arrive as two arrays on the InboundEmail object: binaryAttachments and textAttachments. Most code only processes binary attachments, but plain-text attachments (.txt, .csv) come through the textAttachments array and are silently dropped by code that does not handle them. Test handler code against multi-attachment messages with mixed content types.
Email-to-Case versus Email Services
Email-to-Case is built on top of Email Services. For Case-related inbound mail, prefer Email-to-Case because it provides Case threading, auto-response rules, and assignment integration. Use Email Services directly for any non-Case use case: order confirmations, partner integrations, notification ingestion, custom routing logic. The two can coexist; an org can have Email-to-Case for support and a custom Email Service for purchase orders.
Bounce handling and the From address
The framework lets handler code reject a message by returning an InboundEmailResult with success = false. Depending on the Authorized Senders configuration, the rejection either bounces back to the sender or fails silently. The From address is the only thing the handler can use to identify the sender, and it can be spoofed; never trust the From address for authentication. Use SPF or DKIM validation through downstream code if the source claims to be a trusted partner.
Production deployment
Email Services are metadata, deployed through changesets, SFDX, or unmanaged packages. Each Service must be activated in the target org, and the platform regenerates the email addresses on activation; the addresses are not portable across orgs. Plan downstream system configuration (the external partner sending to your address) for re-pointing after sandbox-to-prod deployments.
Stand up an Email Service end to end
Setting up an Email Service involves writing the handler class, configuring the service, generating the address, and testing the end-to-end flow. The steps below cover the full path from zero to a working inbound endpoint.
- Write the Apex handler
Create an Apex class implementing Messaging.InboundEmailHandler. Implement handleInboundEmail to parse the InboundEmail object and write the result to your target sObject. Include error handling and logging.
- Deploy the handler to the target org
Deploy through SFDX or a changeset. Confirm the class compiles and at least one Apex test covers the handler logic; the platform requires test coverage before deployment to production.
- Create the Email Service
Setup > Custom Code > Email Services > New Email Service. Name the service, link to your Apex class, set Active to true.
- Configure failure response
Under Failure Response, choose whether unrecognized senders are bounced, the message is requeued, or discarded silently. Pick Bounce for partner integrations so the sender knows the message did not process.
- Set authorized senders
Under Authorized Senders, list the email addresses or domains that are allowed to send to this address. Leave blank to accept all senders; restrict for partner-only inbound channels.
- Generate the email address
Click New Email Address on the service. Define the local-part, link to a Run As user, save. The platform generates the full address with the hash and apex.salesforce.com domain.
- Test end-to-end
Send a test message to the generated address. Confirm the handler fires (check debug logs), the result is written to the target sObject, and any reply or bounce behaves as expected.
The handler class implementing Messaging.InboundEmailHandler. The core processing logic for the inbound mail.
The Salesforce User the handler runs as. Determines permissions, sharing, and field visibility during execution.
Comma-separated list of allowed addresses or domains. Leave blank to allow any sender; populate for partner-only inbound.
Bounce, Discard, or Requeue. Bounce notifies the sender on processing failure; Discard fails silently; Requeue retries.
Master switch for the service. Set inactive to pause inbound processing without losing the address or configuration.
- Apex governor limits apply per inbound message. A handler doing too many SOQL queries or DML operations hits the limit and fails the message, with no automatic retry unless Failure Response is set to Requeue.
- The Run As user must have permissions to write to the target sObject. A handler running as a low-privilege user silently fails on the DML if record access is missing.
- Email addresses are regenerated on every service activation. Sandbox refreshes or service re-activations produce a new address, which breaks any partner integration pointing at the old one.
- Authorized Senders comparison is case-insensitive but otherwise exact. A pattern like the partner domain works as a wildcard; user at partner domain is exact match only.
- The handler runs synchronously inside the email processing call. Long-running handlers (over a few seconds) risk timeout; offload heavy work to a queueable or future method called from the handler.
Trust & references
Straight from the source - Salesforce's reference material on Email Services.
- Email ServicesSalesforce Help
- What Are Email Services?Salesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. Why is understanding Email Services important for Salesforce admins?
Q2. In which area of Salesforce would you typically find Email Services?
Q3. What is the primary benefit of Email Services for Salesforce administrators?
Discussion
Loading discussion…