Decoding Salesforce DKIM Failures: From CNAME to Public Key

You see the alert: DMARC aggregate reports show a spike in DKIM failures. The source IP belongs to Salesforce. Your SPF is passing, but DomainKeys Identified Mail is a sea of red 'fail' verdicts. Your first instinct is to check the Salesforce Trust page or open a ticket. But the problem is almost never there.

The real culprit is usually closer to home, hidden in the delicate chain of DNS records that connects your domain to Salesforce's signing infrastructure. Salesforce's use of CNAME delegation for DKIM is a smart, scalable solution for them, but it introduces an extra layer of abstraction—and an extra point of failure—that trips up even experienced admins.

This isn't just an academic exercise in RFC compliance. A broken DKIM setup means your legitimate marketing and transactional emails look suspicious to receiving mail servers. Deliverability plummets. Your domain becomes easier to spoof for BEC attacks. And you start fighting a two-front war: one against deliverability issues and another against your own security stack flagging legitimate outbound mail.

Why Salesforce Uses CNAMEs (And Why It Breaks)

Let's be clear: CNAMEs are the only sane way for a SaaS provider like Salesforce to manage DKIM at scale. They manage keys for tens of thousands of customer domains. Can you imagine the operational nightmare if every customer had to be manually notified to update a TXT record in their DNS every time Salesforce rotated a public key? It would be chaos.

So, they delegate. Instead of giving you a public key to publish in a TXT record, they give you two CNAME records. Something like this:

The Delegation Chain

Your DNS record, `sfdc1._domainkey.yourdomain.com`, doesn't contain the key. It's an alias, a pointer. It points to a hostname that Salesforce controls, for example, `sfdc1._domainkey.yourdomain.com.dkim.salesforce.com`. The receiving mail server, when performing a DKIM check, first resolves your selector. It sees the CNAME, then follows it to the Salesforce-controlled hostname to retrieve the actual TXT record containing the public key.

This pattern isn't explicitly defined in RFC 6376, which specifies the DKIM standard, but it's a perfectly valid and widely used DNS mechanism. The operational stake, however, is massive. You've introduced an indirection. If your CNAME pointer is off by a single character, the entire lookup fails. The receiving server never even reaches Salesforce's DNS to find the key. To the verifier, it's as if the key doesn't exist.

The First Point of Failure: Your Own DNS Zone File

Before you blame esoteric cryptographic issues, start with the basics. The overwhelming majority of Salesforce DKIM failures originate from simple mistakes in your own DNS zone. These are the copy-paste errors and configuration typos that happen under pressure.

Typographical Errors and Selector Mismatches

Salesforce provides two selectors, typically `sfdc1` and `sfdc2`. This allows for zero-downtime key rotation. But it also doubles your chances of a typo. Did you create a record for `sfdc1._domainkey` but accidentally paste the CNAME target for `sfdc2`? Or did you create the CNAME for `yourdomain.com` when the mail is actually being sent from `marketing.yourdomain.com`? The `_domainkey` portion must be appended to the correct sending domain.

Another classic is the trailing dot on the CNAME target. The value you paste, like `sfdc1._domainkey.yourdomain.com.dkim.salesforce.com.`, should have a trailing dot to signify it as a Fully Qualified Domain Name (FQDN). Some DNS providers add this automatically; others don't. If you omit it, your provider might append your own domain to the end, resulting in a lookup for `sfdc1....salesforce.com.yourdomain.com`—a record that will never resolve.

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51921
;; QUESTION SECTION:
;sfdc1._domainkey.yourdomain.com. IN CNAME — A `dig` query showing a nonexistent domain (NXDOMAIN) — the telltale sign of a typo.

TTL Troubles and Propagation Myths

You've fixed the typo, but things are still failing. Now check your Time To Live (TTL). If you set a high TTL like 86400 (24 hours) on the initial, incorrect record, DNS resolvers across the internet will cache that bad result for a full day. There's no way to force-flush their caches. This is why you always use a low TTL—300 seconds or less—when creating or changing critical DNS records. You can always increase it later once you've confirmed everything works.

Beyond the CNAME: When the Public Key Itself is Corrupt

So you've verified the CNAME chain. A query for your selector correctly resolves to the Salesforce TXT record. You're in the clear, right? Not yet. The data inside that TXT record can be another source of failure.

The public key is a long, Base64-encoded string. Some DNS providers, particularly older ones or those with clunky UIs, can mangle this data. They might incorrectly handle the quotes, split the long string into multiple quoted segments within the TXT record, or—worst of all—truncate it. While splitting a TXT record's content into multiple double-quoted strings is allowed by RFCs, some poorly implemented DNS resolvers can fail to reassemble them correctly.

