DNS settings to pay attention to when hosting email

Tech-nerd alert ⚠️ issued for this post!

Back in the days, if someone asked me to set up an email service. My response was: “Thanks, but no thank you.” I preferred not to take on the task. I’m good. And honestly it REALLY was a hassle! While that still holds somewhat true, with new DNS settings for email. And especially the DKIM, DMARC and SPF records makes it at least doable nowadays. But what are these strange ” records”, it do not sound as any Beatles songs I know?! These records are DNS settings and they mean everything for security. If you grab a cup of ☕, I will explain them in detail for you.

MX – The basics

You can start by setting up an MX (mail exchange) record. The MX record directs email to a mail server. And indicates how email messages should be routed. In the early days of internet 1985-1990 the MX was invented and adopted. MX follows the Simple Mail Transfer Protocol (SMTP, the standard protocol for all email). And it looks like this:

example.com	record type	priority	value	TTL
@	MX	10	mail1.example.com	45000
@	MX	20	mail2.example.com	45000

@ just means that it is the root-domain (example.com), priority is the order they should be used where 10 is the preferred domain in this case.

SPF – First line of defense

SPF is short for Sender Policy Framework (do not confuse with Sun Protection Formula in this context). The record was adopted in the early to middle of 2000. And it informs a receiving email server about the origin of any legitimate email service for your domain. the protection is also known as spoof protection. This means that if you add third party senders you trust in the list. Only then the third party server will be allowed to send emails as if they come from your service. This is great if you want to use email services as Sendgrid or MailPoet. The record is on the root domain and looks like this in its purest form:

v=spf1 ~all

The v stands for version. In this case, it is spf1. There has never been a v2 to date (that I’m aware of). the ~ sign is a qualifier. There are 3 more signs that you are allowed to use.

+	PASS	Can be omitted (ip4: is the same ass +ip4:)
?	NEUTRAL or NONE	No policy
~	SOFTFAIL	a debugging aid between NEUTRAL and FAIL.
–	FAIL	The mail should be rejected

We should harden this record so that it makes more sense. Lets add some ipv4 A records:

Hardening

v=spf1 ip4:192.0.2.0/24 ip4:198.198.198.198 a -all

Now only IP addresses in the 192.0.2.0/24 range and the specific 198.198.198.198 are allowed as senders. We can also use a and aaaa (ipv6) record as well! the -all is just saying anything else is not allowed. If you have a domain, the MX record is the easiest to use.

v=spf1 ip4:192.0.2.0/24 ip4:198.198.198.198 a mx -all

Considerations

Please make sure to be mindful here though. Because there is a limitation of 10 lookup:s. And yes, email servers need to look up DNS records. Both “mx” and “a” will do one or more lookup. The ip4 ip6 and all directive do not need any lookup.

DKIM – Sign emails through DNS

Email header

Just as when you sign a document, a proper DNS setup can sign the origin of emails. Ensuring the email comes from their server. Basically it’s added to the email-header and also works as a spoof protector. A private-public key-pair is used to validate origin. There are a lot of tags to use with an email DKIM-Signature: header field:

v (required), version
a (required), signing algorithm
d (required), Signing Domain Identifier (SDID)
s (required), selector
c (optional), canonicalization algorithm(s) for header and body
q (optional), default query method
i (optional), Agent or User Identifier (AUID)
t (recommended), signature timestamp
x (recommended), expire time
l (optional), body length
h (required), header fields – list of those that have been signed
z (optional), header fields – copy of selected header fields and values
bh (required), body hash
b (required), signature of headers and body

When we publish a DKIM we need to consider the selector. When the receiving SMTP server wants to verify. It uses the domain name and the selector to do a DNS lookup. With the d tag that gives the author domain to be verified against (example.net). The s tag is the selector. But the string _domainkey is a fixed part of the specification. This gives the TXT resource record to be looked up as:

selector._domainkey.example.net

The actual DNS record

And this is how an actual DKIM DNS record looks:

"k=rsa; t=s; p=PIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDmzRmJRQxLEuyYiyMg4suA2Sy
MwR5MGHpP9diNT1hRiwUd/mZp1wo7kIDTKS8ttkI6z6eTRW9e9dDOxzSxNuXmhme60Cjbu08gOyhPG3
GfWdg7QkdN6kR4V75MFlw624VY35DaXBvnlTJTgRg/EW72O1DiYVThkyCgpSYS8nmEQIDAbAB"

There are more tags than k t p to consider for a DKIM (DomainKey Identified Mail) DNS setting:

v (recommended), version (default DKIM1, must be the first tag if present)
h (optional), acceptable hash algorithms (default all)
k (optional), key type (default rsa)
n (optional), human-readable administrator notes
p (required), public key data (base64 encoded, or empty if the public key has been revoked)
s (optional), service type (default *, else email)
t (optional), toggle flags (colon-separated list, default none, may include y for testing DKIM without rejecting failed signature verifications, and/or s which is recommended for subdomain strictness as explained in the RFC)

Its not the sexiest of DNS settings but it is a great tool to further prevent email spoofing!

DMARC – The glue

Domain-based Message Authentication, Reporting and Conformance (DMARC). Great to shorten that sentence, but these shorts are getting out of control! Anyway, DMARC extends SPF and DKIM by specifying how to check the From: field presented to end users. And it also defines how the receiver should deal with failures. Furthermore, it provides a reporting mechanism for actions performed under those policies. With origins recorded in RFC 7489,^[1] dated March 2015, my opinion is that this is the savior of sanity!

DMARC records are published in DNS with a subdomain label _dmarc, for example _dmarc.example.com. Compare this to SPF at root domain example.com, and DKIM at selector._domainkey.example.com.

A DMARC looks something like this:

v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:dmarcreports@example.com;

The v stands for version, p is policy sp subdomain policy and np no domain policy, there are 3 different polices to use here:

none No special treatment is required by receivers, but enables a domain to receive feedback reports.
quarantine asks receivers to treat messages that fail DMARC check with suspicion. Receivers use their own implementation for the handling when DMARC fails. It can be flagged message or deliver in the spam folder.
reject asks receivers to reject messages that fail.

The rua:mailto tag is indicating that the email address dmarcreports@example.com wants to have aggregated reports about the rules. And this is great if your domain gets targeted as spam sender. And ruf is the same but for forensics reports. There are even more things to consider. I assure you that taking these steps is a good start. This is your pathway to a spam-free email hosting setup.