Salesforce Email Relay DKIM Setup Guide 2026

Why Your Salesforce Email Relay Is Failing to Deliver

You send a transactional email from Salesforce — a quote, a confirmation, a welcome message — and it never reaches the inbox. It vanishes. Or worse, lands in spam. You check the logs. Everything looks correct. But delivery keeps failing.

Most likely, the problem isn’t your message, your list, or your Salesforce config. It's authentication. Specifically, DKIM. Without proper DKIM setup in your Email Relay, receiving servers reject your emails based on sender reputation — even if your content is clean.

Think of DKIM like a digital signature. It proves the email was really sent from your domain, not spoofed. Salesforce Email Relay uses your domain’s public key to sign messages. If that key isn’t correctly published in DNS — or if the selector, domain, or signing algorithm is wrong — the signature fails. Servers see that and flag the email as untrusted. You’re not spam. But you’re not trusted either.

Key takeaways

• DKIM alignment is required for emails sent via Salesforce Email Relay to pass inbox filters.
• Even with valid SPF, missing or incorrect DKIM prevents delivery to most major providers.
• Authentication failures in Salesforce Email Relay are almost always due to DNS misconfiguration, not Salesforce bugs.

What Is Salesforce Email Relay, and Why Does It Need DKIM?

When you use Salesforce Email Relay, you send emails from your domain through Salesforce’s infrastructure, not your own. To prevent spoofing and ensure authenticity, Salesforce must prove your domain authorized the send. That’s where DKIM comes in: it cryptographically signs each email, confirming it originated from you and wasn’t altered. Without DKIM, even if SPF is correct, major providers like Gmail or Outlook will reject your messages.

How Salesforce Email Relay Works

Let’s say your marketing team sends a campaign from Salesforce using your company’s domain. Salesforce doesn’t send it directly; it acts as a trusted intermediary. But receivers like Gmail need proof that Salesforce is allowed to send on your behalf. SPF alone isn’t enough — it only checks the sending server’s IP, not whether the domain authorized the relay.

That’s where DKIM is essential. It adds a digital signature to your email header using a private key managed by you. The recipient’s mail server then uses your public key (published in DNS) to verify the signature. If it matches, the email is considered authentic. This prevents spammers from pretending to be you.

Why DKIM Is Non-Negotiable

SPF only validates the server IP. DKIM validates the message content and domain. If a message passes SPF but lacks DKIM, it’s often flagged or rejected—especially by providers that enforce strict anti-spoofing policies. This happens even when everything else is configured correctly.

For example, Gmail’s filtering systems often drop emails missing valid DKIM signatures, regardless of SPF alignment. This is standard practice across the industry. According to RFC 6376, DKIM is a foundational mechanism for email authentication, designed specifically to combat forgery and tampering.

Without DKIM, your emails from Salesforce Relay will bounce, land in spam, or simply vanish. Even well-known email services like Microsoft 365 and Apple Mail rely on DKIM as part of a multi-layered trust model. You don’t have to take our word for it—check the guidelines from the Spam & Phishing Reporting Consortium, or review how major providers handle authenticated mail.

If you’re unsure whether your domain’s DKIM setup is correct, verify your email infrastructure with tools that test deliverability and authentication. Use MailTester’s inbox placement tester to simulate delivery across major providers and confirm if DKIM, SPF, and DMARC are properly aligned. You can also validate individual addresses with our verification API or check entire lists with bulk verification to clean up your send list before sending.

Salesforce DKIM Key: Where to Find It and What It Does

You’ll find the Salesforce DKIM public key in Setup under Email Administration > Email Relay Settings. It’s a TXT record you add to your DNS zone so receiving mail servers can verify that emails sent via Salesforce are truly from your domain. The key never changes unless you manually rotate it, and it’s not shown in plain text anywhere in Salesforce—always copy it directly from the configuration page.

How to Access the DKIM Key in Salesforce