Validating Key Syntax and Length

The important part of the DKIM TXT record is the `p=` tag. This is your public key data. If it's been truncated, the cryptographic verification will fail every time. A 1024-bit RSA key, which is common for Salesforce, results in a Base64 string of about 220 characters. A 2048-bit key will be closer to 400 characters. If your `p=` value is suspiciously short, your DNS provider might be cutting it off.

To confirm, you can perform a quick manual check. Use a command-line tool like `dig` to fetch the TXT record. Copy the entire string inside the `p=` tag, making sure to exclude the quotes and any spaces between them. Paste this into a Base64 decoder. If it decodes successfully into binary data, the key is likely syntactically valid. If it throws an 'invalid character' or 'invalid length' error, the key is corrupt in DNS. Because Salesforce controls the source record, this almost always means a resolver or intermediate DNS server is the problem, not Salesforce's original key.

Your Playbook: Tracing the Full Path with `dig`

Stop guessing. The `dig` (Domain Information Groper) command is your ground-truth tool for diagnosing these issues. Don't rely on web-based checkers alone; they can use cached or regional results. Run the queries yourself from a clean terminal.

Step 1: Validate Your CNAME Record

First, check that your CNAME record exists and points to the correct location. Use the `+short` flag to get a clean, simple answer.

$ dig CNAME sfdc1._domainkey.yourdomain.com +short
sfdc1._domainkey.yourdomain.com.dkim.salesforce.com. — Expected output for a correct CNAME record.

If this command returns an empty response, the record doesn't exist. If it returns something else, it's misconfigured. This is your first and most important checkpoint.

Step 2: Follow the Chain to the TXT Record

Now, ask for the TXT record directly. A wonderful feature of `dig` is that it will automatically follow the CNAME chain for you, showing the entire path. This single command validates the whole lookup process.

$ dig TXT sfdc1._domainkey.yourdomain.com

...[snip]...

;; ANSWER SECTION:
sfdc1._domainkey.yourdomain.com. 299 IN CNAME sfdc1._domainkey.yourdomain.com.dkim.salesforce.com.
sfdc1._domainkey.yourdomain.com.dkim.salesforce.com. 299 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQD..."

This output is gold. It shows your CNAME record resolving correctly, and then the subsequent TXT record being served by Salesforce's DNS. You can see the key version (`v=DKIM1`), the algorithm (`k=rsa`), and the public key data (`p=...`). If you get this far, your DNS is configured perfectly.

Postmortem: 'No DKIM Signature Found' on Outbound Mail

Here's the most maddening scenario of all. Your `dig` queries are perfect. The CNAME resolves. The TXT record is valid. Yet, your DMARC reports show failures, and header analyzers report `dkim=none`. What's happening?

The answer is often painfully simple: you've set up the public half of the key in DNS, but you never told Salesforce to actually start *using* the private half. Inside the Salesforce Setup for DKIM Keys, there's an 'Activate' button for each key. If that key isn't active for the domain you're sending from, Salesforce's MTAs will simply not attach a `DKIM-Signature` header to your outbound mail. The DNS records are irrelevant if they are never used.

Checking the Email Headers for Clues

The final arbiter is the email header itself. Send a test email from Salesforce to an external mailbox you control. View the original, raw message source. Are you looking for a `dkim=pass` verdict? No, not yet. First, you're looking for the very existence of the `DKIM-Signature` header.

If that header is missing entirely, the problem is with Salesforce's configuration—the key isn't active. If the header *is* present, examine its tags. Does the `d=` tag match your domain? Does the `s=` tag match the selector you configured (`sfdc1` or `sfdc2`)? A mismatch proves that while DKIM is active, it's configured to use a different key or selector than the one you've been debugging in DNS. This forces you back into the Salesforce UI to find the discrepancy.

The takeaway

Troubleshooting Salesforce DKIM isn't a Salesforce problem; it's a systems problem. It requires you to think like a receiving mail server, tracing a chain of trust from a DNS query all the way to a cryptographic signature. The Salesforce UI might show a green checkmark, but the proof is in the public DNS records and the headers of a delivered email.

Don't just set it and forget it. After you activate a key, send a real test email. Pull up the raw headers and find the `Authentication-Results` header. Are you seeing `dkim=pass` with the correct domain and selector? Only then is the job actually done. For ongoing verification, DMARC monitoring platforms like MailSleuth.AI can parse your aggregate reports, alerting you the moment your DKIM-signed mail starts failing so you can get ahead of any deliverability impact.