DKIM Signing Outbound Email

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 organization.
Available in: Enterprise, Unlimited, and Developer Editions

User Permissions Needed
To Manage DKIM Key Customize Application

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.

The EmailDomainKey object consists of these fields.
  • DomainThe organization’s domain name that the DKIM key is generated for.
  • DomainMatchThe specificity of match required on the sending domain name before signing with this DKIM key. Valid values are:
    • DomainOnly
    • SubdomainsOnly
    • DomainAndSubdomains
  • IsActiveIndicates whether this DKIM key is active (true) or not (false).
  • PrivateKeyThe 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 another EmailDomainKey object.
    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.
  • PublicKeyPart 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.
  • SelectorText 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:
  1. Insert the Domain, DomainMatch, and Selector.
  2. Update your domain’s DNS records.
    1. Locate the DNS record at selector._domainkey.domain. For example,
    2. Add the PublicKey value, like this: V=DKIM1; p=public_key.
    DKIM Signing Outbound Email
    1. 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.
  3. 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 subdomain level.
  • 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 domain, and you then set DomainMatch to SubdomainsOnly for the 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 DomainAndSubdomains key to become SubdomainsOnly. In case of a tie, the most specific key is used.