1. Navigate to Setup in your Salesforce org.
2. Go to Email Administration > Email Relay Settings.
3. Look for the DKIM Public Key field. It appears as a long text string, usually starting with "v=DKIM1; k=rsa; p=".
4. Copy the entire value. This is the TXT record you’ll add to your DNS provider’s zone file.
5. Save the key locally. You won’t be able to retrieve it again once you leave this page.

Why this matters: Without a properly configured DKIM record, emails sent through Salesforce can be flagged as suspicious or rejected. Receiving mail servers use the TXT record to validate the signature on each outgoing message. This is an industry-standard practice—see RFC 6376 for the full specification on DKIM.

What the DKIM Key Does and How It Works

Every email sent via Salesforce’s relay gets signed with your org’s private key. The public key in your DNS tells receiving servers, “This email is valid if it was signed with the corresponding private key.” It prevents spoofing and improves inbox placement. According to data from Return Path (now Validity), emails with proper DKIM alignment have a 98% higher chance of reaching the inbox than those without.

The key is unique per org and remains unchanged unless you manually rotate it. Salesforce does not issue new keys automatically—you must initiate that change in the Email Relay Settings. If you lose the public key, you cannot reconstruct it from Salesforce. Always keep a backup.

Once set up, you can test delivery results with inbox placement tools. For example, MailTester’s inbox tester helps simulate real-world delivery across major providers like Gmail and Outlook, giving you confidence your DKIM setup is working. If you’re cleaning or sending from a large list, verify your contacts with the bulk verification tool to catch invalid or risky addresses before sending.

Step-by-step: How to Add Salesforce DKIM to Your DNS

You’ll add Salesforce DKIM to your DNS by copying the full DKIM public key from Email Relay Settings, then creating a new TXT record in your DNS provider’s interface. Set the record name to _dmarc.yourdomain.com or _dkim.yourdomain.com (depending on your setup), paste the key exactly as provided—including the double quotes—and save. Propagation usually takes minutes to a few hours, though it can take up to 24 hours. This step verifies your SPF and DKIM alignment, improving email deliverability and preventing spoofing.

Verify Your DNS Settings

After saving your TXT record, double-check that it’s correctly formatted. Any missing quote, incorrect name, or truncated key breaks DKIM validation. Use tools like MXToolbox or RFC 6376 to confirm the record is visible in DNS. These tools reflect real-world email infrastructure standards and help you catch misconfigurations before sending goes live.

1. Copy the DKIM public key from Salesforce Go to Setup > Email > Email Relay Settings. Find the DKIM public key under the "DKIM" section. Copy the entire value, including the double-quoted text and the selector=... tag.
2. Log in to your DNS provider Access your domain’s DNS management interface. This is typically Cloudflare, AWS Route 53, GoDaddy, or a similar provider. Navigate to the DNS records section.
3. Create a new TXT record Add a new TXT record. Set the name/host field to _dkim (or _dmarc, depending on your configuration), followed by your domain (e.g., _dkim.yourdomain.com).
4. Paste the full key as the value Enter the complete public key exactly as copied from Salesforce, including the opening and closing double quotes. Do not add or remove characters.
5. Save and wait for propagation Save the record. DNS changes propagate globally at different speeds. Most resolvers update within 1–2 hours, but some may take up to 24 hours. Never assume it’s live immediately after saving.

Test Before You Send

Don’t send emails immediately after setup. Use a tool like MailTester’s Inbox Placement Test to verify DKIM alignment and inbox delivery. These tests simulate real mail servers and show you how your emails land—critical for spotting alignment issues before campaigns launch.

Lots of companies miss DKIM setup errors because they assume the DNS record is live as soon as saved. Even small mistakes—like a missing quote or a typo—can break authentication. Always verify the full record before sending. Tools like MailTester help you test live configurations across real inboxes, giving you confidence before large sends.

Salesforce SPF Include: Why You Need It with Email Relay

