“Be strong… to be weak is to invite aggression, oppression, tyranny, misery and woe.”
– Louis Karoniaktajeh
A multi-part series by John Ball, Phillip Kuzma, and Ted Nass on server security.
I’ll be covering a few security topics centered around email in this post. The configuration of many of these technologies is vendor specific, meaning if you use Google Apps for Business then there is a Google-specific implementation and for Office 365 there is a Microsoft-specific implementation. However, these introductions should get you in the right direction and I’ll include some validation tools as well.
DMARC aka RFC7489
Probably the most helpful to setup is Domain-based Authentication, Reporting, And Conformance (or DMARC for short). It works hand-in-hand with Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). DMARC allows administrators of domains to add a specific entry to their DNS records to specify which mechanism (DKIM, SPF, or both) is being used by the domain, how to check the FROM field for senders, how the recipient should handle failures, and how to report these actions. Pretty powerful for just a single DNS entry!
So, how do you set this up? Well, you can create a record manually following the DMARC TXT options here: https://www.dmarcanalyzer.com/how-to-create-a-dmarc-record/. Or the easiest option, for me, was to use DMARC Analyzer to automatically generate my DMARC record then add to my DNS host (Cloudflare). Using the DMARC record generator, I configured my settings which then generated the DNS TXT record for my domain. I would strongly recommend you start with relaxed settings and slowly bring up the security over a period of a few days into a week or two.
From this example you can see my DNS record was generated based on the settings used in the “CONFIGURATION” section. That record is:
v=DMARC1; p=reject; rua=mailto:firstname.lastname@example.org; ruf=mailto:email@example.com; pct=100; sp=reject; adkim=s; aspf=s; fo=0:1:d:s
The next step is adding your record to your public DNS server/hosting provider. I use Cloudflare and the process is really easy. Details here: https://www.dmarcanalyzer.com/dmarc/dmarc-record-setup-guides/dmarc-setup-guide-cloudflare/.
Once you add your DMARC entry to your DNS provider, swing on over and configure your DKIM and SPF records (I’ll talk about that below). Periodically check back in to your DMARC mailbox or, if using DMARC Analyzer or similar service, check the dashboard. I have DKIM and SPF configured so you’ll see the failures in the screenshot. It took about 3 days after setup for failed records to start rolling in. From an administrator’s perspective, this is important to ensure legitimate emails are flowing for your domain. From an information security perspective, this can potentially give you insight into who is attempting to spoof your domain or perhaps an overlooked email sending service.
SPF aka RFC7208
Sender Policy Framework, or SPF, is designed to detect fake spoofed sender addresses by checking the email sending source against authorized servers for your domain. I won’t go into deep technical details on this works because there are many examples available.
In the simplest of terms, SPF, via a DNS entry, allows you to specify which servers are authorized to send email on your behalf. In that DNS entry you can specify strict, permissive, fail, or softfail restrictions. More about SPF qualifiers can be found here: https://www.fraudmarc.com/spf-avoid-overly-permissive-all-terms/.
Let’s say you use Example Domain, an on-premise mail relay server with a public IP at 22.214.171.124, Survey Monkey, and Google to send email and Google Apps is your mail provider. Your SPF record would look something like this:
v=spf1 ip4:126.96.36.199 ip4:188.8.131.52/32 ip4:184.108.40.206/32 ip4:220.127.116.11/32 ip4:18.104.22.168/32 ip4:22.214.171.124/32 ip4:126.96.36.199/32 ip4:188.8.131.52/32 ip4:184.108.40.206/32 include:mail.exampledomain.com include:_spf.google.com ~all
I’ll break it down:
v=spf1 means Sender Policy Framework version 1
ip4: 220.127.116.11 is your on-premise email relay server’s public IP
ip4: 52.xxx.xxx.xxx/32 is the Survey Monkey mail IP blocks
include: mail.exampledomain.com is a domain allowed to send using your domain name
include: _spf.google.com ~all is all of Google’s mail domains for Google Apps senders
Once you get your SPF record created, add it to your DNS hosting provider. Here are Cloudflare’s instructions: https://support.cloudflare.com/hc/en-us/articles/360020991331-Adding-Vendor-specific-DNS-Records-to-Cloudflare.
There are many options available to an email administrator and getting it just right on the first pass is possible. Creating effective records without hindering business process takes some planning and leg work. Combined with a service like DMARC Analyzer, you’ll be able to monitor for potential issues and make changes as needed. Don’t be afraid of SPF. SPF is your friend.
DKIM aka RFC6376
Similar to SPF, DomainKeys Identified Mail (DKIM) is designed to detect forged senders in email. But more than just a simple DNS entry specifying what is and isn’t allowed, DKIM affixes a digital signature to each outbound email linked to an approved sending domain. The receiving email system then verifies the email signature’s public key against a DNS entry containing the public key.
Since DKIM is specific to each domain as it involves public and private key pairs, my simplest recommendation is to visit your hosting provider and follow their instructions. Office 365 instructions and Google Apps instructions are probably the two biggest I can think of at the moment. A headache-reducing tip: Google’s instructions are much easier than Microsoft’s instructions and if you are a non-Google customer I would recommend reading Google’s instruction set first to understand what is happening before trying to wrap your mind around Microsoft’s instruction set.
Once you get your DKIM key pair created it is a simple task of setting up a DNS record in your provider. Here are Cloudflare’s instructions: https://support.cloudflare.com/hc/en-us/articles/360020991331-Adding-Vendor-specific-DNS-Records-to-Cloudflare
SMTP TLS-RPT aka RFC8460
SMTP TLS reporting is new and has only been around since 2018. I won’t go into detail on TLS-RPT as Hardenize’s blog post nails what literally is a single DNS entry for something that is barely being utilized at this point in time.
See their blog post here: https://www.hardenize.com/blog/smtp-tls-reporting-tls-rpt.
MTA-STS aka RFC8461
Another relatively new addition to the mail stack is MTA-STS. Also introduced in 2018, MTA-STS was designed to combat the complexities of public DNSSEC. I have an entire guide around MTA-STS setup (with TLS-RPT) here: https://www.johndball.com/adding-smtp-tls-downgrade-prevention-using-mta-sts/.
Hardenize – https://www.hardenize.com/ – Validates MTA-STS, TLS-RPT, DANE, SPF, DMARC, SMTP TLS, SMTP Certificates, mail servers.
DMARCanalyzer – https://www.dmarcanalyzer.com/spf/checker/ – SPF Record Check
Agari – https://www.agari.com/insights/tools/dkim/ – DKIM validator
GSuite Toolbox – https://toolbox.googleapps.com/apps/checkmx/ – MX check w/DKIM selector