Domain Keys Identified Mail is an email authentication standard (along with SPF) that uses public/private key cryptography to sign email messages. It is an underpinning of DMARC, which works with SPF to prevent spammers from sending messages on behalf of your domain, in other words, exact-domain impersonation.
DKIM is used to verify that the email came from the domain that the DKIM key is associated with, and that the email had not been modified in transit. It is a stronger method of authentication than SPF because it survives most forwarding.
How DKIM works
First, the domain owner creates a cryptographic public/private key pair, and places the public key, formatted as a TXT record, in the domain’s DNS record. The DKIM header includes the domain name and a “selector” that specifies specific users, subdomains, services and the like.
Each time an email user on that domain sends a message, a Hash is generated based on the contents of the message. That hash is then encrypted along with the domain’s Private key. Then this unique Encrypted Hash gets attached to the header of the email message.
The receiving email server recomputes the Hash based on the contents of the email message. It then signs it with the Public key which is hosted in DNS.
If the Hash value that the receiving server calculates matches the encrypted Hash in the email headers, the email passes DKIM authentication. This proves that the message hasn’t been tampered with since it was originally signed. The recipient knows exactly which domain and selector it was signed by.
How do you implement the use of DKIM keys?
DKIM is usually configured by the mail administrator and enacted by the sending and receiving email servers. Generally, you can gain the DKIM key information from the sending service, eg Salesforce, or you may need to reach out to the customer support team (Eloqua by Oracle). You can then use these details and create a record for each unique sender DKIM key in your DNS. However, depending on each service some will require additional steps or verification processes (Mailchimp) before being fully implemented. For more information on setting up DKIM in particular sending services, please search our KB for that service name and review that article if one exists. Most articles are under the section titled Sender Authentication for Specific Services.
What is a DKIM selector?
A selector is a value that is used to identify something unique such as a subdomain, a specific user, an office location, or a cloud service that sends email. Selectors make it possible to support multiple public keys per domain. A single domain could have many selectors, each one for a different sender. This allows for many different services to send on behalf of the domain without all needing to share the same private key.
What characters are permitted in a DKIM selector?
The DKIM standard requires that DKIM selectors only include letters, numbers and hyphens where a hyphen can not be the first character. Dots can act as separators between labels. A few vendors have begun using underscores in the DKIM selectors they generate for their customers. While these are non compliant with the standards, many email receivers will process these correctly. Depending on how strictly the receiver follows the DKIM standard, underscores may work in some, but not all, cases.
Why does DKIM store keys in DNS?
The aim of DKIM was to simplify key management so that there is no need to rely on third-party certificate authorities. DKIM stores the public key in DNS, so domain owners can manage the public keys themselves. Using DNS allows domain owners to authorize specific senders, by placing public keys in separate selector records in DNS.
Do all senders support DKIM keys?
No, but it is supported by most senders. In addition, we commonly see senders like Zendesk add DKIM authentication as another standard of authentication besides SPF. It is always a best practice to implement DKIM to increase the deliverability rates for the sender.