You need include:spf.salesforce.com in your domain’s SPF record because Salesforce Email Relay sends messages from specific, dedicated IPs. Without this inclusion, email receivers may reject your messages as unauthorized, causing delivery failures. SPF validation checks whether the sending server IP is allowed by the domain's policy, and Salesforce’s IPs must be explicitly authorized.

How SPF Works with Salesforce Email Relay

When you send email via Salesforce Email Relay, the messages originate from Salesforce’s infrastructure, not your own servers. Email receivers use SPF to verify that the sending IP is listed in your domain’s SPF record. If Salesforce’s IP isn’t included, the send fails SPF checks, often resulting in bounces or messages landing in spam.

SPF is defined in RFC 7208, which outlines how domains authorize sending IPs. A properly configured SPF record ensures only approved sources can send on your behalf. Without inclusion of Salesforce’s SPF, your messages are treated as suspicious, even if they’re legitimate.

Adding the Include Directive Correctly

Add include:spf.salesforce.com to your existing SPF record. The full record might look like: v=spf1 include:spf.salesforce.com -all. This tells receivers that Salesforce is authorized to send on your domain’s behalf.

But if you already use multiple third-party services (like SendGrid, HubSpot, or Mailchimp), you must keep the total number of include mechanisms under 10. Exceeding this limit can break SPF alignment, leading to failed validation. Use tools like MxToolbox to check your SPF record’s structure and avoid common errors.

Let’s say you use five email services. Including Salesforce may push you to nine includes — leave space for one more. If you’re close, consider consolidating services or switching to a unified sender like Salesforce or a third-party with a single include.

For a real-time check of your domain’s SPF configuration, use MailTester’s integration tools to validate sender authentication across multiple platforms, including SPF, DKIM, and DMARC.

Best Practices for Salesforce Email Deliverability Settings

You improve deliverability by using a dedicated sending domain, warming it up gradually, keeping bounce rates below 3%, sticking to one consistent from address, and testing inbox placement with real tools before big sends. These steps reduce blacklisting risks and increase inbox placement.

Domain & Sending Configuration

• Use a dedicated sending domain like mail.yourcompany.com instead of your primary domain. This isolates email traffic and protects your main domain’s reputation.
• Warm up your domain over 7–10 days with a 20% daily volume increase. Start at 100–200 emails on day one to signal legitimacy to ISPs.
• Set up and verify DKIM for every sending domain. Salesforce Email Relay requires it. A well-configured DKIM aligns with RFC 6376, the industry standard for email authentication.
• Use consistent from addresses across campaigns. Mixing senders (like [email protected] and [email protected]) on the same domain confuses spam filters and harms sender reputation.

Monitoring & Testing

• Monitor bounce rates closely. A rate above 3% signals list hygiene issues—likely old or invalid emails. Clean your lists before sending.
• Test inbox placement using a real delivery tool. Don’t rely on Salesforce’s built-in logs alone. Tools like MailTester’s Inbox Placement Tester simulate real-world delivery and detect filters.
• Verify your email list before sending. Use MailTester’s Bulk List Verification to detect invalid, catch-all, or disposable addresses upfront.
• Integrate verification into your workflow. Use the MailTester API to check addresses in real time during sign-up or CRM sync.

Consistent sending patterns and authentication are the foundation of deliverability—not luck, not hacks.

How to Test if Your Salesforce Email Relay DKIM Is Working

You can verify your Salesforce Email Relay DKIM setup by sending a test email to a Gmail or Outlook inbox, then checking the raw headers for DMARC, SPF, and DKIM validation results. If DKIM shows a pass, alignment is correct. If it fails or is missing, double-check your DNS TXT record. Use tools like MXToolbox or Mail-Tester to analyze the headers and confirm alignment between the From domain, SPF, and DKIM. DMARC requires either SPF or DKIM to pass; if DKIM fails, the issue is likely in the TXT record configuration.

