Can you tell your DMARK from your DKIM ?

Four years ago I received a mysterious message from our email provider, mandrill. It was advising me that email sending for our startup would be stopped unless I completed DKIM and SPF signatures for our email.

Fortunately the email also contained some pretty easy to follow instructions so the issue was closed out pretty quickly. I was curious why we needed two; why DKIM & SPF ? I just never had the time to find out.

Fast forward four years and a pen test at my present company is telling us we don’t have DMARC set up. I googled DMARC only to find it’s connected to my old friends DKIM and SPF - now there’s a third thing to understand.

I’ll cut straight to the answer on what these three are and when/why you would use them. It’s pretty simple though much of the online documentation could leave you feeling the opposite.

What do SPF, DMARC and DKIM do ?

It’s scarily easy to send emails that look as if they come from another company, most junior developers can do it in a single line of code.

DMARC, DKIM & SPF help a server that’s receiving email to understand if that email really is from the organisation it claims to be and what to do if it isn’t.

SPF Records

These are DNS records that list the servers that the owner of the domain allows emails to be sent from. For example

If you own the domain “wonderland.com” then create a TXT dns record

@wonderland v=spf1 include:wonderland.com include:otherland.com -all

which basically tells any email server that receives an email where the from address contains @wonderland.com that it’s genuine if the email server that sent the message was a wonderland.com or otherland.com email server. If the email server that sent the message was, say, badland.com then the server receiving that message knows it’s likely to be a fake.

DKIM Records

That all seems very clear and simple, especially if you’re a bit old school and manage your own email servers but there’s a flaw in this plan. With the proliferation of SaaS providers for services like Helpdesk, Contact Management, Email marketing, infrastructure and just sending your emails, these days there are many online services that will legitimately send emails on Wonderland’s behalf.

For example it wouldn’t be uncommon for our Wonderland company to use:

  • Zendesk for customer service. Zendesk would send Customer Support emails to their customers as if they were from wonderland.com
  • Similarly Wonderland could send marketing emails via Salesforce or Hubspot.
  • Wonderland may also use Google Workplace so all of the emails sent by staff would be sent by a Google server
  • Wonderland may use a Payment Gateway that in turn uses the email provider Sendgrid that also sends payment notification emails.
  • Wonderland’s developers may use Amazon SES to send notifications & reports to customers and suppliers.

To solve the AWS SES problem we could just create an SPF record that states that amazon SES is a valid sender of emails:

@wonderland v=spf1 include:amazonses.com -all

The problem here is that if we use SPF to approve amazonses.com servers then anyone with an AWS account can send wonderland.com emails and the SPF record would confirm them as genuine.

DKIM is a contract between the sender and the domain of the customer - in this case wonderland.com.

If we continue AWS SES as an example, AWS would produce DKIM records unique to the wonderland.com account. This would be a public key that wonderland would upload to its DNS record servers.

Whenever Sendgrid sends an email it includes encrypted headers that would enable the receiving email server to use the public key it found in the wonderland.com DNS record and then decrypt those headers to determine if the email is genuine or not.

I have my own domain, creedon.me and use Google Workspace to send and receive emails from creedon.me.

From the admin console in my Google Account I generated this key:

DNS Host name (TXT record name):
google._domainkey
TXT record value:
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArdZT9N3VYg9T5zwK0kuDZe2Ja6U9kiQjGfqSVmzofUs7F/W2A7dwiWKvVUTZOZCEW4U3lgDexGAMBVLqwERQUnzaDmh6C/KswXlveFiEmSA4R2nGXYHGL/Vzd6TN2zQZV4VNeJ8Qug5kKXXFTXKOa01QthITaEsqfYKb6pMuvYtkhTi/rJKlqG9uigIVfRwiokZ8ctkpWbm0NoQZFGHbfDN/SdQ/czmSeJ2eyBHK6LInPuYGRyc3S0mEwVBhCftKWrKtSc+62kU5BLPSt4T8O5KHQzRxYRYl2YA24cnwIDAQAB

Now whenever Google sends an email as creedon.me it includes encrypted headers somethmg like this (I’ve deliberately mangled them as I’m publishing them to the web)

ARC-Seal: i=1; a=rsa-sha256; t=1664022561; cv=none;
    d=google.com; s=arc-20160816;
    b=VF6DwBEHw/qDJ2r+6b8d39Sk8Dh7Rwm1rUDxEg9PQSexARYsaRCHkhsXqRNTT94lfB
     svYhS2JFJXUnHwtBQYHj1/t2aBojh2cE06A2PAe/FCJMqcuRZw38V+AyzRDlTJGJneeg
     X5x0aRAWeDtRvhLGz8nOEhc/GF1YauqMid5jFeB3lvgBurzkM0S3OpuMAQLF5xfpr6mq
     RxRQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
    h=to:date:message-id:subject:mime-version:from:dkim-signature;
    bh=swvXdBQPVLbvU6Cgc7mMpIg3c8VOo507yblgRKDlMho=;
    b=urLfUnC4QbcxfY1KrWCl7fm18VlfHCfORpgzSvRfG1r6hA26bo50IZ3wLDNrUNZcPz
     oIR3n8RFNx4CJEwxQr7EtubP6XjENrPKfIUoSEjbihajXFyxXzssnAmhCAvmIQliRSc2
     lacPvNDiFnLNf2GB1MGzaKbtGazXGVaFEed+D2MydsfkRh9UQAktdO9EZUYv7fSbCEqf
     v3gw==
ARC-Authentication-Results: i=1; mx.google.com;
   dkim=pass header.i=@creedon-me.20210112.gappssmtp.com header.s=20210112 header.b=HiQCd2Cd;
   spf=neutral (google.com: 209.85.220.41 is neither permitted nor denied by best guess record for domain of erika@creedon.me) smtp.mailfrom=erika@creedon.me

Any email server receiving these headers can use the public key in the google._domainkey DNS record tp decrypt these headers and determine that my email is from a genuine source.

So what is a DMARC record ?

Fortunately DMARC is much simpler. It’s yet another DNS record - this is Google’s own DMARC:

v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com

This is an advisory message to receiving email servers suggesting what they should do with an email that fails both SPF and DKIM checks. In this case Google is advising that the email server reject all messages.

They can also set DMARC to quarantine - usually this means SPAM or report - this means simple report the outcome to a specified address e.g.

v=DMARC1; p=none; pct=100; rua=mailto:re+qstmoahrhur@dmarc.postmarkapp.com; sp=none; aspf=r;