Tag: ai

Salesforce Now Requires Email Domain Verification

If you send emails through Salesforce, there’s an important update you need to pay attention to. Starting March 9, 2026, Salesforce has rolled out a new requirement — you must now prove that you own the email domain you’re sending from.

The current image has no alternative text. The file name is: image.png

So, What Is Email Domain Verification?

Think of it this way — when Salesforce sends an email on your behalf (say, from yourname@yourcompany.com), it now needs to confirm that your organization actually owns the domain “yourcompany.com”.

Without this verification, Salesforce will simply stop delivering those emails. That means leads, customers, and colleagues might never receive messages you send through Salesforce — without any error message warning you.

Who Does This Affect?

This affects anyone who sends emails through Salesforce using a custom company domain — like @yourcompany.com, @yourbrand.in, etc.

The good news? You’re not affected if you send emails using:

  • Personal email addresses like Gmail (@gmail.com) or Outlook (@outlook.com)
  • Gmail or Office 365 integrations connected to Salesforce
  • Einstein Activity Capture (EAC)
  • Free or trial Salesforce orgs

What Are the Deadlines?

Salesforce is giving everyone a little time to get this done, but the clock is ticking:

  • New domains → Verification required right now, immediately
  • Sandbox orgs (used for testing) → Verify by March 30, 2026
  • Production orgs (your live Salesforce environment) → Verify by April 27, 2026

The safest move? Do it as soon as possible — don’t wait until the last day.

How Do You Verify Your Domain?

There are two ways to do this. Your IT team or Salesforce Admin will handle the technical parts, but here’s a plain-English explanation of both:

Option 1: DKIM (Recommended ✅)

DKIM stands for DomainKeys Identified Mail — it’s basically a digital signature that gets attached to your emails, proving they’re genuinely from your domain.

Setting it up involves generating a key inside Salesforce and then adding a small record to your domain’s DNS settings (that’s managed wherever you registered your domain — like GoDaddy, Cloudflare, etc.).

Once it’s active, your domain is considered verified. This is the method Salesforce recommends.

Option 2: Authorized Email Domains

If you’d rather not use DKIM, you can verify your domain through Salesforce’s Authorized Email Domains setup. Here’s how it works, step by step:

In Salesforce:

  1. Go to Setup and search for Authorized Email Domains in the Quick Find box
  2. Click Add
  3. Type in your domain name (e.g., yourcompany.com)
  4. Click Save
  5. Salesforce will generate a verification key — copy it

In your DNS settings (done by your IT team):

  1. Log into wherever your domain is managed (GoDaddy, Cloudflare, Route 53, etc.)
  2. Add a new TXT record with either _sfdv.yourcompany.com or yourcompany.com as the name
  3. Paste the verification key Salesforce gave you as the value
  4. Save the record

Back in Salesforce:

  1. Go back to Authorized Email Domains in Setup
  2. Find your domain and click Edit
  3. Turn on Verify domain ownership
  4. If everything is set up correctly, it’ll confirm successfully. If not, wait a few minutes for the DNS change to spread across the internet, then try again.

One More Thing — User Email Verification Still Applies

Even after your domain is verified, each individual user’s email address still needs to be verified separately. Domain verification and user verification are two different things — both are required.

The Batch Apex “Ghost Data” Mystery: Why finish() Sees What execute() Missed

Have you ever experienced this Salesforce scenario? Your Batch Apex job marks itself as “Completed,” yet you discover thousands of records that were never touched by your business logic. You check debug logs for the execute() methods and find nothing for those records. Yet, oddly, the finish() method seems aware of the total scope.

Welcome to the nuances of Batch Apex Transaction Isolation.

This post solves the mystery of why your finish() method can query data from the original start() scope that individual execute() methods never successfully processed.

The High-Level: It’s About Boundaries

In Salesforce Batch Apex, the finish() method executes in a completely separate transaction after all batches have completed (or failed).

Because of transaction isolation, each execute() chunk runs independently. If a chunk fails due to governor limits or unhandled exceptions, that entire chunk rolls back silently. The records in that chunk are never committed to the database in their processed state.

However, finish() gets the “30,000-foot view” post-completion. It can see the final state of the database (where those records still look unprocessed) and query the job metrics to see exactly what went wrong.

Batch apex, salesforce, flow

Visualizing the Disconnect

Here is the flow of a batch job. Notice how the execute() chunks are isolated lanes, while finish() is a separate checkpoint at the end.

Detailed Breakdown: Transaction Isolation

Batch Apex processes records in rigid, isolated transactions. Each execute() handles its scope (e.g., 200 records) with its own brand new set of governor limits.

If Chunk 3 hits a CPU timeout or a “Too many SOQL queries” error:

  1. The execution stops immediately.
  2. All DML operations within that specific chunk transaction are rolled back.
  3. Crucially: The job does not abort. It moves on to Chunk 4.

The records in Chunk 3 remain untouched in the database.

When the finish() method finally runs in its own isolated transaction, it accesses two key things:

  1. Full Job Metrics: By querying AsyncApexJob, it sees the reality of the failures.
  2. Database State: It sees the database exactly as it is. Since Chunk 3 rolled back, re-querying the original criteria reveals records that still match the “unprocessed” criteria.

Example Scenario: You have 1,000 records split into 5 chunks of 200. Chunk 3 fails on a governor limit.

  • execute() view: It never finished processing those 200 records.
  • finish() view (via AsyncApexJob): TotalJobItems: 5, NumberOfErrors: 1, ExtendedStatus: "System.LimitException: Too many SOQL queries: 101"

The Code That Reveals the Discrepancy

Use your finish() method to act as the source of truth by querying the job status directly.

global void finish(Database.BatchableContext bc) {
    // 1. Query the AsyncApexJob to get the true execution metrics
    AsyncApexJob job = [SELECT Id, Status, NumberOfErrors,
                        TotalJobItems, CompletedDate, ExtendedStatus
                        FROM AsyncApexJob WHERE Id = :bc.getJobId()];
    System.debug('Job finished. Total Batches: ' + job.TotalJobItems);
    System.debug('Batches with Errors: ' + job.NumberOfErrors);
    if (job.NumberOfErrors > 0) {
        // ExtendedStatus often contains the specific limit exception message
        System.debug('Failure Reason (ExtendedStatus): ' + job.ExtendedStatus);
        // Optional: Re-run the original start query to identify exactly which
        // records remain unprocessed in the database.
        // List<Account> unprocessed = Database.query(yourOriginalSOQLString);
        // System.debug(unprocessed.size() + ' records remain unprocessed in DB.');
    }
}