A Guide to Increasing Your Email Security and Deliverability: DKIM

Category

Guides

Risk Level

This is part two of a three part series on securing your email. You can read part one here and read part three here.

Also be sure to check out our Round Table discussion of this topic on Hive Live.

Have you ever found out that your email was being used to send spam - and when you check your “sent” folder, you don’t see any suspicious emails? Or have you ever had your legitimate emails end up in someone’s spam folder; including your marketing emails sent through third parties like Constant Contact, Mailchimp, Amazon SES, Salesforce, or SendGrid? This could be due to a simple misconfiguration that could cost you millions in lost revenue or impact your reputation. To boost your email security, we’re continuing a three part series to help you address these problems through the proper setup of your SPF, DKIM, and DMARC records.

Part 2: Creating a DKIM Record

DKIM stands for “DomainKeys Identified Mail” and “signs” your emails as a trusted email. This is similar to the physical world, using our postal mail analogy, if you were to get your letter notarized before sending it. If the recipient knows that the sender was verified, they are more likely to trust the contents of the letter. In the digital world, the recipient is the receiving email server, who can better trust emails signed with DKIM because it shows that the email is who it says it’s from, and that it hasn’t been tampered with.

There are two main differenced between SPF and DKIM. The first, is that DKIM stays in place if an email is forwarded since it is embedded into the email. Using our postal mail analogy, if someone were to put your letter inside another letter, the notarization would still be in place (DKIM), but the return address on the outermost letter would have changed (SPF). While this may not be a major consideration for you, it may impact how some of your emails sent through marketing companies are handled. The second, is that DKIM use encryption to sign the emails. This means that while you will create a new DNS record, similar to SPF, you will also have to generate “keys” for your DKIM process to work correctly. You can read more about public key cryptography here to understand more about this process.

To start, collect a list of all your domains - including ones that don’t send email. You should create a DKIM record for every domain you own. For the domains that you use to send emails (i.e. email sent from yourname@yourorganization.com), follow the steps in Step 1. And for the domains that you own, but do not use to send emails (i.e. inactive or parked domains), see Step 2.

STEP 1: FOR DOMAINS THAT SEND EMAIL

You will need to identify EVERYTHING that can send an email “as” your domain. This includes:

• Email servers - which can include web based email like Google Workspace or Microsoft 365, or in-office email servers, like Microsoft Exchange.

• Email Service Providers (ESPs) - which can include companies that provide email marketing/bulk email services that may send emails on behalf of your domain (e.g. Constant Contact, Mailchimp, Amazon SES, Salesforce, or SendGrid).

• Miscellaneous services - which can include help desk ticketing systems, HR benefits providers posing “as” you, or even e-merchant services.

BIG NOTE: A major part of DKIM is that the “private key” will need to be placed on your email server, while the “public key” will go in your DNS record. Unfortunately not every email company offers DKIM services. As a result you may not be able to implement DKIM for every one of the items you identified above. You can check out a list of companies who provide SPF and/or DKIM capabilities here.

For those services that can handle DKIM, they will often generate the DKIM record for you to use. This includes both a “selector” and the “public key” while they automatically configure and store the “private key” for you. When you have your list of DKIM information, head to your DNS provider.

Unlike SPF where there is only one record created per domain (e.g. www.hivesystems.io), you will need to add a new DKIM record for EVERY email sender that supports DKIM. So repeat this process as many times as necessary. For example, you would create one entry for your email servers on Google Workspace, and another for your marketing email sender, Salesforce. Remember, every DNS provider is different in their specific approach, but we’ll cover the general idea. For each DKIM record, you’ll create a new entry with the following values:

• For the Name, this is where you’ll put the “selector” that your email company (e.g. your email provider, ESP) gave you. Generally, it takes the following format:

  theemailcompanyname._domainkey

• For the Type, set it to “TXT” if it looks like the first example below, and “CNAME” if it looks like the second example

• For the TTL, you can leave it as the default value or set it to “1h”

• For the Data, this is where you’ll put the “public key” that your email provider gave you, in the following format:

  v=DKIM1; k=rsa; p=asdfkhkadkjhKJH789990HhjkhkjhGYT9876HQe+YcG+958eatXFZJmCxtUymm0G9ofq4F2hLQ/SUxLRiziRQJ7siAzdsm/++STvHM30528x1TNrPgoTkLk560KR4EMt7ey7DoUW6KJ9NvNybLjRpkY2H5g868Ga1U3sZxEqgyV8qBHYMmEXh2

  or maybe like this:

  yourdomain.dkim.theemailcompanyname.com.

So what do all of these parts mean?

• v=DKIM1 - This indicates that it is a DKIM record. You will always start your DKIM record with this value.

• k=rsa - This is the key type of your “public key.” This may not always be included, so follow your email company’s information they provide.

• p=asdfkhk… - This is the “public key” that matched the “private key” on the email server.

If the information your email company provided looks like the second example above, this mean that they are handling the maintenance of both the “public key” and “private key” - in which case you just need to put that information in your DNS record. Remember to set the DNS record Type to “CNAME”.

STEP 2: FOR DOMAINS THAT DON’T SEND EMAIL

If you have any domains that do not send email (i.e. inactive or parked), it is recommended to publish a locked down DKIM record to prevent it from being abused. So create a DNS entry on those domains and create a DKIM record with the same information as above except set the Data as:

• Set the Name to:

  *._domainkey

  and the Data to:

  v=DKIM1; p=

STEP 3: VALIDATE AND MONITOR

After you make the changes to your DNS, you’ll generally have to wait about 48 hours for the changes to propagate across the internet. After that time, you can check to see if your new DKIM record(s) are valid using an online tool, like this one. Remember to add DKIM records for any new email companies that you use in the future, otherwise the emails won’t be delivered!

“Is that it?”

That’s it for DKIM records, but now you have the more important part coming up! In the meantime, if you’re unsure about how to tackle DKIM records, CONTACT US TODAY and we’ll help you secure your email and your marketability today. Just ask Hitting Cancer Below the Belt:

Learn about how Hive Helps can provide pro bono cybersecurity consulting for your nonprofit at https://t.co/PfzTXTutom pic.twitter.com/6JbJbAuHa4

— Hive Systems (@hivesystems) September 29, 2020

---

Follow us - stay ahead.

---

Read more of the ACT