Guide
Email deliverability for Salesforce: keep your Marketing Cloud emails out of spam
Updated for 2026 · 5 min read
Salesforce Marketing Cloud is a powerful platform, but it is also a common source of deliverability problems. If your Salesforce emails are landing in spam, the issue is almost never the copy. It is the DNS records and sender reputation behind your sending domain. This guide covers the specific deliverability setup a Salesforce Marketing Cloud user needs.
The six DNS records your domain must have
Every sending domain needs six records. Salesforce handles some of these for you, but you still need to verify they are actually published and not conflicting.
- MX: a valid MX record so the domain is not treated as a throwaway. The MX checker confirms it resolves.
- SPF: a TXT record listing the servers allowed to send for the domain. Salesforce adds its own SPF include. If you also have a hand-written SPF, you can exceed the 10-DNS-lookup limit and break authentication. Use the SPF checker to see your effective record and catch that.
- DKIM: a signature proving the message came from you. Salesforce has its own DKIM selector. If you send through more than one provider you need one DKIM record per provider. The DKIM checker finds your live key and flags weak (1024-bit) or missing keys.
- DMARC: the policy that tells receivers what to do with unauthenticated mail. Start at
p=none, read the reports, then move to p=quarantine and finally p=reject. The DMARC checker shows your current policy and the DMARC report parser turns the XML reports into a list of who is actually sending as you.
- Reverse DNS (PTR): the IP that sends your mail should resolve back to a hostname that matches your sending domain. The PTR checker confirms it.
- TLS: a valid TLS certificate on the mail server. An expired or misconfigured certificate is a quiet killer. The TLS checker confirms it.
Salesforce-specific gotchas
- Shared vs dedicated IP. Salesforce Marketing Cloud lets you use a shared IP or a dedicated IP. On a shared IP, other senders can drag your reputation down. If you are sending high volume, a dedicated IP is worth the cost.
- Warm-up is not automatic. Salesforce does not warm up your sending domain for you. If you are new to Salesforce or you just switched domains, you need to ramp volume over 2 to 4 weeks. The warm-up calculator gives you a daily send schedule.
- Multiple sending domains. If you send from multiple domains (e.g. your main domain and a subdomain for campaigns), each domain needs its own SPF, DKIM, and DMARC records. The deliverability checklist covers the full setup.
- Salesforce's SPF include. Salesforce adds
include:salesforce.com to your SPF record. If you have other sending services, make sure your SPF record does not exceed the 10-DNS-lookup limit. The SPF checker catches this.
Monitoring: the part most teams skip
Deliverability is a state, not a setup. Records rot, IPs get listed, and providers change their rules. The teams that stay in the inbox are the ones watching. The monitoring guide covers the full setup.
Run the free audit against your Salesforce sending domain and it checks SPF, DKIM, DMARC, MX, TLS and IP reputation in about 30 seconds, then tells you exactly which of the above is broken.
Check your Salesforce domain free, no signup. SPF, DKIM, DMARC, TLS and IP reputation in ~30 seconds.
Run a free audit
Related: Shopify · WordPress · WooCommerce · Squarespace · Wix · HubSpot · all guides
Need continuous monitoring of your Salesforce sending domain? Inboxproof Pro re-checks your records daily and emails you the moment authentication or reputation breaks.