Salesforce email deliverability: access levels, DKIM, relays

Start with the setting that stops mail entirely. In Setup, under *Email → Deliverability*, the Access to Send Email level controls whether the org can send at all: no access, system email only, or all email. Sandboxes are deliberately restrictive — a refresh resets them so you cannot mail real customers from a test org — and every "Salesforce stopped sending" ticket should check this first. Production orgs can also be reduced to system-only by an admin change nobody announced.

The same page holds bounce management and the options that control whether Salesforce stamps its own compliance footers and how bounced addresses are flagged on records.

Make Salesforce mail authenticate as your domain

By default, mail Salesforce sends on your behalf is signed by Salesforce, so DMARC cannot align with your From domain. If your organisational domain publishes p=quarantine or p=reject, that is a filtering problem waiting to happen.

Fix it in Setup under *Email → DKIM Keys*: create a key for your domain, choose the selectors, and publish the DNS records Salesforce generates at your DNS host. Take the exact hostnames from that screen — they are org-specific. Activate the key once DNS resolves, then verify from the receiving side: send a test, open the raw headers, and confirm dkim=pass with your domain in header.i= and dmarc=pass with header.from= on your domain.

Two related pieces:

• Organisation-wide addresses (Setup → *Email → Organization-Wide Addresses*) let teams send from a shared, verified address rather than each user's own, which is usually what you want for case notifications.
• SPF: if you add a Salesforce include to your SPF record, count your DNS lookups first. The limit is 10 per record and exceeding it is a permerror that breaks every sender on the domain at once.

Email Relay, and when it is the right answer

*Email → Email Relay Activation* routes Salesforce's outbound mail through your own mail server or ESP instead of Salesforce's infrastructure. Reasons to use it:

• All company mail then leaves from one place, with one reputation, one set of logs and one suppression list.
• You can apply your existing DKIM signing, archiving and compliance rules.
• You get the receiver's SMTP responses in your own logs rather than inferring from Salesforce's bounce flags.

Reasons not to: it makes your mail server a dependency for case and workflow email, and a misconfigured relay drops mail silently. If you turn it on, restrict the relay to Salesforce's IP ranges, test with Email Log Files (Setup → *Email Log Files*) before cutting over, and keep a documented rollback.

Know which Salesforce is sending

This is where diagnostics go wrong. The sending path, the limits and the authentication are different per product:

Sales outreach belongs on the third path. Bulk list email from the CRM to a cold list belongs nowhere — use a marketing platform with proper consent, suppression and unsubscribe handling.

A fix order that works

1. Confirm the Deliverability access level in the org you are actually testing.
2. Create and activate DKIM keys, publish SPF carefully, and verify alignment from real headers.
3. Turn on bounce management and make sure bounced addresses are visible on the record, not just counted.
4. Check Email Log Files for the receiver's responses before theorising about content.
5. Separate streams: notifications and workflow mail on a subdomain of their own, marketing on its own, sales replies from real mailboxes.
6. Measure placement independently per provider with a seed test, because Salesforce reports sends and bounces, not folders.

What not to do

• Do not use the CRM's list email for prospecting. There is no real unsubscribe infrastructure behind it and complaints land on your corporate domain.
• Do not assume a sandbox is misconfigured when it refuses to email external addresses. That is the intended behaviour.
• Do not add a Salesforce SPF include without counting lookups.
• Do not leave DKIM inactive after publishing the records. Creating the key is not activating it.
• Do not treat Marketing Cloud's deliverability as the same problem as the CRM's. Different infrastructure, different fix.

MailPilot does not integrate with Salesforce, and we are not going to imply it does. What it covers is the sending identity underneath: SPF, DKIM and DMARC verification for your sending domains, warm-up for the Gmail, Outlook or SMTP mailboxes your reps actually send from, real per-provider inbox placement measurement, and daily per-mailbox reputation tracking.