Mail Technologies(DKIM & DMARC) - Part 2

Mail technologies(SPF, DKIM and DMARC) are important to understand from all sides. This post dives into DKIM and DMARC.

Mail Technologies(DKIM & DMARC) - Part 2

Hopefully you've read part 1 and are raring to learn more about the other mail security technologies that can assist in a layered security implementation.

It is important as creators, builders, defenders, attackers and combinations of all to understand how email technology can be leveraged to better the security of an organisation. Enter part 2 and 3 of my mail technologies series diving into three DNS records that could help secure your organisations' mail for the better.

DomainKeys Identified Mail (DKIM)

DomainKeys Identified Mail, or DKIM, is a technical standard that helps protect email senders and recipients from spam, spoofing, and phishing.  It is a form of email authentication that allows an organisation to claim responsibility for a message in a way that can be validated by the recipient.

Specifically, it uses an approach called “public key cryptography” to verify that an email message was sent from an authorised mail server, in order to detect potential spoofed senders and to prevent delivery of harmful email like spam. It supplements SMTP, the basic protocol used to send email, because it does not itself include any authentication mechanisms.

It works by adding a digital signature to the headers of an email message, that signature can be validated against a public cryptographic key in the organisation’s Domain Name System (DNS) records. In general terms, the process works like this:

A domain owner publishes a cryptographic public key as a specially-formatted TXT record in the domain’s overall DNS records.

Here is what the full DNS DKIM record looks like for 600 IN TXT "v=DKIM1\; p=MIGfMA0GCSqGSIb3DQEbaihfadouhsdofuhsUBAMASYIGSDAFTDCBiQKBgQC1TaNgLlSyQMNWVLNLvyY/neDgaL2oqQE8T5illKqCgDtFHc8eHVAU+nlcaGmrKmDMw9dbgiGk1ocgZ56NR4ycfUHwQhvQPMUZw0cveel/8EAGoi/UyPmqfcPibytH81NFtTMAxUeM4Op8A6iHkvAMj5qLf4YRNsTkKAV;"

  • The selector (s=): dk1024-2012 ; indicates the selector record name used with the domain to locate the public key in DNS. The value is a name or number created by the sender. s= is included in the DKIM signature.
  • The domain (d=): ; d= indicates the domain used with the selector record (s=) to locate the public key. The value is a domain name owned by the sender. d= is included in the DKIM signature.
  • The public key (p=): MIGfMA0GCSqGSIb3DQEbaihfadouhsdofuhsUBAMASYIGSDAFTDCBiQKBgQC1TaNgLlSyQMNWVLNLvyY/neDgaL2oqQE8T5illKqCgDtFHc8eHVAU+nlcaGmrKmDMw9dbgiGk1ocgZ56NR4ycfUHwQhvQPMUZw0cveel/8EAGoi/UyPmqfcPibytH81NFtTMAxUeM4Op8A6iHkvAMj5qLf4YRNsTkKAV; p= indicates the public key used by a mailbox provider to match to the DKIM signature.
  • The version (v=): DKIM1

A DKIM signature is a header added to email messages. The header contains values that allow a receiving mail server to validate the email message by looking up a sender’s DKIM key and using it to verify the encrypted signature. It looks something like this:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google;

The signature is constructed similar to the DNS entry whereby each parameter is explained below:

  • v= version of DKIM in use
  • a= signing algorithm used for the signature which in the example above was rsa-sha256
  • d= domain that the keys are for
  • s= selector
  • c= canonicalization algorithm(s) for header and body
  • q= default query method
  • t= signature timestamp
  • x= expire time
  • h= header fields - list of those that have been signed
  • bh= body hash

When receiving emails that have a DKIM header, the receiving SMTP server wanting to verify uses the domain name and the selector to perform a DNS lookup.

Now that I've explained what the different parts mean you might be wondering that's all fine and well but how do I generate a DKIM record for my own domain? Fear not, there are a few methods for doing this.

Most registrars and hosting providers have an option to generate a DKIM key however there are also docker images available to do this;

docker pull tvial/docker-mailserver:latest

The docker-mailserver docker image will allow you to generate a DKIM key for a given domain; Specifically the generate script is located [here].

docker-compose up -d mail

Once the image is up and running you can run the following command to generate a DKIM key for a select domain, in this case we'll use but replace this with whatever domain you want to use.

docker run --rm -v "$(pwd)/config":/tmp/docker-mailserver -ti tvial/docker-mailserver:2.2 generate-dkim-config

