Email at BIT protected against spam and phishing by using DMARC

17-06-2020 11:56:37

If you want to prevent your e-mail from being seen as spam, using authentication tools such as SPF and DKIM is a must. However, email recipients handle this authentication in different ways from each other,
something which decreases their effectiveness. DMARC offers a solution for this. We have recently started using DMARC on top of SPF and DKIM at BIT.

Email is one of the oldest functions of our modern Internet. I am not talking specifically about the 'SMTP' protocol itself, but also about the agreements about "what makes an e-mail", which date back to the
stone age. Meanwhile, email is still extremely popular. For communication with customers, with colleagues, your family or your friends, but also for those who have less sincere intentions.

Unsolicited email, so-called spam, quickly became a major problem. Most people are familiar with news articles which indicate more than 90% of the total amount of email traffic on the Internet is unsolicited e-mail. In addition, an increasing amount of phishing emails were sent and received; messages that appear to come from a bank, the tax authorities or a streaming service, but were actually sent by criminals. In recent years some steps have been taken concerning the 'authenticity' of emails. They improve our ability to check whether an e-mail has actually been sent by the person claiming to be the sender.

SPF, DKIM en DMARC

Terms such as SPF (Sender Policy Framework) and DKIM (Domain Keys Identified Mail) emerged. Just in brief; with SPF you tell "who" can send e-mail on the internet on behalf of your domain and with DKIM you put a digital signature on the "envelope" above each e-mail (the so-called DKIM header).

But what should you do if you receive an email where, for example, all SPF checks are correct, but the DKIM signature turns out to be incorrect, or vice versa? And do you have to do something with that as a
recipient? That's where 'DMARC' comes in. DMARC stands for 'Domain-based Message Authentication, Reporting and Conformance' and builds on the implementation of SPF and DKIM. With DMARC, the owner of a domain, as with SPF and DKIM, can publish in his or her DNS settings what actions to take if one or more of these checks fail.

Is this the holy grail? Will we never receive spam from now on? Unfortunately, that is not the case.

DMARC is not an "anti spam" solution. Cyber criminals are also able to set up DKIM, SPF and DMARC for their spam domains and domains for which no SPF, DKIM or DMARC have been set up, of course, still have to be processed properly. These email standards are not mandatory, although they are on the (Dutch) government's "PTOLU ("Pas Toe Of Leg Uit", Apply Or Explain)" list.

Institutions would do well to implement these standards as the combination of DKIM, SPF and DMARC can help them against criminals impersonating their domain name in email. This can help prevent the
simplest form of phishing emails.

However, proper implementation also requires in-depth knowledge of the email flows within the organization as there is a chance that some unforseen flows will break in the process. In a later blog we will
further discuss the technical implications of setting up SPF, DKIM and DMARC.

Why DMARC now?

BIT has now started with DNSSEC validation; if a company on the internet states that the DNS responses must always be properly secured and this turns out not to be the case, we will not pass on the incorrectly secured answer. We have done the same with SPF; if a company on the internet states that email may only come from certain IP addresses and this is not the case, we will not accept the email. We have also recently started following DMARC policies. This could mean that email is rejected because the DMARC policy is set to "reject", which means something is wrong with regards to SPF or DKIM for the e-mail in question.

Feedback reporting within DMARC

DMARC provides a reporting function, which allows mail server administrators to notify each other about which emails have been rejected from domains and the properties of those emails. BIT has not yet enabled this function because a very large part of the reports cannot yet be delivered to the reporting addresses set in the DMARC records that were tested with. Perhaps a bit ironic, but unfortunately it turns out that the vast majority of the reporting emails are rejected by the recipients. We do keep this data and may send the reports at a later time.

By: Sander Smeenk

Email at BIT protected against spam and phishing by using DMARC