Email is the wild wild west of the internet. Anyone can send email as another person, which is one of the reasons that we have junk email. One of the ways 
that companies can help others ensure that emails are coming from where they claim to be coming from, is to set up outbound email security. This involves setting a few DNS records in the DNS domain for that company. When the emails are then received by the receiving email server, it checks these DNS records against the email that was just received to see if the email was sent from an SMTP server that is listed in the DNS record.
There’s a couple of different records that need to be created. The first is called an SPF record. This record is a text record at the root of the domain.
To add this in, you first need to know what servers will be sending emails for your domain. In the case of DCAC, we use Office 365 as well as SendGrid, QuickBooks Online, and MailChimp.
SPF
This all needs to be added to our SPF record so that emails sent by any of these services are marked as valid from an SPF perspective.
We use the record below.
v=spf1 ip4:206.154.105.0/24 ip4:199.16.139.0/24 ip4:206.108.40.0/24 include:spf.protection.outlook.com include:servers.mcsv.net include:sendgrid.net ~all
Version
Let me explain how this specific record works. The “v=spf1” part says that this is SPF version 1. If version 2 of SPF comes out, then this would need to be changed to that.
QuickBooks Online
The “ip4:206.154.105.0/24 ip4:199.16.139.0/24 ip4:206.108.40.0/24” section is the SPF section for QuickBooks Online. QuickBooks Online uses a bunch of outbound email servers, and they are all contained within the three subnets listed.
Office 365
The “include:spf.protection.outlook.com” section is the SPF section for Office 365. This section says that any emails that are sent from Office 365’s outbound email servers are valid. As Office 365 will send all emails from severs that come back to that DNS name, this marks all the records as valid; and since you can’t send email through Office 365 without authenticating, we can trust this setup.
MailChimp
The “include:servers.mcsv.net” section is the SPF section for MailChimp. Again, since you can’t send email as someone else’s domain without verifying that it’s your domain, we can trust this setup.
SendGrid
The “include:sendgrid.net” section is the SPG section for SendGrid. Again, since you can’t send email as someone else’s domain without verifying that it’s your domain, we can trust this setup.
All
The final part is the “~all” section of the record. This covers everything else. The values within the SPF record are processed in the order listed. So if the email is sent through another email server that isn’t listed, then it’s processed by the “all” record. The “~” before “all” says that an email that matches “all” will be marked as a soft failure. There are a few values that can be used instead of the “~”. You can use a “+” which means that all emails will pass SPF checking, you probably don’t want this as unauthorized emails would be marked as valid.
You can use a “-” which means that all emails will fail SPF checking if they match “all”. The “~” which we use means that any emails that match “all” are given a soft failure. Eventually, we’ll change this from “~” to “-“.
The final value you can use is “?” which means that anything which matches “all” is given a match of Neutral. This is the same as not having “all” and tells the receiving server that the email isn’t from a valid server, but it shouldn’t fail it either. It means to ignore SPF and do other checking and use that to decide if it’s junk email or not.
DKIM
After you set up SPF, you will want to set up DKIM. This is another set of DNS records that need to be created. Your email provider will give you the values that you need to put in place. Since we use Office 365, we need to set up DKIM in Office 365.
To create this in Office 365 (where DCAC hosts its email), the first thing you need to do is to connect to Office 365 in PowerShell. This is done using a simple bit of code that you can run in PowerShell. You’ll need to run the PowerShell window in Admin mode.
Set-ExecutionPolicy RemoteSigned
$UserCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
Import-PSSession $Session -DisableNameChecking
Once you run that, it’ll prompt you for a username and password. Enter the username and password of your account that has admin rights within your O365 environment. Keep in mind that if you have MFA enabled (which you should have), this code won’t work. You’ll need to bypass MFA for your public IP address for this to work.
Once you get logged in to O365, you need to enable DKIM for the domain. Turning on DKIM is done using a PowerShell command, which you’ll want to run in the same window as above. You may receive an error saying that this object already exists. If you get this error message back, just ignore it the error.
New-DkimSigningConfig -DomainName {your domain} -enabled $false
Once that is done, you’ll want to ask O365 what the DNS setting for your domain should be. You get these settings using the PowerShell code below.
Get-DkimSigningConfig -Identity {your domain} | fl Selector1CNAME, Selector2CNAME
This will give you back two records. They will look something like this.
Selector1CNAME : selector1-{your domain}._domainkey.dcassoc.onmicrosoft.com
Selector2CNAME : selector2-{your domain}._domainkey.dcassoc.onmicrosoft.com
Take these values and create two new DNS entries for these. These will both be CNAME records. The first will be called “selector1._domainkey”, and it has the value that’s returned as Selector1CNAME. The second will be called “selector2._domainkey”, and it has the value that’s returned as Selector2CNAME.
The final command that needs to be run is to enable DKIM for this domain.
Set-DkimSigningConfig -Identity {your domain} -Enabled $true
DMARC
Once this is done, that’s most of what needs to be setup. The final think to be setup is called DMARC.
The setup DMARC, you need to create another DNS record. This is a TEXT record with the name of “_dmarc” (yes, there’s an underscore in front of the name). This record tells receiving email servers to send reports to someone about your SPF and DKIM settings about how many emails they get for each of these settings, and if emails fail these checks what should be done with the emails.
Our record looks something like this.
v=DMARC1; p=none; rua=mailto:{email address}; ruf=mailto:{email address}; fo=1; pct=100;
Let’s dive into what these various settings mean.
Version
The “v=DMARC1” section simply means the version of DMARC that we are using. Currently (in 2020), only version 1 is in use, so we use DMARC1 as the version.
Response
The “p=none” tells that receiving server what to do with emails that fail SPF and DKIM check. Currently, we are using a value of none here. The options are quarantine or reject. If you set “p=quarantine”, then emails that fail SPF or DKIM checks will be sent to quarantine (the junk folder in Outlook). If you set “p=reject”, then the receiving server will reject emails that fail SPF or DKIM checks. The standard process that most companies do is start with a value of none. After the reports are reviewed, then the p-value is moved to quarantine and then finely reject.
RUA
The rua value is an email address that feedback on the status of emails is sent to. This feedback is an XML file that is either zipped or gzipped.
RUF
The ruf values is an email address that forensic reports will be sent to.
Report Options
The “fo=1” section tells the receiver what options to use when sending the reports. A value of “0” will generate reports if both DKIM and SPF fail. A value of “1” will generate reports if either DKIM or SPF fails to produce a DMARC pass result. A value of “d” to generate a report if DKIM has failed, or a value of “s” if only SPF failed.
Percent
The final section is “pct=100”, which tells the receiving server what percent of emails should be included in the report. 100 percent is all emails, 50 is half the emails, etc. The bigger the company, and the more emails that you send out, the lower the setting should be. As we’re a small company that doesn’t send a massive number of emails, we want the inspection and reports for all emails that we send out.
What’s Reported On
As users find out about this reporting, they could start getting nervous about the admins getting reports on what emails they are sending out. These reports only look at the headers and do not include any of the data within the actual email.
Viewing the Reports
The reports that are sent because of DMARC settings are not meant to be read by people. They are XML files, and they are pretty complex. The easiest way to read them is to use a service. We use DMARC Analyzer to view the data. This gives some nice reports that summarize the data that gets sent back.
Conclusion
Hopefully, this will help people get their email servers properly secured. If you’re looking to get into a nice secure email platform, contact the sales team at DCAC, and our team can help you get setup in Office 365.
Denny
