Fixing Salesforce Emails Going to Spam: DKIM Setup Step-by-Step (QA to Prod)

 If your Salesforce emails are landing in SPAM (or not being trusted by Gmail / Outlook), the most common reason is missing DKIM configuration.

This guide walks through:

• What DKIM is

• Why Salesforce emails fail without it

• How to set up DKIM safely in a lower sandbox

• DNS validation, activation, and testing

• How to roll it cleanly into Production

This is written from a real implementation + troubleshooting perspective, not theory.

---

What Is DKIM (and Why It Matters)

DKIM (DomainKeys Identified Mail) allows Salesforce to cryptographically sign outgoing emails using your company’s domain.

Mail providers use DKIM to verify:

• The email genuinely came from Salesforce

• Salesforce is authorized to send on behalf of your domain

• The email content wasn’t altered

Without DKIM:

• Emails look spoofed

• Spam filters downgrade trust

• Automated Salesforce emails often land in junk

---

How DKIM Works with Salesforce (High-Level Flow)

1. Salesforce generates DKIM keys internally

2. Salesforce provides CNAME DNS records

3. IT publishes those records in the domain’s DNS

4. Salesforce verifies DNS

5. DKIM is activated

6. Salesforce signs all outbound emails

⚠️ The private DKIM key never leaves Salesforce.

---

Why You Should Start in a Lower Sandbox

DKIM is org-specific, which means it is safe and recommended to test in:

• QA

• UAT

• PDX

Benefits:

• No Production risk

• Full validation of DNS and headers

• Easy troubleshooting before rollout

Only SPF is domain-level; DKIM can be validated per org.

---

Step 1: Create DKIM Keys in Salesforce (Sandbox)

Navigate to:

Setup → DKIM Keys → Create New Key

Recommended values:

Field	Value
Key Size	2048-bit
Selector	sfdc-qa
Alternate Selector	sfdc-qa2
Domain	yourcompany.com
Domain Match Pattern	.*@yourcompany\.com

Some orgs require an Alternate Selector. This supports key rotation and is a good long-term practice.

---

Step 2: Understand the DNS Records Salesforce Generates

After saving, Salesforce generates CNAME records like:

sfdc-qa._domainkey.yourcompany.com
→ sfdc-qa.xxxxxx.custdkim.salesforce.com

sfdc-qa2._domainkey.yourcompany.com
→ sfdc-qa2.yyyyyy.custdkim.salesforce.com

These CNAMEs are the only thing IT needs.

❌ You do NOT send a “DKIM key”
✅ You send DNS records

---

Step 3: Where IT Adds DKIM Records

IT adds these records in the DNS provider that manages your domain, for example:

• AWS Route 53

• Cloudflare

• GoDaddy

• Azure DNS

Each record must be:

• Type: CNAME

• Hostname: exactly as Salesforce provides

• Value: exactly as Salesforce provides

Both primary and alternate selectors must exist.

---

Step 4: Verify DNS Before Activating DKIM

Before clicking Activate, confirm DNS resolution:

nslookup sfdc-qa._domainkey.yourcompany.com
nslookup sfdc-qa2._domainkey.yourcompany.com

If either returns NXDOMAIN, Salesforce will disable Activate.

This is the #1 reason people get stuck.

---

Step 5: Activate DKIM in Salesforce

Once both records resolve:

• Refresh the DKIM page

• Click Activate

Activation is instant. No deploy. No downtime.

From this moment, Salesforce signs all outbound emails.

---

Step 6: Send Test Emails and Verify Headers

Send test emails to:

• One internal address

• One external Gmail / Outlook address

Check email headers. You should see:

DKIM=PASS
dkim=pass header.d=yourcompany.com

SPF may still show SOFTFAIL until SPF is updated — that’s expected.

---

Common Issues (and Fixes)

Activate Button Disabled

Cause:

• One or more DKIM CNAME records missing or not propagated

Fix:

• Verify both selectors with nslookup

• Ensure record type is CNAME, not TXT

---

Only One Record Added

Cause:

• IT added only the primary selector

Fix:

• Add both primary and alternate CNAME records

---

Emails Still Go to Spam

Likely missing:

• SPF update (include:_spf.salesforce.com)

• DMARC alignment

DKIM improves trust, but SPF completes authentication.

---

Rolling This into Production

Repeat the same steps in Production, using new selectors:

• sfdc-prod

• sfdc-prod2

Never reuse sandbox selectors in Prod.

SPF update is done once, domain-level.

---

Final Takeaways

• DKIM is essential for Salesforce email deliverability

• Always validate in a lower sandbox first

• You never share a DKIM private key — only DNS records

• Both selectors must resolve before activation

• Activation is immediate once DNS is verified

Once DKIM is active, email trust improves immediately.

---

If you want next:

• ✍️ Confluence-formatted version

• 🧾 Production rollout checklist

• 📧 SPF + DMARC follow-up post

• 🔗 Short LinkedIn version

LWC key Features #Salesforce

Lightning Web Components (LWC) is a new programming model for building web components on the Salesforce platform. It’s a modern, lightweight, and fast alternative to Aura components and offers a number of new features and benefits to developers.

Here are some key features of LWC:

Modern Web Standards: LWC is built on modern web standards like ES6, HTML, and CSS. This makes it easy for developers who are already familiar with these technologies to get started quickly with LWC.


Reusable Components: Components can be easily reused across multiple pages and applications in Salesforce. This helps reduce duplication of code and saves time for developers.


Lightning-Fast Performance: LWC uses a shadow DOM to encapsulate component logic and styles, which helps ensure lightning-fast performance.


Easy Integration with Apex: LWC components can easily integrate with Apex code to access server-side functionality. This enables developers to create complex applications that can scale to meet business needs.


Strong Security: LWC components are secure by design, which helps prevent XSS attacks and other types of security vulnerabilities.

Let's look at a simple example of how to create an LWC component in Salesforce.

Here’s a component that displays a greeting:

php
<template>
  <p>Hello, {greeting}!</p>
</template>

<script>
export default class Greeting extends LightningElement {
  @track greeting = 'World';
}
</script>

In this example, we’re using the <template> tag to define the HTML template for our component. The <p> tag displays the greeting, which is stored in a property called greeting.

The <script> tag contains the JavaScript logic for our component. We’re using the export default statement to make our component available to other parts of our application. The LightningElement class provides the core functionality for our component, and the @track decorator is used to indicate that the greeting property should be reactive, meaning that any changes to its value will automatically be reflected in the HTML template.

And that’s it! With just a few lines of code, we’ve created a fully functional LWC component that can be used in a Salesforce application.

In conclusion, LWC is a powerful and modern way to build web components for the Salesforce platform. With its modern web standards, reusable components, lightning-fast performance, easy integration with Apex, and strong security, it’s a great choice for any Salesforce developer.