How DKIM records reduce email spoofing, phishing and spam

The email security problem

All internet email is transmitted from an originating email server to the destination email server using Simple Mail Transfer Protocol (SMTP). When SMTP was specified in 1982 in RFC 821, it provided no security features. The objective of the protocol was to specify a means for exchanging messages. Security through encryption or cryptographic authentication was left for other protocols. For example, the earliest email implementations transmitted unencrypted plaintext messages, but mail encryption and data integrity services are now provided at the transport layer using the TLS protocol.

Encrypting SMTP data over TLS provides assurance that messages are not accessible to attackers in transit, but it provides no assurance that those messages originated from the apparent source. Individual messages may be digitally signed and encrypted by the sender, using protocols such as Secure/Multipurpose Internet Mail Extensions (S/MIME) or Pretty Good Privacy (PGP), but these protocols only authenticate the sender and say nothing about whether the messages have been sent by a mail server authorized for the sending domain.

A further complication -- and part of the reason security is kept separate from mail delivery -- is that email security should not negatively affect email delivery. While protecting against email forgery is important, it should be implemented in a way that doesn't degrade delivery of legitimate messages.

What are the threats from unauthenticated email?

Without email validation or authentication, all incoming email is treated as legitimate. This enables the following types of attack:

• Spam is when spammers send unwanted email to promote an otherwise legitimate product, but more often, spam is used to promote scams, gather information or attack the email infrastructure of the targeted organization to disrupt email services.
• Spoofing is a technique email hackers use to convince recipients they are communicating with a legitimate sender. Business email compromise and whaling attacks often depend on spoofed email.
• Phishing is a technique that uses email to manipulate recipients into taking action that furthers the attacker's goals. Phishing attacks may prompt victims to open malicious software or authorize improper payments, for example.

When used together, DKIM, SPF and DMARC enable email senders and recipients to significantly reduce the threats carried by spoofed or otherwise illegitimate email. DKIM works best when email servers can authenticate the digital signatures on individual emails using the email sender's public DKIM key.

What is DKIM?

The DKIM protocol, defined in Internet Engineering Task Force RFC 6376, DomainKeys Identified Mail (DKIM) Signatures. When DKIM is implemented, a domain-owning entity can claim responsibility for that domain by signing all outgoing messages with a public key associated with the domain. DKIM signatures are incorporated into the message headers of authenticated email; they are not under the control of the person sending the mail.

DKIM signatures are separate from other types of message-signing protocols, such as PGP or S/MIME. Those protocols enable users to sign or encrypt individual messages, but when DKIM is in use, all messages -- including those signed or encrypted individually by the senders -- can be authenticated as coming from an authorized mail server.

In cases where a user signs email with PGP or S/MIME, those signed messages are themselves digitally signed using the DKIM public key. This gives the receiving mail server a mechanism to authenticate the message as being sent from an authorized domain, subdomain or IP address with DKIM, while also giving the person receiving the email a way to authenticate the contents of the message as originating from the person who sent it.

DKIM, SPF and DMARC work together to provide the most important method for protecting email users from spam, spoofing and phishing. When used together, email-sending organizations have the means to do the following:

• include a digital signature in the header of outgoing messages, using DKIM records;
• identify authorized mail servers for a domain, subdomain or hostname, using SPF records; and
• notify receiving mail servers how to process email from a domain or hostname when it is received from an unauthorized server or when the digital signature fails to authenticate, using DMARC.

All three of these protocols use DNS TXT records to store information about the email servers that serve a domain (SPF), how email from those servers can be authenticated (DKIM), and what to do when email is received from unauthorized servers or when messages fail to authenticate (DMARC).

Setting up a DNS record for email authentication using any of these protocols is usually done by domain administrators. Email receivers can do a DKIM check on inbound email to authenticate messages using the sending domain's public key. The DKIM check is done using a DNS lookup, which verifies a DKIM record exists for the domain and then validates the email by checking the message's digital signature.

How does DKIM protect against spam and phishing?

