Blog article

Author Profile Picture

What Salesforce’s Domain Verification Requirement Means

Salesforce Logo In A Blue Digital Environment With Network Connections

Salesforce domain verification overview:

  • Salesforce now requires domain verification for all outbound emails. Emails sent from unverified domains won’t be delivered.
  • Two verification methods are available: An active DKIM key (recommended) or adding the domain to the Authorized Email Domains list.
  • DKIM is a DNS-level control. Configuring it in Salesforce only covers emails sent through Salesforce – every other sending platform requires its own DKIM key.

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.

If you’re at risk of impersonation, one of our experts will be in touch to assist.

What Changed in March

Salesforce’s Spring ’26 release introduced mandatory domain verification for all email-sending domains. Enforcement began on March 9, 2026.

The key facts:

  1. Salesforce now requires domain verification in addition to the existing requirement to verify individual email addresses.
  2. Two domain verification methods are available: Set up an active DKIM key (Salesforce’s recommended approach) or add the domain to the Authorized Email Domains list.
  3. Emails sent from unverified domains fail. Admins can identify failures in Salesforce email logs by looking for the error code: 550 5.7.1 Delivery not authorized, message discarded.

Salesforce recommends DKIM because it provides cryptographic signing of outbound messages and improves deliverability across all receiving servers.

What This Means Beyond the Salesforce Admin Console

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.

How To Approach Domain Verification

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.

The Broader Enforcement Pattern

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.

Know Where You Stand Before the Next Deadline

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.