Blog article

Salesforce domain verification overview:
Salesforce now requires domain verification for all outbound emails sent from its platform. If your company uses Salesforce to send transactional alerts, workflow notifications, or Apex-generated messages, unverified sending domains will cause those emails to fail.
This is an authentication issue – and it points to a broader gap that most enterprise organizations have not yet closed.
See how your domains are configured before Salesforce surfaces the problem for you. Run a free domain analysis.
Salesforce’s Spring ’26 release introduced mandatory domain verification for all email-sending domains. Enforcement began on March 9, 2026.
The key facts:
Salesforce recommends DKIM because it provides cryptographic signing of outbound messages and improves deliverability across all receiving servers.
Salesforce’s requirement surfaces a DNS-level control that many businesses have deferred.
DKIM is not a Salesforce-specific configuration. DKIM is a public key published in your domain’s DNS that receiving servers use to verify message signatures.
A company that doesn’t have DKIM configured for its sending domains is exposed to spoofing and impersonation. Attackers can send emails that appear to originate from your domain, and without an active DKIM signature, receiving servers have no way to verify the message is legitimate.
Configuring DKIM in Salesforce only covers emails sent through Salesforce. Your other sending services – marketing platforms, transactional email tools, HR systems, finance applications – each require their own DKIM configuration.
If Salesforce’s requirement has exposed an authentication gap, start with scope before you begin configuration.
Audit your sending domains first. Identify every domain used to send email across your environment – not just Salesforce. Most enterprise organizations send from multiple domains across a range of platforms, and not all of them are visible to the security team.
Check existing DKIM and DMARC records for each domain. Use lookup tools to confirm whether records are active and correctly formatted.
Prioritize active sending domains. Verify and activate DKIM for domains currently in use before addressing dormant domains.
Do not treat Salesforce DKIM setup as the end state. The same domain that sends from Salesforce almost certainly sends from other platforms. Each requires its own DKIM key, and each gap is an independent exposure.
Use this requirement as the trigger to escalate your DMARC policy. If your DMARC record is still at p=none, your domain isn’t protected – it’s monitored. Salesforce’s enforcement requirement is a defensible reason to start the escalation path toward p=quarantine and then p=reject.
Salesforce’s requirement is part of a broader industry shift toward mandatory email authentication.
In February 2024, Google and Yahoo announced they would begin requiring bulk senders to implement SPF and DKIM, and to publish a DMARC record with a minimum policy of p=none. Senders who did not comply faced rejection or placement in the Spam folder. In May 2025, Microsoft joined with equivalent requirements for high-volume senders.
The pattern is consistent: Google, Yahoo, Microsoft, and now Salesforce all require domain verification before they will deliver your mail. Authentication is no longer a recommendation. It is a condition of sending.
As more platforms enforce domain verification, businesses that haven’t progressed beyond p=none will face increasing operational disruption – failed sends, altered “From” addresses, and email flows that break without warning.
Salesforce’s requirement makes one problem visible: Your company’s email authentication posture across all sending domains. For most enterprise environments, that posture is inconsistent – some domains are fully configured, others partially configured, and some have no authentication controls at all.
Security and IT teams managing distributed environments face several compounding challenges: Incomplete visibility into every domain and sending service, difficulty coordinating DNS changes across departments and regions, and no centralized reporting to confirm what’s protected and what isn’t. Without continuous monitoring, gaps accumulate quietly until a platform enforcement event makes them operational problems.
Sendmarc provides unified visibility across your DMARC, SPF, and DKIM configurations. DMARC Management surfaces every sending source and policy state across your domains, so you can identify what’s unverified, what’s misconfigured, and what requires immediate action – before the next deadline, not after.
See how Sendmarc strengthens your authentication posture across your entire email environment.