1. Send a test email from Salesforce to a personal Gmail or Outlook address. Use a valid Salesforce user with email relay enabled. This triggers the outbound message path with DKIM signing.
2. Retrieve the raw email headers from the recipient inbox. In Gmail, click the three-dot menu on the message and select "Show original." In Outlook, go to File > Properties > Internet headers.
3. Check for DKIM-Signature, Domain-Keys-Identified-Mark, and Authentication-Results headers. Look for "pass" under DKIM and SPF. A DMARC result of "pass" means at least one of SPF or DKIM validated successfully. If DKIM shows "fail" or "none," the signature isn’t being applied or the DNS record is misconfigured.
4. Verify domain alignment using the DKIM RFC strict alignment requirements. The domain in the From header must match the selector and domain used in the DKIM-Signature header. If the domains don’t align exactly (e.g., from: [email protected], DKIM domain: marketing.yourcompany.com), alignment fails.
5. Use third-party tools to analyze the raw headers. Paste the full header text into MXToolbox’s Email Header Analyzer or Mail-Tester for a detailed breakdown of SPF, DKIM, and DMARC. These tools highlight misconfigurations in real time.
6. Recheck your DNS TXT record if DKIM fails. Ensure the selector and domain match what Salesforce uses. The record must be published under the correct subdomain (e.g., s123456789._domainkey.yourcompany.com). Use RFC 6376 as reference for syntax.

Common Missteps to Avoid

Don’t assume DKIM is working just because the email arrives. Many emails pass delivery but fail authentication. A failed DKIM can trigger inbox filtering or rejection by receiving servers. Always validate the header results, not just the delivery status.

Use Real Tools for Real Data

Even if your DNS record is correct, issues can arise from caching delays or misconfigured Salesforce settings. Tools like Mail-Tester provide instant feedback and can simulate real mailbox behavior. If you're verifying multiple domains or large lists, consider a bulk email validation tool like MailTester’s bulk verification for ongoing inbox placement testing.

Common Pitfalls in Salesforce Email Relay Configuration

You’re likely hitting delivery issues with Salesforce Email Relay not because of the platform, but because of misconfigured DNS entries—especially DKIM and SPF. The most common cause? A missing or incorrect DKIM TXT record. Even a single typo in the signature breaks authentication. Let’s walk through the top mistakes that silently sabotage your deliverability.

DKIM and SPF: The Twin Gates to Inbox Placement

DKIM is your email’s digital signature. If the TXT record isn’t published exactly as Salesforce provides it—including the correct selector, domain, and key value—it fails validation. Major providers like Gmail and Outlook reject messages without a valid DKIM signature, often returning silent failures. The record must be in the correct DNS zone, typically under the sending domain, not a subdomain like mail.yourcompany.com.

SPF is equally sensitive. Having multiple SPF records causes immediate failure—only one SPF record per domain is allowed. Even if one record is correct, conflicting versions result in a failure during email validation. Also, if your SPF record doesn’t include include:salesforce.com or include:spf.protection.outlook.com (depending on your outbound provider), your domain will be rejected by major email providers. It’s not just about having an SPF record—it’s about having one that correctly lists your sending sources.

Domain Trust and Authentication Readiness

Trying to enable Salesforce Email Relay without verifying your sending domain first? That’s a ticket to blocklists. Providers like AWS SES, Microsoft 365, and Gmail require domain registration and authentication before accepting outbound emails. Skipping this step means your domain is treated as unverified—even if your DNS records look perfect. It’s better to start small, test, and scale than to send at scale with weak authentication.

Some teams also mistakenly add DKIM records to the wrong DNS zone—like putting the TXT record under a subdomain instead of the root domain. This breaks the alignment required by DMARC. The signature must match the domain in the From header. Using the wrong key type or placing the record in a non-public DNS zone (e.g., internal DNS) makes it invisible to verifying servers. Always test your DNS records with tools like MXToolbox before sending.

