Salesforce email relay: send from your own domain with MailKite

Salesforce sends email from Salesforce’s infrastructure. When your sales team sends a follow-up, when a flow triggers a notification, when Apex fires an email — it goes out through Salesforce’s mail servers, with Salesforce’s DKIM signature. Your brand name is in the From field, but your domain’s reputation isn’t behind the message.

For most Salesforce orgs, this is invisible. But the moment you care about deliverability — high-value outreach, transactional notifications, compliance-sensitive communications — sending from someone else’s domain is a liability. Gmail sees the mismatch between your From domain and Salesforce’s signature, and DMARC alignment fails.

MailKite fixes this with Salesforce’s built-in Email Relay feature. Here’s the setup.

Why Salesforce’s default email is a problem

Salesforce’s email goes through its own SMTP infrastructure. Three issues:

1. DKIM misalignment. Salesforce signs with its own key. Your domain’s DMARC policy requires alignment with your key. Result: DMARC fails.

2. Shared reputation. Your email shares Salesforce’s sending pool with every other Salesforce org. One bad actor in the pool affects everyone.

3. No inbound routing. Salesforce can send email but can’t receive it at your domain’s addresses. Inbound email needs a separate solution (Email-to-Case, or a third-party parser).

MailKite handles all three: your DKIM key, your domain’s reputation, and inbound email as Salesforce Cases.

The setup

1. Verify your domain in MailKite

Add your domain to the MailKite dashboard. Publish the four DNS records (MX, SPF, DKIM, DMARC). Takes under 5 minutes.

2. Configure Salesforce’s Email Relay

In Salesforce Setup, go to Email → Email Relay and add MailKite:

Setting	Value
SMTP Host	smtp.mailkite.dev
Port	587
Username	mailkite
Password	Your API key (mk_live_…)
TLS	Required (STARTTLS)

Set the relay as the outbound gateway for your org. All Salesforce-originated email — alerts, flows, Apex sends — routes through MailKite.

3. Verify DKIM alignment

Send a test email from Salesforce (via Apex, a flow, or the “Send Email” action). Check the headers:

Authentication-Results: mx.google.com;
  dkim=pass header.d=yourcompany.com
  spf=pass
  dmarc=pass

If DKIM shows Salesforce’s domain instead of yours, the Email Relay isn’t configured as the outbound gateway.

Sending from Apex

Once the relay is configured, standard Apex email calls automatically route through MailKite. No code changes:

Messaging.SingleEmailMessage msg = new Messaging.SingleEmailMessage();
msg.setToAddresses(new String[] { 'customer@example.com' });
msg.setSubject('Invoice #INV-2024-001');
msg.setPlainTextBody('Your invoice is attached.');
msg.setHtmlBody('<p>Your invoice is attached.</p>');
msg.setUseSignature(false);
msg.setBccSender(false);

// The Email Relay handles DKIM signing via MailKite
Messaging.sendEmail(new Messaging.SingleEmailMessage[] { msg });

The setUseSignature(false) prevents Salesforce from adding its own signature on top of MailKite’s.

Flows and email alerts

Record-triggered flows, scheduled flows, and email alerts all use the org’s email relay. Configure them normally — they’ll send through MailKite:

1. Create a Record-Triggered Flow on your object
2. Add a Send Email action or Email Alert
3. The email routes through the Email Relay → MailKite → DKIM-signed from your domain

No code needed. The relay is org-wide.

Receiving inbound email → Cases

MailKite can POST inbound email to a webhook. Create Salesforce Cases from support emails:

// salesforce-webhook.js — Cloudflare Worker or any serverless function
export default {
  async fetch(request, env) {
    if (request.method !== "POST") return new Response("OK");

    const payload = await request.json();
    const { from, subject, text } = payload;

    // Salesforce REST API — create a Case
    const sfRes = await fetch(
      "https://" + env.SF_INSTANCE + ".salesforce.com/services/data/v58.0/sobjects/Case",
      {
        method: "POST",
        headers: {
          Authorization: "Bearer " + env.SF_ACCESS_TOKEN,
          "Content-Type": "application/json",
        },
        body: JSON.stringify({
          Subject: subject,
          Description: text,
          Origin: "Email",
          Status: "New",
          SuppliedEmail: from,
        }),
      }
    );

    return new Response(JSON.stringify({ created: sfRes.ok }), { status: 200 });
  },
};

Set your domain’s webhook to this endpoint. Every inbound email creates a new Case with the sender’s email, subject, and body — ready for your support team.

How it compares

	Salesforce default relay	MailKite Email Relay
DKIM signature	Salesforce’s key	Your key
SPF alignment	Fails (Salesforce IP)	Passes (your domain)
DMARC alignment	Fails	Passes
Sending reputation	Shared (all Salesforce orgs)	Dedicated (MailKite)
Delivery logs	Setup → Email Log files	Dashboard + API
Inbound email	Email-to-Case (limited)	Webhook → any endpoint
Cost	Included in edition	Free tier included

FAQ

Do I need Salesforce Enterprise edition for Email Relay? Email Relay requires Professional Edition or higher. On Essentials, use the MailKite API from an external app (Heroku, Lambda, Cloudflare Workers) to send email triggered by Salesforce.

Will this conflict with Salesforce’s built-in DKIM? If you have Salesforce’s DKIM keys published in your DNS, disable them in Setup → Email → DKIM Keys before enabling the Email Relay. Two DKIM signatures on the same message can confuse some receivers.

Can I use this with Salesforce Marketing Cloud? Marketing Cloud has its own email infrastructure and doesn’t use the standard Email Relay. For Marketing Cloud, you’d configure its own SMTP relay separately. This tutorial covers Salesforce Core (Sales/Service Cloud).

---

Send Salesforce email from your own DKIM-signed domain. Start free — unlimited domains, no credit card.

Related: HubSpot transactional email with MailKite — the same pattern for HubSpot · Zendesk support email — for support teams · Set up email once, reuse every project — the architecture