Take your email sending credibility even further by implementing DKIM & DMARC


Creative Team
User ID
7 Jan 2019
Reaction score
Having a properly configured SPF is essential, in this article we'll learn how to improve your email sending credibility even further by implementing DKIM & DMARC.

Assuming you already have SPF configured properly on your domain if you haven't, click here to learn more šŸ’”

DomainKeys Identified Mail (DKIM) allows the receiver to check that an email claimed to have come from a specific domain was indeed authorised by the owner of that domain. It achieves this by affixing a digital signature, linked to a domain name, to each outgoing email message. The recipient system can verify this by looking up the sender's public key published in the DNS. A valid signature also guarantees that some parts of the email (possibly including attachments) have not been modified since the signature was affixed. Usually, DKIM signatures are not visible to end-users and are affixed or verified by the infrastructure rather than the message's authors and recipients.
Domain-based Message Authentication, Reporting and Conformance (DMARC) is an email authentication protocol. It is designed to give email domain owners the ability to protect their domain from unauthorized use, commonly known as email spoofing. The purpose and primary outcome of implementing DMARC is to protect a domain from being used in business email compromise attacks, phishing emails, email scams and other cyber threat activities.

Once the DMARC DNS entry is published, any receiving email server can authenticate the incoming email based on the instructions published by the domain owner within the DNS entry. If the email passes the authentication, it will be delivered and can be trusted. If the email fails the check, depending on the instructions held within the DMARC record the email could be delivered, quarantined or rejected. For example, one email forwarding service delivers the mail, but as "From: no-reply@<forwarding service>".

DMARC extends two existing email authentication mechanisms, Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). It allows the administrative owner of a domain to publish a policy in their DNS records to specify which mechanism (DKIM, SPF or both) is employed when sending email from that domain; how to check the From: field presented to end users; how the receiver should deal with failures - and a reporting mechanism for actions performed under those policies.

Without further ado, let's configure the DKIM šŸ”

In this scenario, we'll be using Microsoft 365 (previously: Office 365) MX, and if you're on Microsoft 365, you might not realise that Microsoft is already signing DKIM for your messages.

Have a look at the following message header:
Rich (BB code):
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
smtp.mailfrom=saputra.org; dmarc=pass action=none header.from=saputra.org;
dkim=pass header.d=saputra.org; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=<tenant name>.onmicrosoft.com;
s=selector<x>-<tenant name>-onmicrosoft-com;
bh=<body hash>;
b=<signed field>

All hosted mailboxes in Microsoft 365 gains the benefit of ARC with improved deliverability of messages and enhanced anti-spoofing protection. ARC preserves the email authentication results from all participating intermediaries, or hops, when an email is routed from the originating server to the recipient mailbox. Before ARC, modifications performed by intermediaries in email routing, like forwarding rules or automatic signatures, could cause DMARC failures by the time the email reached the recipient mailbox. With ARC, the cryptographic preservation of the authentication results allows Microsoft 365 to verify the authenticity of an email's sender.
Microsoft uses this method because they have no ability to edit your DNS zone file. But they do control onmicrosoft.com. This is where they provision the DKIM DNS records. They also couple this with DMARC. With DMARC they tell recipients to accept a sender address of saputra.org with a DKIM domain of <tenant>.onmicrosoft.com.

This advantage encourages me to favour Microsoft 365 when compared with Google Suite šŸ˜

If you're like me, you may want to tidy things up a bit. I prefer the domain field in my DKIM header to match my from address. The remainder of this article describes how to accomplish that goal by enabling explicit DKIM signing.

Let's review our Microsoft 365 settings to verify how everything is currently configured in the tenant šŸ¤“

Go to https://portal.office365.com -> Admin -> Exchange -> Protection -> DKIM.

Screen Shot 2020-07-22 at 1.02.38 PM.png

From the screenshot above, we can see that the <tenant>.onmicrosoft.com already have DKIM enabled, which we can see from the message header above.

I'll demonstrate setting up DKIM for the domain name called: cya.nz

If you press Enable here, you will get this message:

Screen Shot 2020-07-22 at 1.13.57 PM.png

Now we'll need to go to the DNS manager, and create the following DNS records:

Rich (BB code):
selector1._domainkey.cya.nz. 300 IN CNAME    selector1-cya-nz._domainkey.<tenant>.onmicrosoft.com.
selector2._domainkey.cya.nz. 300 IN CNAME    selector2-cya-nz._domainkey.<tenant>.onmicrosoft.com.

Screen Shot 2020-07-22 at 1.23.01 PM.png
Screen Shot 2020-07-22 at 1.27.29 PM.png

Once those two CNAME records are created, go back to Exchange -> Protection -> DKIM, and now we should be able to enable the DKIM for the aforementioned domain.

Screen Shot 2020-07-22 at 1.31.33 PM.png

Now when you send an email, you will get an explicitly signed DKIM for that domain, for example, have a look at the message header down below:

Rich (BB code):
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
smtp.mailfrom=saputra.org; dmarc=pass action=none header.from=saputra.org;
dkim=pass header.d=saputra.org; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=saputra.org;
bh=<body hash>;
b=<signed field>

Since we have properly configured both SPF and DKIM, let's form a DMARC TXT for the domain:

Rich (BB code):
_dmarc.cya.nz.        3600    IN    TXT    "v=DMARC1; p=<policy>; pct=100"

  • By default, the record protects mail from the domain and all subdomains. For example, if you specify _dmarc.cya.nz, then DMARC protects mail from the domain and all subdomains, such as www.cya.nz or mail.cya.nz.
  • TTL should always be the equivalent of one hour. The unit used for TTL, either hours (1 hour), minutes (60 minutes), or seconds (3600 seconds), will vary depending on the registrar for your domain.
  • pct=100 indicates that this rule should be used for 100% of email.
  • the policy specifies what policy you want the receiving server to follow if DMARC fails. You can set the policy to none, quarantine, or reject.
For example:

Screen Shot 2020-07-22 at 1.41.14 PM.png

Now we have SPF, DKIM and DMARC configured, if you test sending mail using mail-tester.com, you should get 10/10 score:

Screen Shot 2020-07-22 at 1.51.32 PM.png

Screen Shot 2020-07-22 at 1.50.14 PM.png

Screen Shot 2020-07-22 at 1.54.59 PM.png

You can verify if your SPF, DKIM and DMARC records are working on one of my preferred mail checkers down below:
I trust this article been helpful to you, should you have any questions, don't hesitate to post on the comment section down below šŸ‘‡
 Short URL: