In my previous post, I described how you can set up DKIM records if you are outsourcing your advertising email to a 3rd party.

In summary: You don’t have to do anything.

However, this comes at the cost of not being able to generate your own domain-reputation. You may care about generating reputation. After all, you want to be seen as a good and responsible email sender. This will help get email delivered to the inbox, and prevent getting added to IP blocklists or throttling lists. As spam filters move to domain-reputation, you want to be ahead of the game.

So how do you keep your own reputation when you outsource your email?

Let’s go back to the SMTP transaction from the previous example where Oceanic Airlines is outsourcing their bulk email to BigCommunications:

HELO mail.bigcommunications.com
MAIL FROM: oceanic.airlines@bigcommunications.com
RCPT TO: <recipient>
DATA
Subject: Discover Ireland from $768* RT
From: Oceanic Airlines <oceanic@news.oceanicairlines.com>
To: Me
Content-Type: multipart/alternative;
    boundary="----=_Part_8280486_25400197.1366674040595"
Date: April 26, 2013, 4:30 PM PST
Message-ID: <04262013_0163013@bigcommunications.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=s1024_oceanicairlines;
d=bigcommunications.com; h=Message-ID:Date:Content-Type:From:To:Subject;
bh=<hash>;
b=<hash>
<Everything else in the email>
.
QUIT


In this example, email receivers are building reputation on the domains in the RFC5321.MailFrom and the domain in the d= field in the DKIM signature. Here they are both bigcommunications.com.

In order to build reputation using DKIM, Oceanic Airlines must be the domain in the d= field. This means that when email receivers get this message, they will perform a DKIM validation on s1024_oceanicairlines._domainkey.oceanicairlines.com.

But how? Isn’t BigCommunications the one signing with DKIM? With a private key? How does Oceanic Airlines know what the public key is that is associated with the signing private key?

There are two ways to accomplish this:

  1. Option 1 – Generate a key pair and give the private one to BigCommunications

    This is just as it sounds. The only way to know the public and private key pairs is to generate them both yourself. Then, you give the private key to BigCommunications and say “Here, sign with this key, and put this selector and d= field into the DKIM signature.” You then go and publish a DKIM record into the desired subdomain along with the public key. In this example, it would be:

    s1024_oceanicairlines._domainkey.oceanicairlines.com

    When BigCommunications sends email, the domain in the d= field is oceanicairlines.com. Email receivers are building reputation on oceanicairlines.com, which is your own domain. Since you are the ones actually composing the email, this is an added bonus (BigCommunications still has a strict anti-abuse policy since you can still degrade their IP reputation). Furthermore, the RFC5321.MailFrom address doesn’t change.

    Both DKIM and SPF pass!

  2. Option 2 – Let the 3rd party generate the key pair, and give you the public one to publish into DNS

    Very similar to option 1, rather than you generating the key pair, BigCommunications generates the key pair. They then tell you to publish the public key and required DKIM record into the necessary DNS subdomain. They will sign with your domain in the d= field, and everything else remains the same as option 1.


    Once again, SPF and DKIM will pass, and you will generate reputation on your own domain.


This sounds pretty good. All you need to do is generate a public/private key pair and publish one to DNS and give the other to the 3rd party. Easy!

But there is no free lunch.

First, there’s the hassle of maintenance:

  1. it’s not as easy as just getting the 3rd party to do it all themselves. You can “set it and forget it.” It is not the case with this set up.

  2. If you aren’t a DNS expert, you may have a tough time managing it. The key goes where…? The DKIM record looks like what…?

  3. You will also have to rotate the keys every so often, and ownership of maintenance of those records will get lost if you are in a large organization and the keys don’t change very often. The people who are responsible for setting this up change positions and forget to hand it off to the next guy. This becomes challenging if there are a lot of domains to manage.

Second, the 3rd party may get compromised, or you may have hired an evil 3rd party, who start sending out spam using your private key and your domain. What if an email receiver ever gets the following message:

HELO mail.bigcommunications.com
MAIL FROM: oceanic.airlines@bigcommunications.com
RCPT TO: <recipient>
DATA
Subject: WIN A *** FREE *** TRIP TO WINNIPEG!!!
From: Oceanic Airlines <oceanic@news.oceanicairlines.com>
To: Me
Content-Type: multipart/alternative;
    boundary="----=_Part_8280486_25400197.1366674040595"
