Alphabet Soup - CNAME, SPF, and DKIM on your DNS - pt.2 SPF and DKIM

Wikipedia defines SPF as follows: 

 

Sender Policy Framework (SPF) is a simple email-validation system designed to detect email spoofing by providing a mechanism to allow receiving mail exchangers to check that incoming mail from a domain comes from a host authorized by that domain's administrators.[1] The list of authorized sending hosts for a domain is published in the Domain Name System (DNS) records for that domain in the form of a specially formatted TXT record. Email spam and phishing often use forged "from" addresses, so publishing and checking SPF records can be considered anti-spam techniques.

 

Again, this is a very nice technical explanation but what does it mean?  I think of it as being something like the security that many companies maintain at their front desk, so the scenario would go something like this.

 

A delivery person dressed in a Marketo uniform walks up to the front desk of your lead's company (email server), and says to the person at the desk (who in our analogy would be the email security software), "Hi, I'm here to deliver email from yourmarketingteam@yourcompany.com to yourlead@theircompany.com."

 

The front desk/email security person looks up and notices the uniform says Marketo, not Yourcompany.  Depending on their security settings, they might just assume this is okay and buzz Marketo in to make the delivery.  However, if they are security-conscious, they are going to want proof that Marketo isn't trying to trick them with a phony delivery (spoofing an email).  SPF gives them the ability to call back to the DNS at Yourcompany and ask, "Hey, I've got someone here from Marketo who claims to be making a delivery for you.  Is this an authorized delivery?"

 

If Marketo is correctly included in the SPF record, then effectively, this allows the DNS to tell them, "Yes, Marketo is authorized to make deliveries from us."

 

So how does this differ from DKIM?  According to Wikipedia:

 

DKIM allows the receiver to check that an email claimed to come from a specific domain was indeed authorized by the owner of that domain which is done using cryptographic authentication.

 

Verification is carried out using the signer's public key published in the DNS. A valid signature guarantees that some parts of the email (possibly including attachments) have not been modified since the signature was affixed.

 

So if we go back to our analogy of the delivery at the front desk, it works a bit like this.  When the front desk calls the DNS to make sure the delivery is authorized, Marketo has to produce an ID badge with an authorization code on it.  The front desk/email security person reads that authorization code to the DNS which validates it against the code it has on record.  If the code matches, then the delivery is authorized.

 

Some email security programs require SPF, some require DKIM, and some don't require anything at all.  To be sure Marketo can always make your deliveries, you should always have both set up for each domain you use in the From: line of your emails.

 

Instructions for setting up SPF and DKIM can be found here.


Is this article helpful ?

YesNo


17 Comments

Hi Sanford,

I'm a bit confused by the "Shared DKIM key" blog entry.  Marketo no longer uses shared DKIM keys for authentication and hasn't done so for over a year now.  Some people may have legacy shared DKIM keys from before we rolled out the custom keys in 2014, but all new keys generated in the Marketo tool should be specific to the instance and domain.

Of the 60 instances I just surveyed, 44 are using the shared key.  Presumably this is because they are "legacy" clients, but since that key hasn't been revoked, there's no incentive to change and they are subject to the vulnerability discussed in my post.  There are also official documents that refer to the shared key.

I'm happy to hear this isn't the standard anymore, and I'll update the post with the advice that people review their DKIM key and ensure they use either a Marketo-generated unique key or a keypair provided by the client.

Hi Sanford,

We in Support have been trying to root that old document out for a while.  Could you tell me where you found it in our documentation so we can have it removed?

Thanks,

Roxann

Level 10

How do we know if we're still using the shared key?  And if we are, how do we move to a custom key?

Hi Dan

The value for the old shared key can be found here: http://pages2.marketo.com/rs/marketob2/images/Marketo%20DKIM.txt

You can check the value for the key on your DNS using NSLookup or one of the many available third-party tool.  Personally, I like the DKIMCore tool​. If you use that tool, you would enter the selector "m1" in the Selector field and your domain ("yourcompany.com") in the Domain Name field.  It will then display the DKIM key posted to your DNS.  Comparing it to the shared key can be challenging because they are long alphanumeric strings.  My tip is to compare the strings starting at the end rather than the beginning.  You can also compare them by pasting them both into Notepad or some similar application and comparing where word wrap breaks the lines.  If they are the same, they should break in the same places.

To switch out the the shared key for the custom key, just delete the existing DKIM entry from both your DNS and your Marketo instance, and go through the process here to reestablish the new custom key for your domain.

Level 10

Thanks Roxann.  We're still using the SHARED value.  Since we need to DELETE our existing record (updating it will negatively affect our deliverability), we’ll need to do this in a coordinated fashion.  For example, we essentially need to do this in real-time in that I will delete our existing record; create a new record; send IT the host record and TXT value; have IT create the new record – all at once.  Does that seem like the best approach?

Hi Dan,

Yes, that is what I would recommend.

You should also have IT lower the TTL on your current record.  While it's only 20m now, lowering it to 5m decreases the window of uncertainty and allows you to start testing that much sooner.

Level 10

I've raised this with our IT team.  They had the following questions:

  • Does this raise a security risk; or is it just something that could be impacting our deliverability?
  • Ironically, our IT team just recently updated DKIM for avanade.com (for our own internal servers).  Would we use this same entry in Marketo?
  • The updated DKIM text value is as follows ("v" value is the same; "p" value is different: "n" value doesn't even exist in our Marketo record):
    pastedImage_5.png

Sanford Whiteman

Roxann McGlumphy