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:

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: <>
v=1; a=rsa-sha256; c=relaxed/relaxed;
; 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

Comments (7)
  1. says:…/index.html

    How to Sign with DKIM?

    free smtp server relay email in india

    Home Download

       created: 03/10/2011

       latest update: 11/9/2013

       by: jSMTP smtp server relay email in india


    smtp server relay email in india – free mass e-mailing solution

  2. Ranvir Sharma says:…/index.html

    What is DKIM? DomainKeys Identified Mail is a method for associating a domain name with an email message, thereby allowing a person, role, or organization to claim some responsibility for the message. The association is set up by means of a digital signature which can be validated by recipients.

  3. santu says:

    We are providing bulk email solution

    Cheap Dedicated server with multiple IP Address

    PowerMTA email Server and Interspire Email marketer

    Contact Us

    Skype ID : san2roy

    Gtalk ID : san2roy

    Email : san2roy @ gmail .com

  4. says:

    for more info regarding same you can visit us ..

    and find all info live chat ..

  5. Max says:

    Very useful post!

  6. William Pyles says:

    Placing the SPF and DKIM DNS TXT resource records in the outsourced company’s DNS (in this case BigCommunications) will allow SPF and DKIM to be authenticated, but not aligned. The domain in the From: field does not match the d= tag in the DKIM signature, nor does it match the MAIL FROM: domain. This will cause DMARC to fail.

  7. William Pyles says:

    A better way would be to publish the SPF and DKIM records in a subdomain of the outsourcing company (Oceanic Airlines), provide BigCommunications with the private DKIM key for that selector, and include their sending servers in the subdomain’s SPF record. Then BigCommunications would need to use a MAIL FROM that includes the subdomain you created and you could align AND authenticate.

Comments are closed.

Skip to main content