Microsoft 365 administration: Creating DNS records for email security

In our continuing series on Microsoft 365 administration, today we are going to look at email security and how it can be enforced and enhanced with DNS records. So far in this series, we have looked at configuring Microsoft Teams (basic and advanced) and configuring your admin portal.

One of the first things to get migrated into Microsoft 365 is email. Email security is a top concern for everyone and rightly so. Email is how almost all bad things get into networks today. Because securing email is so important, this topic will be split into three articles. In this one, I’ll show you how to create the DNS records you need, and in the next article, I’ll suggest a few Exchange rules, and finally, we’ll look at how to configure the anti-phishing, anti-malware and anti-spoofing policies. All three — DNS records, rules, and policies — are required to create a secure email system.

Email security starts with SPF, DKIM, and DMARC records in your DNS. For some reason, people find creating these records intimidating. It’s really not difficult for most organizations.

DNS records: Sender policy framework

The first record, SPF (sender policy framework), is the one that most admins are probably familiar with. It was the first one that was required by public email services in order to keep your mail out of the junk folder or quarantine.

The SPF record verifies with DNS that the mail server that sent the mail is authorized to do so. The SPF record needs to include any service that will be sending mail as your domain. This will include bulk mail services, so be sure to check with the marketing department and see which services they are using. It might also include your website.

Below is an SPF record. It follows a specific syntax. Let me tell you how to read it.

v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net include:spf.smtp2go.com -all

Let’s use the table below. That table was generated by MXToolbox.com. There are many free services that will read your SPF for you, and some will even help you create them. However, I find those SPF creation sites to be overly complicated.

Reading the SPF record from left to right and the table from top down, the SPF record reads like this:

This is SPF1, spf.protection.outlook.com is allowed to send mail as my domain, as is servers.mcsv.net and spf.smtp2go.com if something doesn’t match those always fail.

Note that my table has five rows. Each row represents an SPF mechanism. You are allowed only 10. What if you need more? Then you need multiple SPF records. In that case, your SPF1 record would only include SPF2 and SPF3. And the specifics would be housed in SPF2 and SPF3.

Here’s an example of how to create multiple SPF records:

V=spf1 include: spf2.txt include spf3:txt -all

V=spf2 include: spf.protection.outlook.com -all

V=spf3 include: servers.mcsv.net include:spf.smtp2go.com -all

Domain keys identified mail

Domain keys are a digital signature. There is a private side and public side to these keys, and when put together, they positively identify you.

Microsoft creates one side and gives you the key that you need to reference it in your DNS record. In the Exchange admin center, you’ll go to dkim and then click enable next to your domain name. It’ll fail, but in doing so, it will tell you exactly what it is looking for you in your DNS records.

Once we have that information, we’ll use it to create a CNAME record in DNS. There will be two records one for selector1 and another for selector2

DKIM DNS EXAMPLE (NOTE: DNS is case-sensitive!):

Two things to note: In the table above, notice that your domain name is not yourdomain.net or yourdomain.com, it is yourdomain-net or yourdomain-com. Second, note the trailing “.” at the end of the address. Be sure to include that.

You might need to wait up to an hour for your DNS to propagate. When it has to go back into the Exchange admin portal, click that enable button again. When Microsoft can successfully read your DKIM record, it’ll show it as enabled.

Domain message authentication reporting and conformance

As the name implies, DMARC is an information feedback record. DMARC lets you know if your SPF and DKIM records are working properly, if you missed adding a service as an include record, and also if someone is trying to spoof your domain.

Reading a DMARC record is very similar to reading an SPF record. Below is an example record.

v=DMARC1; p=reject; ruf=mailto:[email protected]; pct=100

The table helps you read the record.

The record reads like this: From left the right in the sample and in the table, top to bottom. This is DMARC version1. The existence of this DMARC policy means, in plain language, that I want you to verify my email using my SPF and DKIM records. If it passes one of those, please accept the mail. If mail fails both of those, then reject the mail. I want you to check 100 percent of the email supposedly sent by me and send me a report of any failed mail.

Here’s how you create the record. DMARC is a txt record type. The hostname is always _dmarc and the address field contains your settings. Notice that in this record, items are separated by a semicolon.

DMARC DNS EXAMPLE (NOTE: DNS is case-sensitive!)

Instead of [email protected] you’ll enter the email address of the administrator that will review any email failures.

You do have the option of telling other servers not to reject your mail here. You can tell them instead just to report. This can be useful as a short-term trial while you find out if someone forgets to tell you about an email service. For that, you would use p=none. Your mail won’t get rejected, but you’ll still get reports.

Now we’ve set up the very foundation of email. In the not too distant past, having an MX record was enough, but now that the bad guys’ spoof domains, we need more verification that our mail is coming from a legitimate source. That is really the entire purpose of these records — to allow remote mail servers to trust your email. Having these records properly set up is a near guarantee that your mail gets delivered to the inbox. Not having these records will get you to the spam/junk/quarantine/delete bins.

Microsoft 365 administration: Coming next

In our next article, I’ll demonstrate a couple of essential email policies, using transport rules in Exchange that are absolutely necessary for protecting your users from getting hacked and another that provides them with a very useful tool.

Featured image: Business vector created by Freepik