How to set up your DKIM records if you are outsourcing some, or all, of your email

In my last two posts on outsourcing your email, I explained how to set up your SPF records if you are outsourcing your advertising email, and how to set up your SenderID records if you are outsourcing it.

Next up is how to set up your DomainKeys Identified Mail, or DKIM, records if you are outsourcing your email.


First of all, why DKIM? I am going to assume you have a basically familiarity with DKIM; if not, it is defined in RFC 6376 or at But to summarize it, DKIM is a way of cryptographically signing a message so that whoever receives it can verify that it both came from the sender it claims to come from, and that the message content has not been modified in transit.

[This is not exactly how DKIM works. Technically, DKIM allows the receiver to validate that the signing domain sent (or is responsible for) the message. The sender (the domain in the From: address) is frequently, but not always the sender. Second, DKIM doesn’t strictly require that the message has not been modified in transit, but only the parts of the message that
have been signed have not been modified in transit. Usually, all of the important parts have been signed and that’s what a receiver cares about, but not always.

But receivers frequently approximate it as verifying that the email really did come from the sender and it hasn’t been tampered with.]

How it works (the short version)

DKIM uses public-key encryption to sign a message from a particular domain (e.g., “from”, and this signature is (mostly) tamper-proof. Receivers can trust the signer. However, the reverse is not true; lack of a DKIM signature or failure of validation does not mean you must distrust the message.

How it works (the slightly longer version)

The below diagram is how digital signatures work:


DKIM works by including a digital signature in the message. This digital signature is a string of text that the sender signs with a private key. The receiver can take this signed piece of text, query DNS for the public key, and sign the content with that public key. The receiver then verifies that the original digital signature matches this newly signed content with the public key. If so, then DKIM verifies and the message really did come from the signing domain. If not, then you can make no assertion either way.

This is not the same as saying that the message did not come from the signing domain.

  1. It could be that a spammer is spoofing the message, or…

  2. It could be that the message was modified in transit (perhaps line wraps were folded or characters added in content conversion), or…

  3. It could be that the message came from a server where DKIM-signing was disabled, or…

  4. It could be something else. 

Advantages of signing with DKIM

Why sign with DKIM? There are a couple of reasons:

  1. DKIM has path independence

    DKIM is independent of its path. In SPF, whenever you change IP addresses, you have to update the SPF records with those new IP addresses. DKIM doesn’t care what IP addresses it came from, it only cares where the public and private keys are stored.

    This is very powerful flexibility and is easier to manage (in some ways).

  2. DKIM is a much stronger statement about identity than SPF

    SPF is about IP addresses. Unfortunately, if you sent out email from behind a shared IP service (such as an ISP, or an email cloud filtering service), others will also use those same set of IPs. This means that if others cause that IP reputation to degrade, your IP reputation degrades along with it. If they start spoofing you, other 3rd parties will pass that SPF check since both of you have the same set of IPs in your SPF records (I wrote about this here).

    DKIM is resistant to this since each domain signs with its own key. Thus, when you build domain reputation, you are building reputation on your own domain instead of everyone’s domain the way you would if you were sharing IP space.

  3. Signing with DKIM tells receivers that you are taking responsibility for the email
    Because DKIM is largely spoof resistant, email receivers can look at the signing domain and determine who is responsible for the email. The sender is not spoofed, and therefore you are building a greater degree of trust.

    But beware! Signing with DKIM allows email receivers to trust you, but just because you sign with DKIM doesn’t automatically mean they will trust you. You still need to build your reputation. Signing with DKIM makes it easier.

    If you sign with DKIM but send spam, or users complain loudly about the email you sent, DKIM will not help you. But if you send email users want, then it does.

  4. The cool kids sign with DKIM

    We all want to be part of the cool kids.

How to sign with DKIM

If you are going to sign with DKIM (and you do), and you are outsourcing your email, then it is easy to sign with DKIM. Simply find a bulk emailer that will sign with DKIM, and they will do all the work for you.

Let’s go back to our example sender – Oceanic Airlines. They contract out to send their marketing email. Oceanic wants the message to pass DKIM. What does that look like?

  1. First, agrees that it will be the one who will DKIM sign the message. They will pick something called a “selector.” The selector is a subdomain they will publish the public DKIM key to in their own DNS zone.

    In our example, they pick s1024_oceanicairlines. They pick this because the public key is unique to Oceanic Airlines, and the key length is 1024 bits. They like using this type of nomenclature because it’s easy to keep track of keys at a glance.

  2. Second, they publish the public key to their own DNS records at:

    Oceanic Airlines doesn’t have to publish anything.

  3. Third, when BigCommunications sends out the email communication, they use the “relaxed” header canonicalization algorithm, and the “relaxed” body canonicalization algorithm before DKIM-signing the message. They do this because there are some MTAs out in the wild that will reformat messages such as folding line wraps if it exceeds too many characters. If line wraps are folded after the message is DKIM signed, but not unfolded before the DKIM signature is verified, the DKIM signature will not validate.

  4. Fourth, BigCommunications picks the headers they are going to hash and sign. The choice of this is somewhat arbitrary, but BigCommunications picks the RFC5322.From, RFC5322.To, Message-ID, Subject, Content-Type and Date.

  5. Fifth, BigCommunications signs with the rsa-sha256 algorithm because it is more secure.

  6. Sixth, BigCommunications also ensures that the message passes an SPF check. They do all the same things we talked about in my previous post. SPF and DKIM are independent of each other. Setting up one does not affect the other.

Now that we are set up and ready to go, BigCommunications prepares the email to send it out. The SMTP conversation looks like this:

RCPT TO: <recipient>
Subject: Discover Ireland from $768* RT
From: Oceanic Airlines <>
To: Me
Content-Type: multipart/alternative;
Date: April 26, 2013, 4:30 PM PST
Message-ID: <>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=s1024_oceanicairlines;; h=Message-ID:Date:Content-Type:From:To:Subject;

<Everything else in the email>

When the email receiver gets the message, they do a standard SPF check on the sending IP against the domain This passes.

Next, they see the message has a DKIM header and extracts the public key from They perform the necessary DKIM validation magic and the message validates.

Both SPF and DKIM have passed!

There’s no free lunch, however

But be mindful about what’s going on here: is not building reputation; it is not the domain in the RFC5321.MailFrom where SPF is performed, nor the domain in the d= field in the DKIM signature. Instead, it is that is building reputation.

What this means is that email receivers will hold responsible for Oceanic’s email. That means that BigCommunications will have stringent anti-abuse policies in place that Oceanic must comply with. This is all well and good because if Oceanic doesn’t play by its rules, Big Communications can cut off their outbound email flow.

On the other hand, it is also that is building the good reputation, not Oceanic. If Oceanic decides it doesn’t like BigCommunication’s terms, it can’t just pick up and do it themselves.


Because email receivers don’t know who is with respect to bulk advertising email. It’s difficult to get bulk email delivered without getting blocked or throttled by all of the big email providers. Reputation is difficult to generate and maintain.

Thus, if you have a 3rd party send email on behalf of you, and they sign it with their DKIM key in their DNS, you give up control of generating your own bulk email reputation. So long as you are willing to comply by the 3rd party’s rules, and you don’t need to send your own bulk email, everything is fine. It’s quick and easy and you don’t have to do anything special other than pay for the service.

However, if you do want to generate your own reputation, then you’re going to have more work to do. That’s a topic for my next post.

Oh, one last thing – you don’t have to bother signing email with DomainKeys, only DKIM.


Quick Navigation