Date: April 26, 2013, 4:30 PM PST
Message-ID: <04262013_0163013@bigcommunications.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=s1024_oceanicairlines;
d=oceanicairlines.com; h=Message-ID:Date:Content-Type:From:To:Subject;
bh=<hash>;
b=<hash>
<Everything else in the email>
.
QUIT

Now, as we all know, Winnipeg is a very enticing place and many of Oceanic’s customers want to go there.

 

However, it is not Oceanic that has sent the message, but a spammer that has broken into BigCommunications, compromised the system and is sending out spam with malicious links. People all around the Internet – in a frenzied desire to go to Winnipeg – start clicking on them.

What happens?

Everyone starts complaining that they are getting spam in their inboxes “from” oceanicairlines.com. Oceanicairlines.com will see its reputation degrade. Some spam traps will harvest the sending domain (especially because it is signed with DKIM) and start adding them to domain blocklists. Some email receivers will do deeper forensics, but not all.

When Oceanic tries to send out its next legitimate email campaign, filters all around the world reject it because they got so much spam from Oceanic in the past. This is all because some spammer broke into someone else’s house where you store your stuff.

Worse yet, Oceanic’s corporate domain, oceanicairlines.com, is also blocked. Their users can’t send email to its regular customer base, or people they regularly communicate with, because so many spam filters have their domain listed on a domain blocklist.

When you let someone else sign email as your own domain, you are at the mercy of their security practices. You may have good corporate security, but necessarily others who can impact your reputation.

So how can you prevent this?

First, if you discover that your domain is being abused, immediately revoke the DKIM record. It’s published in your own DNS zone, so you can take action to delete the record. When that happens, the spam messages will no longer authenticate with DKIM and instead will “only” pass SPF. But the good news is that email receivers will look to the domain in the SPF record as the one responsible – BigCommunications.com.

Second, you may decide you want to do this key-publishing trick but you want to mitigate the risk of a rogue 3rd party sending as you. To do this, you delegate a subdomain to this 3rd party, very similar to what was done for passing SenderID.

In our example, Oceanic delegates news.oceanicairlines.com. This way, if the 3rd party ever sends out spam, the “only” domain that is compromised is the one for bulk advertising. You can still send out email from your main domain.

Let’s review. Below is the SMTP transaction:

HELO mail.bigcommunications.com
MAIL FROM: oceanic.airlines@bigcommunications.com
RCPT TO: <recipient>
DATA
Subject: New in May: Discount trips to
Istanbul
From: Oceanic Airlines <oceanic@news.oceanicairlines
.com>
To: Me
Content-Type: multipart/alternative;
    boundary="----=_Part_8280486_25400197.1366674040595"
Date: April 26, 2013, 4:30 PM PST
Message-ID: <04262013_0163013@bigcommunications.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=s1024_oceanicairlines;
d=news.oceanicairlines.com; h=Message-ID:Date:Content-Type:From:To:Subject;
bh=<hash>;
b=<hash>
<Everything else in the email>
.
QUIT

First, this message passes an SPF check because it is sent from bigcommunications.com’s IPs, and it contains their domain in the RFC5321.MailFrom.

Second, this message passes a DKIM check on news.oceanicairlines.com because Oceanic has generated a public/private key pair and given BigCommunications the private key to sign with.

Third, Oceanic delegated news.oceanicairlines.com specifically for sending outsourced email. If BigCommunications ever goes rogue, that is the only subdomain that should be affected.

Fourth, Oceanic is building reputation on its subdomain news.oceanicairlines.com. This is not quite as good as building it on its parent domain oceanicairlines.com, but it’s the next best thing. Besides which, Oceanic DKIM signs its email from @oceanicairlines.com coming out of its own email servers, so it is generating reputation that domain, too.

This is a good state of affairs.

* * * * * * * * * * * *

We now have a comprehensive guide to outsourcing email so that it passes SPF, SPF + SenderID, and SPF + DKIM.

There is still one more type of authentication left: DMARC. Passing DMARC will require all of our previous knowledge, and also allows us to pass SPF + SenderID + DKIM if we choose.

 


Quick Navigation