Use DKIM in addition to SPF to help prevent spoofers from sending messages that look like they are coming from your domain.
DKIM lets you add a digital signature to email messages in the message header.
When you configure DKIM, you authorize your domain to associate, or sign, its name to an email message by using cryptographic authentication.
Email systems that receive email from your domain can use this digital signature to help determine if incoming email that they receive is legitimate.
The sending email service adds a DKIM signature to outbound email. The receiving email service uses the public key to check the DKIM signature matches.
If it does, it forwards the email to the receiver’s inbox. If it does not match, the receiving email service fails or rejects the invalid email.
You have to create a new DKIM TXT record with your domain, the selector and your public key: <selector(s=)._domainKey.domain(d=)>. TXT v=DKIM1 ; k=rsa ; p=<public key>
The mail header will thus looks as follow (for instance):
Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.europa.eu; s=maple; t=1582617907; bh=OlHvsp/RvV59stiQtr1pcYwioCXmPGBwSzHj2iNmxO0=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:From: To:CC:Message-ID:Date; b=dTvC/XbYiCBV7HV+wT8o/ESBiM7bGIXHdIXzvxb4YzSCAKHqgO6m4aEXe3Ot+y4It 6dNOYXIzLDSoM8dZi7n0UyXbLAxx6RO4qM5oBFFt6jJNbjTUm/6auVKMqeKNCOuG35 VjkiVlusNqcAiIEe/NhpLmHxrO/w8BI97g4ow7dbINZwocFrvKa4rjKLhhz7sUWH61 fdnx9R4fKhOLcynvdns8h3eLz0MnCZ4+CoQVyr9xMlLEceC59LDpyP0zB6v2XCJij4 Lj/IH1wJNnxmECM5wcl7gd0bvfSdHf9NsNvDksKy9t7RLb2i7KI+xcjWHdVtht9WKV rLdGkoArvVfJg==
Below are the required tags of a DKIM signature header. Any DKIM signatures missing these tags will encounter an error during the verification process.
v= indicates the version of the signature specification. The value should always be set to 1.
a= indicates the algorithm used to generate the signature. The value should be rsa-sha256. Senders with reduced CPU capabilities may use rsa-sha1. However, using rsa-sha1 is discouraged due to potential security risks.
s= indicates the selector record name used with the domain to locate the public key in DNS. The value is a name or number created by the sender.
b= is the hash data of the headers listed in the h= tag; this hash is also called the DKIM signature and encoded in Base64.
bh= is the computed hash of the message body. The value is a string of characters representing the hash determined by the hash algorithm.
d= indicates the domain used with the selector record (s=) to locate the public key. The value is a domain name owned by the sender.
h= is a list of headers that will be used in the signing algorithm to create the hash found in the b= tag. The order of the headers in the h= tag is the order in which they were presented during DKIM signing, and therefore is also the order in which they should be presented during verification. The value is a list of header fields that won’t change or be removed.
Optional and recommended tags
Below are the optional tags that we recommend you include in a DKIM signature header. DKIM signatures missing these tags will not encounter an error during verification, but they are recommended as a means to help identify spam.
Spammers don’t normally set time values. Empty or incorrect time values, such as an expiration time dated before the email timestamp, will cause some mailbox providers to reject the message.
t= is the DKIM signature timestamp. It is meant to indicate the time that message is sent. The format is the number of seconds from 00:00:00 on January 1, 1970 in the UTC time zone.
x= is the DKIM signature expiration time in the same format as above. The value of the this tag must be greater than the value of the timestamp tag if both are used in the DKIM signature. DKIM signatures may be considered invalid if the verification time at the verifier is past the expiration date, so be sure not to set the expiration date too soon.
Complete testing to make sure these tags are working properly and that the expiration time is not set too soon after deployment.
Below are the optional tags that are not required in the DKIM signature.
c= is the canonicalization algorithm that defines to a mailbox provider what level of modifications may be present as the email is in transit to the mailbox provider. Modifications can include whitespace or line wrapping. Some email servers make minor modifications to the email during transit which can invalidate the signature.
Here is the value that defines what level of tolerance the destination server should have when a message has these minor modifications: value1/value2.
Value1 represents the header of the message and value2 represents the body of the message. Value1 and value2 can be labeled as “simple”, which tolerates very little, if any, modification, or “relaxed” which tolerates common modifications.
i= indicates the identity of the user or agent. The value is an email address containing the domain or subdomain as defined in the d= tag.
Optional and not recommended tags
l= is the number of characters from the message body that were used to compute the body hash (bh=). If this value isn’t there, then it’s assumed the whole message body was used. We don’t recommend you use this tag because it can be difficult to control and may lead to verification errors.
z= is a list of the message’s original headers and may differ from the headers listed in the h= tag. This tag may be used by some mailbox providers in the process of diagnosing a verification error. Its value is not well defined.
Any tags not specified in RFC 6376 are not part of the DKIM protocol and should be ignored during the verification process. Not all mailbox providers ignore unrecognized tags, so you might see an error during the verification process.