You can catch many of these issues early with a pre-send verification tool. For example, MailTester’s bulk email verification can flag invalid sender domains, detect catch-all addresses, and uncover DNS issues before they impact delivery. It’s not about preventing every bounce—it’s about catching the preventable ones early.

Why You Should Verify Your Contact List Before Relaying

Even with flawless DKIM and SPF, sending to invalid, catch-all, or role-based email addresses still harms deliverability. These addresses generate bounces, trigger spam traps, and hurt your sender reputation—no matter how well your authentication is set up. Verifying your list first stops this damage before it starts.

Authentication Isn’t a Shield Against Bad Data

DKIM and SPF protect against spoofing and ensure your messages are accepted by receiving servers. But they do nothing to stop you from sending to addresses that don’t exist, are role-based (like admin@ or sales@), or are disposable. Sending to these addresses often results in hard bounces or silent failures, which degrade your reputation over time.

According to Return Path’s research, high bounce rates—especially from invalid or role-based addresses—are a strong signal to email providers that your sender is untrustworthy. This is true regardless of whether your alignment with SPF, DKIM, or DMARC is perfect.

MailTester Cleans Lists Before You Send

MailTester’s bulk email verification checks every address in your Salesforce list for validity, risk level, and domain reputation before you relay. It identifies invalid, disposable, catch-all, and role-based addresses with 98.9% accuracy. This means fewer bounces, fewer spam complaints, and better inbox placement.

You can run this directly on your Salesforce data using the MailTester integration. The process is simple: import your list, verify it in bulk, and push the cleaned version back to Salesforce—no extra tools, no workflow disruption. See how it works with Salesforce and other platforms.

It’s not enough to authenticate if your list is filled with dead ends. Every bounce or soft fail, even if it never reaches the inbox, counts against you. MailTester removes the noise so your deliverability is based on real engagement—not technical compliance alone.

Let’s be clear: list hygiene isn’t optional. It’s a core part of responsible email marketing. With real-time verification at your side, you’re not just protecting your reputation—you’re making every sent email count.

Salesforce DKIM: Verifying Domain Alignment and Authentication

DKIM alignment fails when the domain signing the email doesn’t match the From address. If you send from [email protected] but sign with app.salesforce.com, the authentication fails. To pass, your DKIM signature must use your public domain (e.g. yourcompany.com) as the signing domain. This is why Email Relay requires a custom domain and correct key configuration. Always check email headers after sending to confirm both SPF and DKIM alignment.

Why DKIM Alignment Matters for Salesforce Email Relay

Let’s say you’re using Salesforce Email Relay to send transactional emails. You want those emails to land in inboxes, not spam folders. One of the core requirements is domain alignment: the domain used in the DKIM signature must match the domain in the email’s From header. If it doesn’t, even if your SPF is correct, your messages may be flagged as suspicious.

For example, if your From domain is [email protected] but your DKIM signature uses app.salesforce.com, the alignment check fails. This breaks trust with receiving mail servers. Most modern email providers — including Gmail and Microsoft 365 — check for alignment and penalize mismatched signatures.

That’s why Email Relay lets you specify a custom domain. You can configure DKIM keys under your own domain (e.g. yourcompany.com) so the signature domain matches your From address. This ensures alignment and improves deliverability. You don’t need to rely on Salesforce’s default signing domain.

How to Verify Alignment in Practice

Alignment can’t be trusted in theory alone — it must be tested. After sending a test email, examine the raw header. You’ll see the From: field, the DKIM-Signature: header, and the Authentication-Results: field. Look for entries like dkim=pass (signature verified) and check that the signing domain (d=) matches your From domain.

Tools like MxToolbox or the RFC 6376 specification provide the technical standard for DKIM validation. The full specification is available at RFC 6376, which details how domain alignment is enforced through the d= tag in DKIM signatures.

Even with strong technical setup, misconfigurations happen. Use inbox placement testing before sending bulk campaigns. Tools like MailTester’s inbox placement tester let you send a message to real inbox providers and analyze how it lands. You can catch alignment issues before they hurt your sender reputation.

