- User ID
- 1
- Joined
- 7 Jan 2019
- Messages
- 861
- Reaction score
- 35
- Points
- 28
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
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:
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.
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:
Now we'll need to go to the DNS manager, and create the following DNS records:
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.
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:
Since we have properly configured both SPF and DKIM, let's form a DMARC TXT for the domain:
Hints:
Now we have SPF, DKIM and DMARC configured, if you test sending mail using mail-tester.com, you should get 10/10 score:
You can verify if your SPF, DKIM and DMARC records are working on one of my preferred mail checkers down below:
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.
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;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
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.
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.
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:
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.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.
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;
s=selector1;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
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"Hints:
- 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.
Now we have SPF, DKIM and DMARC configured, if you test sending mail using mail-tester.com, you should get 10/10 score:
You can verify if your SPF, DKIM and DMARC records are working on one of my preferred mail checkers down below:
- mail-tester.com
- dmarcanalyzer (SPF)
- dmarcanalyzer (DKIM)
- dmarcanalyzer (DMARC)
- kitterman
- googleapps