This will output the new DKIM key to config/opendkim/keys/

This key can be viewed using the following command;

cat config/opendkim/keys/ | awk -F '"' '{print $2}'

Then simply throw this in a DNS TXT record; 600 IN TXT "contents of key"

Simples, there you have a DKIM generated!

So if you've been following from the first half you should have a SPF and DKIM record setup within your DNS settings. Next it is time to marry them up with a DMARC record for the full mail validation experience.

Domain-Based Message Authentication Reporting & Conformance(DMARC) {Just rolls of the tongue...}

DMARC is essentially a protocol created for reporting, authentication and policy for e-mails. It adds value to DKIM and SPF records by linking together the author (“From:”), domain name(e.g and published policies to the domain which are used for handling recipient authentication failures. Additionally, it checks if DKIM and SPF have been configured correctly together. It also does reporting from recipients and senders to improve and monitor protection of the domain from fraudulent email also called spoofing.

It is implemented much like DKIM and SPF in that it is a DNS TXT record on the domain that it is configured for. An example DMARC configuration is broken down and explained below:

"v=DMARC1;p=reject;sp=reject;pct=100;rua=mailto:[email protected]"  

Similar to DKIM and SPF examples, this record is broken down as follows:

  • v=DMARC1: specifies the DMARC version
  • p=reject: specifies the preferred treatment, or DMARC policy, in this case it has been set to reject messages outright if mail messages fail the conditions of the DMARC validation.
  • sp=reject: much like p, this specifies the policy, however as p is for the primary domain, sp covers subdomains and how these should be treated.
  • pct=100 is the percentage of mail to which the domain owner would like to have its policy applied
  • rua=mailto:[email protected] is the mailbox to which aggregate reports should be sent, there is also ruf which specifies where forensic reports should be delivered to, this can be a separate email address.

In this scenario, the sender defines the policy as such that the receiver outright rejects all non-aligned messages and sends a report about the rejections to a specific email address. If the sender were to use the “quarantine" setting in the policy, it would look like:

"v=DMARC1;p=quarantine;pct=100;rua=mailto:[email protected]" 

and would request the action to quarantine on the receiving end of the message. In the next example, if a message claims to be from your domain and fails DMARC, no action is taken. Instead, these messages will then show up in your daily aggregate report sent to whatever email address you set in rua.

 "v=DMARC1; p=none; rua=mailto:[email protected]" 

While it is a useful protection measure to have DMARC it is not a silver bullet, it can work in conjunction with a properly tuned SPF and DKIM setup but other steps are required to prevent e-mail based attacks. It certainly will aid in sifting out spam-like messages and lesser skilled phishing attempts that do not have necessary DKIM and SPF setup.

Combining DKIM, SPF & DMARC for Hax

Often when faced with a phishing engagement an attacker will query the DNS records of a target to see if misconfigurations such as missing SPF or DKIM records can be leveraged to spoof mail or get mail into an organisation.

Even when things like SPF, DKIM and DMARC exist,  email spoofing is still a problem and a common vector for phishing attacks.

A common misconfiguration with SPF is due to softfail being set with no DMARC and DKIM records married up. Again as stated above none of these are a silver bullet however if an organisation has softfail enabled in SPF and no DMARC the record is as good as having nothing. Again misconfiguring DMARC with p set to none combined with SPF softfail is another example of as good as not having anything setup.

Finding Misconfigurations

A good first step to audit your own DNS is to gather all your  TXT records for the domain;

host -t txt

The command above will print out all the TXT records for the given domain, the next step is to look for any SPF records, usually these will begin with v=spf1. To do the same for DMARC records, these will start with  v=DMARC1 at the subdomain _dmarc.

If the SPF record ends with ~all or +all the DMARC record needs to contain p=reject or p=quarantine,  if it does not then this would be vulnerable to spoofing.

It is important to note from an attacking and defending perspective that SPF records should exist on all sub-domains as well, while DMARC is only on the main domain. So if a domain only has the DMARC policy set for the primary domain but not subdomains this might also be vulnerable; p refers to the main domain, while sp controls sub-domains.

Being a Smart Attacker

Now that you have a bit of an understanding of SPF, DKIM and DMARC, it is important to test your setup when configuring attacking infrastructure such as mail servers and mail domains, testing if the records are configured correctly can be done via several services online, my favorites to leverage are &, these will validate if your TXT records are configured correctly for emailing and give options of things to fix.