It is impossible to imagine today’s world without e-mail. Every day, around 250 billion e-mails are sent worldwide, of which approximately 60% are business e-mails and 40% are private e-mails. That means about 2.5 million e-mails per second. E-mail is our biggest communication channel and it doesn’t look like this is going to change in the near future. E-mail is by design also a very unsafe medium. By default, e-mail is susceptible to every conceivable hack, interception, forgery, fraud, etc. To make e-mail a bit safer, there are a number of protocols. From various angles, people try to stimulate the use of these protocols. Governments are obliged from 2020 onwards to use a strict DMARC policy and to implement DANE. But to do this properly, you need to know what these protocols entail. And that… is what you will read in this post!
If you are following my blog, you will know that I have already covered this topic once, in this post. In this post, however, I will discuss DKIM, DMARC and DANE in more detail and SPF in less detail.
SPF, DKIM, DMARC and DANE? All 4 options are (wholly or partly) DNS-based security methods. Let us briefly list them:
SPF – Sender Policy Framework. Goal: reduce SPAM and fraud.
DKIM – DomainKeys Identified Mail. Goal: reduction of SPAM.
DMARC – Domain-based Message Authentication, Reporting and Conformance. Purpose: mitigate spoofing of e-mail.
DANE – DNS-based Authentication of Named Entities. Purpose: enforce cryptographic solutions (STARTTLS).
Although we will mostly focus on DMARC and DANE in this post, it is useful to discuss SPF and DKIM. This way, you will get a complete picture and it will be easy to understand and implement DMARC and DANE.
SPF – Sender Policy Framework
SPF used to stand for “Sender Permitted From” because SPF is primarily intended for the protection of the “From” field. This field allows any e-mail user to send e-mail on behalf of any person. The moment an e-mail server receives an e-mail, it will look in the DNS records of the domain where the e-mail seems to come from. If an SPF record is present, the content will be checked. If the mail server is present in the SPF record, the mail server will mark the received e-mail as SPF PASS. The e-mail will now be allowed through. If the sending e-mail server is not present in the SPF record, the sent e-mail will receive an SPF FAIL. It is then up to the receiving e-mail server (or spam filter) to decide what to do with this e-mail. It is therefore important that companies have their SPF record in order and that all e-mail servers that send e-mail on behalf of the company are included in it. These servers can be specified by name and by IP. When a name is used, a DNS lookup will take place to find the IP address. Make sure that an SPF record does not need more than 10 DNS lookups or it will fail. And beware, when you use “include”, DNS lookups will also take place of domain names in the SPF record of the domain you include here. This way you have no control over the number of lookups and you must be careful not to exceed 10 lookups. Try to avoid “includes” as much as possible.
An SPF record is created in DNS as a TXT record and has the following structure:
“v=spf1 a mx ip4:211.181.40.14 include:_spf.marketingmail.com ~all”
All qualifiers for SPF can be read in my previous blog post (https://jarnobaselier.nl/spf-dkim-dmarc-vechten-tegen-spam-phishing/). The SPF record starts with v=spf1 to indicate that this is an SPF record and ends with a dash (-) FAIL or a tilde (~) SOFTFAIL to indicate how to deal with email that comes from a server that does not comply with the SPF record. It is advisable to make the SPF record as strict as possible and therefore to close it with a dash.