When used with DMARC and SPF, DKIM enables email-receiving organizations to reduce or prevent spoofing, phishing and spam by resolving the following questions:

• How can individual email messages be authenticated? DKIM records provide a public key, which gives email-receiving organizations a way to authenticate individual email messages.
• Who is authorized to send email for a domain? SPF records identify the domain names and IP addresses of email servers authorized to send mail for the associated domain.
• What should be done when email is sent from an unauthorized domain? DMARC records specify what to do with an email message sent from an unauthorized email server based on the SPF record for the domain.

When an email-sending organization publishes its public key in its DKIM record, it offers email-receiving organizations a method for flagging email without a DKIM signature or with a DKIM signature that fails to properly authenticate.

DKIM, SPF and DMARC all depend on DNS to publish and distribute authentication information for the sending domain, so it is important to understand how DNS TXT records are created and added. In most cases, adding a DNS TXT record for these protocols should only be done by someone with authority for the sending domain's DNS records.

DKIM works when an email server receives messages from an email sender. If the receiving email server supports DKIM, it queries DNS for the domain specified in the return-path address in the message header. If a DKIM record exists for the domain the mail is being sent from, that record includes the public key needed to authenticate the incoming message.

How to implement DKIM

Smaller organizations and individuals that use email service providers to send and receive email can check with their providers to be sure their email servers implement DKIM. Most large email service providers use DKIM, SPF and DMARC to restrict email forgeries, email spoofing and other malicious or unwanted email.

Implementing DKIM is usually just one aspect of a larger effort to authenticate email. While DKIM can be used by itself, it is much more effective to deploy DKIM records along with SPF and DMARC records. This enables an organization to specify authorized emails with SPF and directives for proper handling of unauthenticated emails with DMARC.

Organizations that want to protect their domains using DKIM, SPF and DMARC usually roll out their email authentication efforts gradually and in concert. The domain owner must take the following steps:

1. Publish DNS TXT records for each protocol under the email sending domain.
2. Configure email servers for the domain to support each protocol and take appropriate action when email is authenticated or fails to be authenticated.

Gradual implementation usually means taking the following steps:

1. Publish a DMARC record that specifies no action or only a request for reporting on messages that are received and go through the authentication process. This enables the domain holder to determine whether the DMARC instructions are valid and applicable only to messages that fail to authenticate.
2. Publish DKIM and SPF records for the domain with the neutral DMARC record. During the email authentication rollout, this enables the domain administrator to determine that the records are properly applied and will be effective for reducing forged email.
3. Update DKIM, SPF and DMARC records to apply rules for restricting potentially harmful email and discarding unauthenticated messages.
4. Review rollout processes, and verify that implementation has been effective at reducing unauthorized or unauthenticated email, while not affecting email deliverability.

DKIM authentication is most effective when it is deployed in conjunction with DMARC, which establishes the domain owner's policies for handling unauthenticated email sent from the domain. If DMARC is not implemented, organizations that receive unauthenticated email don't have a clear path to report those messages, but they may still have their own policies for rejecting or accepting unauthenticated mail.

DKIM selectors

While a single domain may only have one SPF record posted in DNS, domain owners must use different public key pairs for different email servers operating on behalf of the same domain. Different public keys for different servers are identified by a DKIM selector, a string added to the name of the DKIM DNS record that differentiates between multiple authorized email servers and their public signing keys.

All DKIM DNS records are named using this format:

selector_name._domainkey.example.com

DKIM selectors are useful for large organizations that have operations in multiple locations and send email from each location. A selector may also be used for email sent on behalf of the domain owner, such as email campaigns run by a third-party provider or for email sent by an email service provider. The following are examples of such selectors:

kolkata._domainkey.example.com
mumbai._domainkey.example.com
gmail._domainkey.example.com

In the above example, an organization based in India specifies separate DKIM signing keys published for mail sent from a Kolkata mail server, from a Mumbai mail server and from Google's Gmail email service.

DKIM signature headers

