Configure DKIM, DMARC in Office 365

DKIM (Domainkeys Identified Mail) is another scheme like SPF that aims to prevent spoofing of your domain name by spammers. Like SPF, this not help only with emails from your domain to other organizations, but also inbound emails to your users when attackers are trying to impersonate your domain. DKIM is implemented as a digital signature in the header of email messages. There’s some DNS involved in this, as well as asymmetric cryptography. DKIM is not mandatory, but it certainly recommended.

Office 365 uses the tenant domain to manage the DKIM signing. So that is the unique onmicrosoft. com domain that each tenant chooses at signup. They use the tenant domain, because they control the DNS for that domain, which is crucial to the DKIM signing process. Microsoft recommends that we enable this for custom domains. DKIM is enabled by default on .onmicrosoft.com

Requirements for DKIM

We need to create 2 CNAME records in our public DNS zone and once we have them in place we can enable DKIM.

Let’s go through the steps for configuring DKIM. Before you login to your external dns and create those 2 CNAME records you will have to know what value you need to type in. To discover that, login to your Office 365 tenant, click on Admin Centers –> Security & Compliance

Click on Threat Management –> Policy –> DKIM

Click on the custom domain where you want to enable DKIM and click on ENABLE. Once done, you will receive a warning message which will tell you that those 2 CNAME records are not created. There you will see the info about what to type or how to create those CNAME records.

Selector: The selector is the DNS record that will be queried for the public key to verify the digital signature (selector1-domain-com)

_domainkey: protocol

Domain: domain.onmicrosoft.com

The selector and domain were provided in the DKIM signature. The _domainkey is a standard part of the DKIM protocol. The three pieces of information are joined together to represent the DNS name that will be queried

selector1-domain-com._domainkey.tenantdomain.onmicrosoft.com

Once you know that you will then login to your external dns and create those 2 CNAME records. The reason we configure two selectors for DKIM signing in DNS is because Exchange Online is going to rotate between the two, which allows it to expire old keys, and enable the use of new keys on a regular basis. It rotates between them approximately every week. How would you configure those CNAME records?

Name: selector1._domainkey

Type: CNAME

Value: Here you specify that whole thing you see in the warning message so for the first record you will type in selector1-domain-com._domainkey.tenantdomain.onmicrosoft.com

Do the same for the second record. Once done, go back to your office 365 portal and click on the enable. If you don’t see that the DKIM is enabled right away, keep in mind that it may take a few minutes.

Now that DKIM signing is in place with a custom domain, we can implement DMARC as well.

NO DKIM KEYS SAVED FOR THIS DOMAIN

It may happen that you click on your custom domain and you see Status: No DKIM keys saved for this domain and with no Enable button. Even if you connect to Exchange online with powershell and run Get-DkimSigningConfig you will not be able to see that domain in the list.

To resolve this you will need to connect to Exchange online with powershell and run New-DkimSigningConfig -domain <your custom domain> -Enabled $True

Once done, you will be able to enable DKIM on your custom domain.

 

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC allows domain owners to publish a policy that advises receiving servers on what they should do with emails that fail SPF and DKIM checks. If those two mechanisms are failing, you specify what happens next by publishing a DMARC policy. DMARC is implemented as a DNS TXT record, so like SPF and DKIM, this is fairly simple to implement through DNS. A nice feature of DMARC is the reporting aspect, which allows you to receive reports from receiving servers. I should also point out that you can’t implement DMARC until you’ve implemented SPF, as well as DKIM for your custom domain in Office 365.

So why is this DMARC stuff important and effective at preventing spoofing?

The secret sauce, so to speak, is in the way two different addresses work for email messages.

MAIL FROM

The first address is the Mail From address, also known as the 5321 MailFrom address. This address identifies the sender of the email. If it’s sent by a person using their email client to send from their mailbox, it will just match their email address, but if it’s sent from an application or from a bulk mailing system, you’ll see a strange-looking email address there instead. MailFrom address is where any return notices are sent. A good example is non-delivery reports. MailFrom is present in the message headers, but it’s usually not displayed at all to the recipient of the email.

FROM

The other address is the From address. This is known as the 5322. From address, and this address specifies the author of the email, who actually wrote it, and who actually sent it, even if it’s a marketing email sent from a bulk email system, companies will usually use a friendly, real person’s name as the From address, or they’ll use a do not reply address. Either way, this is the email address that will be displayed in most email clients as the From address or the sender of the email.

So let’s see through an example why DMARC is important and effective.

Spoofed email example

MAIL FROM: accounts@nastyhackers.com

FROM: accounts@swedbank.se

TO: finance@mehic.se

Subject: Urgent action required to verify your account.

It uses the Mail From address of accounts@nastyhackers.com but the From Address of accounts@swedbank.se, that itself is not an immediate red flag. Remember the Mail From address can be different and usually is different to the From Address. So we need to leverage the anti-spoofing schemes (SPF, DKIM, DMARC)

SPF: The SPF result for this email could very well be passed, because SPF checks are usually performed only against the Mail From address, and there’s nothing stopping these nastyhackers from adding a valid SPF record to their domain, so those emails pass the SPF checks.

DKIM: Emails can pass the DKIM check as well, because nastyhackers can sign it using their own domain. They can do that, and it’s the same type of DKIM scenario as when Microsoft is DKIM signing your outbound email from Office 365, before you enable DKIM for your custom domains.

DMARC: What the attacker can’t do is pass a DMARC check, because that absolutely relies on the address in the From field where they are spoofing someone else’s domain and the reason they can’t do that is because you control the DNS zone for your domain, so you control the DMARC policy. The phisher can only beat DMARC if they already have control of your domain name DNS.

So how we can enable this. Once we have SPF, DKIM in place we need to publish DMARC policy in DNS and this is a TXT record.

DMARC TAG OPTIONS

DMARC tags are the language of the DMARC standard. They tell the email receiver to check for DMARC and (2) what to do with messages that fail DMARC authentication. I will focus only on these tags.

v = This is the version tag that identifies the record retrieved as a DMARC record. It’s value must be DMARC1 and be listed first in the DMARC record

p = This indicates the requested policy you wish mailbox providers to apply when your email fails DMARC. Options are none, reject , quarantine

• none – means “take no action, just collect data and send me reports”
• quarantine – means “treat with suspicion”
• reject – mean “block outright”.

pct = The percentage of messages to which the DMARC policy is to be applied

rua = This is a tag that lets mailbox providers know where you want aggregate reports to be sent. Aggregate reports provide visibility into the health of your email program by helping to identify potential authentication issues or malicious activity.

ruf = This tag lets mailbox providers know where you want your forensic (message-level) reports to be sent.

On your custom domain external DNS create new TXT record and for values type in

Name: _dmarc

Type: TXT

Value: v=DMARC1; p=none; pct=100; rua=mailto:support@domain.com; ruf=mailto:support@domain.com

You can verify this by going to ex https://dmarcian.com/dmarc-inspector/

Warnings / Errors

You may receive this warning message when you run DMARC lookup

Missing authorization for External Destination.

What does this mean, is that domain that is going to send reports (your source domain) don’t have permission to send reports to the destination domain.

Let’s say that we have a domain named nm.com that want to send reports to mehic.com. Mehic.com must have TXT record which will allow nm.com to send reports to it.

So we need to create a TXT record on the destination DNS (mehic.com) with these values

Name: nm.com._report._dmarc

Type: TXT

Value: DMARC1

We can use wildcard as well to accept DMARC reports from any domain.

*._report._dmarc

That’s it.

Cheers,

Nedim