For teams with large email lists, regular verification is essential. Use the bulk verification tool to clean your list and remove invalid addresses before sending. A clean list reduces bounce rates and keeps your domain healthy. Combined with proper DKIM and SPF setup, this leads to consistent inbox placement.

Final Checklist: Are You Ready to Launch with Salesforce Relay?

Verifying each step ensures your emails reach inboxes reliably. Skipping any of these reduces deliverability, even with a correct Salesforce Relay setup.

• ✅ DKIM TXT record added to your DNS with the correct key – The key must match exactly what Salesforce provides. Any mismatch breaks authentication.
• ✅ SPF record includes include:spf.salesforce.com and stays under 10 records – Exceeding the 10-record limit invalidates SPF. Combine records where needed.
• ✅ From email address matches the authenticated domain – Using a different domain from the one in SPF/DKIM causes failure.
• ✅ No disposable, role-based, or catch-all addresses in your list – These harm sender reputation and increase bounce rates.
• ✅ Sender reputation is clean (no prior blocks or spam traps) – Check your IP and domain history using tools like MxToolbox or Spamhaus.
• ✅ Inbox placement tested with real-time delivery tools – Validate in Gmail, Outlook, and Apple Mail before sending live.

Completing this checklist aligns your infrastructure with inbox provider expectations. The result is consistent delivery and lower risk of spam filtering.

Sources

• The number of top domains at DMARC enforcement grew from 233,249 in 2023 to 411,935 in 2026 — a 77% increase driven largely by mailbox-provider sender mandates. — EasyDMARC 2026 DMARC Adoption & Enforcement Report (2026)
• Since May 5, 2025, Microsoft Outlook requires SPF, DKIM, and DMARC from domains sending 5,000+ emails per day, rejecting non-compliant mail outright at the SMTP level with error 550 5.7.515. — Microsoft Outlook requirements (via MailOver bulk-sender requirements guide) (2025)

Keep reading

• Email authentication: SPF, DKIM, DMARC, BIMI and MTA-STS (complete guide)
• Resolving Reverse Proxy IP Conflicts and SPF Record Validation Failures
• Why BIMI Records Fail with Self-Asserted Implementation
• How to Detect Domain Spoofing Using DMARC Policy Enforcement
• DNS Configuration for CNAME-Based DKIM Delegation in 2026

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Does Salesforce Email Relay require DKIM?

Yes. Without DKIM, most email providers reject messages due to lack of authentication. DKIM is mandatory for reliable deliverability.

Can I use a different domain for Salesforce Email Relay?

Yes. You can set up a subdomain (e.g. mail.yourcompany.com) specifically for Salesforce Relay to isolate sending and improve tracking.

How long does it take for Salesforce DKIM to activate?

After DNS propagation is complete (typically 1–6 hours), messages sent via Email Relay will be validated and deliver correctly.

What happens if my SPF record is too long?

SPF failure occurs. Limit includes to one or two trusted services and use the SPF aggregate method if needed.

Why does my email show as 'failed' in MailTester?

Failures often stem from invalid, catch-all, or disposable addresses. Run a list cleanse first using tools like MailTester.

Does MailTester work with Salesforce?

Yes. MailTester supports bulk verification and real-time API checks that integrate with Salesforce workflows to verify email lists.

How accurate is MailTester’s verification?

It achieves 98.9% accuracy. It identifies valid, invalid, catch-all, and risky addresses with minimal false positives.

Can I use MailTester to test inbox placement?

Yes. MailTester offers inbox-placement testing that shows whether emails land in the primary inbox or spam folder across major providers.

What is a catch-all email address?

A catch-all accepts any email sent to a non-existent address on the domain, making it risky for outreach and prone to spam detection.

Do disposable email domains affect deliverability?

Yes. Emails to disposable domains lead to higher bounce rates and lower sender reputation. Always filter them out.