When DKIM is in use, all email sent by an email server in the sender's domain is digitally signed. The DKIM signature is then incorporated into the header of the signed email. The DKIM signature consists of tags, which are informational elements that carry relevant information about the digital signature on the email, as well as information related to sender's email server. These tags include the following:

• Version refers to the version of DKIM implemented by the sender. Currently, the only valid value for version is 1 for DKIM version 1.
• Signing domain identifier (SDID) is the originating domain name claimed in the originating email header. This value identifies the entity claiming to own the domain and is used along with the DKIM selector value to determine the name of the DNS TXT record containing the domain's signing key.
• DKIM selector is a string appended to the originating domain to identify the DNS record associated with a particular email server or service. See DKIM Selectors section above for more information.
• Header fields is a list of the header fields included in the hash of the message. The tag h= is followed by the exact field names separated by the string " : " (<space><colon><space>), with the semicolon character ";" terminating the list.
• Email body hash (bh) is the cryptographic hash of the selected header fields and the body of the message. This is the value that should be produced by the recipient when an inbound message is processed by the receiving DKIM implementation.
• Algorithm is the digital hashing algorithm used to generate the digital signature in the DKIM header. Support for the RSA SHA-256 algorithm is required for all DKIM implementations and was initially recommended to be used for most purposes. The RSA-SHA1 algorithm is also supported. A new signing algorithm, Ed25519-SHA256, was specified for use with DKIM signatures in RFC 8463.
• Digital signature is the actual digital signature generated by the sender. This signature is generated by hashing the selected header fields and the body of the message and then digitally signing that hash.

Here is an example of a DKIM signature header, including the first string, DKIM-Signature, which is required for these headers:

DKIM-Signature: v=1; a=rsa-sha256; s=mumbai;
d=example.com; q=dns/txt;
h=Received : From : To : Subject : Date : Message-ID;
bh=Nr9BrIAPreKQj2jUSOH9NhtVGCQWJVOzv8O6Sn7XIkf=;
b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHutKVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV4bmp/YzhwvcubU4=;

The tags used in this example are explained in the table below.

When an email server that supports DKIM receives a DKIM signed message, it does a DKIM query to acquire the public key associated with the message signature and then attempts to authenticate the message.

DKIM records

Sending DKIM-authenticated email requires a DKIM record in a DNS TXT record. Adding DNS records is usually restricted to one or a small group of authorized staff members and should not be done lightly because of the potential for negative impact on an organization's internet accessibility.

The first step when creating a DKIM record is the record name. The simplest DKIM record looks something like the following:

_domainkey.mail.example.net

The record is identifiable as a DKIM record because of the _domainkey prefix followed by a period. In this case, all DKIM email would be authenticated against the public key published in the record, and there would only be one email server for that domain.

In cases where multiple email servers are in use, email administrators have to choose between copying the private (secret) key to all servers or creating different public key pairs for use on different email servers. The latter choice is preferable for security reasons, as it restricts the distribution of an extremely sensitive private key.

DKIM selectors enable email administrators to publish different DKIM records that are differentiated by the DKIM selector name. Continuing from the example listed above of an organization with email servers in both Mumbai and Kolkata, India, two DKIM records are created using the DKIM record names:

mumbai._domainkey.mail.example.net
kolkata._domainkey.mail.example.net

A simple DKIM record looks similar to this:

v=DKIM1; t=y;
p=MIGCSQUAA4GNADCBiQKBgQDcS0KlQNqr9KpF0W12OLpolAG5QfEMrVRjhjwVRkRHd/hqGSIb3DQEBAGfMA0TfcOflHRsGPLoTusFDxGHKIXjlR9/srlkG/+cX5mIxDV/t/1pRNm1Z47sg2GKok6KZth0YcXRfh8d4lawDRdberkBPebVji65HvnrFLD+YCTUhAPv3znlsfee+/Z9kQIDAQAB

Only two options are mandatory: the version of DKIM being supported and the public key being used by the server sending email on behalf of the domain specified in the DKIM record name.

The optional testing parameter, t=, has two valid values, n and y, which specify whether the DKIM record is being tested (t=y;) or is in production (t=n;).