Use the DomainKeys Identified Mail (DKIM) key feature to enable Salesforce to sign outbound emails sent on
your organization’s behalf. A valid signature provides recipients confidence that the email was
handled by a third party such as Salesforce in a way authorized by your
|Available in: Enterprise, Unlimited, and Developer
|To Manage DKIM Key
When you create a DKIM key, Salesforce generates a public and
private key pair. You must publish the public key in the DNS, which tells recipients that
you, as the owner of the domain, have authorized the use of this key to sign your mail.
Salesforce uses the private
key to create DKIM signature headers on your outgoing email. Then, recipients of the mail,
can compare the signature header with the public key in the DNS to determine that the mail
was signed with an authorized key. If your domain also publishes a Domain-based Message
Authentication, Reporting and Conformance (DMARC) policy, recipients can use the DKIM
signature to verify that the mail conforms to DMARC.
object consists of these fields.
Domain—The organization’s domain name that the DKIM key is generated
DomainMatch—The specificity of match required on the sending domain name before
signing with this DKIM key. Valid values are:
IsActive—Indicates whether this DKIM key is active (true) or not (false).
PrivateKey—The private portion of the DKIM key pair used to encrypt mail headers
from your domain. Salesforce generates
an encrypted PrivateKey if you
don’t specify a value when creating the DKIM key. If you do specify
a value, it must be an existing valid PrivateKey from
This field doesn’t contain the actual private key, but a value that represents the
key in our system. Therefore:
- The actual private key can’t be leaked.
- You can’t use the value to do your own email signing.
PublicKey—Part of the domain key pair that mail recipients retrieve to decrypt
the DKIM header and verify your domain. Add the PublicKey value to
your domain’s DNS records before you start signing with this domain
key. Otherwise, mail recipients may reject your email.
Selector—Text used to distinguish the DKIM key from any other DKIM keys your
organization uses for the specified domain.
For each domain key you create, we recommend this sequence:
- Insert the Domain,
- Update your domain’s DNS records.
DKIM Signing Outbound Email
- Locate the DNS record at selector._domainkey.domain. For
- Add the PublicKey
value, like this: V=DKIM1;
- In addition, you can optionally put the record in testing mode, which instructs
recipients to not make decisions based on the email signature. Add parameter t=y to the DNS entry, like this: V=DKIM1; t=y; p=public_key.
- Update the key via the API or UI to be active.
Consider the following
when using domain keys.
- Make sure you add the public key to your DNS record before you make your key active in Salesforce and start DKIM
signing. DKIM signing is active whenever your DKIM key is in the active state.
- You can’t have more than one active DKIM key per domain name. You might have multiple
active DKIM keys if your organization mails from more than a single domain or if you use
subdomains under your organizational domain and have specified domain matching at the
- If you want to use the same DKIM key for multiple organizations, you can. Create the key and
ensure it’s working for one organization first. Then using the API or UI create the key in
your other organizations by setting the corresponding fields in the new key to the same
values as the original.
- When you insert or update a DKIM key, it’s possible that the change affects existing
domain keys. For example, if you’ve set DomainMatch to DomainAndSubdomains for the
example.com domain, and you then set DomainMatch to SubdomainsOnly for the
mail.example.com domain, either key could be used. Here’s how we resolve
conflicts in the case when DKIM keys overlap.
- If two keys are equally specific about matching for the same domain, the new key
replaces and deactivates the existing key.
- If a new key is more specific about matching than an existing key, the new key is
used and the existing key is modified to inactive.
- If multiple keys have different domains that match the sending domain, the key
with the longest domain name is used. In case of a tie, the most specific key is
used. For example, because DomainOnly and SubdomainsOnly are more
specific than DomainAndSubdomains, a
new DomainOnly key
would change the DomainMatch for an existing
to become SubdomainsOnly. In case
of a tie, the most specific key is used.