Email is widely used not only for business and personal communications, but also by automatic systems that send you notifications and reminders triggered by your online activity. However, email is surprisingly vulnerable to impersonation attacks and online fraud. The origin of its vulnerability is that the information displayed in the “from” and “to” addresses are not necessarily where the email actually came from and who originated it.
Several attempts have been made over the years to validate that the person who sent an email is who they say they are. More recently a protocol called DMARC has been created to give a clear answer to the validation question.
DMARC (Domain-based Message Authentication, Reporting & Conformance) uses two previously defined protocols SPF and DKIM and allows domain owners to explicitly tell the receiving email server what to do with an email that fails an authentication attempt.
SPF is one of the earliest attempts to validate email communications. It’s based on a record published in the sender’s DNS and it contains the domains and IPs of the services that are authorised to send emails on behalf of a particular domain. The receiving email server looks at the domain in the address stated in the return path field of the email, then goes to the DNS of that domain and looks at the SPF record, if the originating IP address matches one of the IP addresses within the DNS record then SPF passes.
The main problem with SPF is that it validates the domain in the return path which is not visible to the user through the most common email clients. A user could be seeing a SPF valid email with a “From” address from a trusted source, which was not originated at that source.
If SPF is implemented on it’s own, without DMARC, it only gives a signal to the receiving server and doesn’t block emails from being delivered to the end user. At most it increases the spam score of an email. This is not enough if the email is a fraud attack.
DKIM is a more recent standard and more complex than SPF. It’s functionality is based on a cryptographic signature of parts of the email with a two part key, one part is stored in the email metadata, and the other part is published in the DNS record of the sender’s domain.
The main problem with DKIM is that the signing domain stated in the key within the email could be different than the one in the from header. A user could be seeing a validly signed email with a “From” address from a trusted source, which was not signed by that source.
Similarly as with SPF, DKIM validation can pass or fail and the receiving email server then decides what to do, since DKIM is well used but not mandatory in all emails, receiving servers don’t block unsigned or DKIM non-validated emails. This is not enough if the email is a fraud attack.
Domain-based Message Authentication, Reporting & Conformance
DMARC uses the validation results from both SPF and DKIM and verifies the domain names against the From address in the email. If either validation is successful and the domain name aligns then the DMARC validation result is pass.
In addition, DMARC can explicitly tell the receiving server what to do with an email if both SPF and DKIM fail. This policy is stated in the DMARC DNS record:
Nothing. This is stated in the parameter
p=none. It means that the receiving email server is not instructed to take action regarding an email that fails DMARC. This policy is regularly the initial state of any domain that wants to implement their DMARC policy and even though it doesn’t block fraudulent emails it allows domain owners to enable reporting, which is useful to understand a domain’s email traffic and make sure its configuration includes all the valid email services.
Quarantine. Tells the receiving email server to send any emails that fail DMARC validation to the user’s spam folder.
Reject. Tells the receiving email server to actively reject any emails that fail DMARC validation. Such emails get rejected and never reach the email account of the intended receiving user. This policy is recommended to effectively block cyber attacks that start with email impersonation.
Finally, DMARC has also a provision to report all the validation attempts. An email address can be specified in the DMARC record and the receiving server can send reports that include information like the IP address of the origin of an email. This is particularly helpful to understand the frequency and quantity of unauthorised email.
Implementing DMARC can be a bit complex for several reasons:
The majority of organisations use additional services to send emails on their behalf. If those services are not properly identified in their configuration they could fail.
The DMARC reports contain vasts amounts of data that needs to be converted in insights and actions.
It can be difficult to implement your blocking policy p=reject without blocking any valid email services.
That’s why we created OnDMARC. It’s a cloud service that understands your current traffic and gives you step by step recommendations to implement and maintain your DMARC policy giving you a clear and quick path to full rejection of invalid email.
OnDMARC’s reporting system highlights specific traffic that domain owners can verify as valid or not. Spikes in traffic from a particular source are highlighted and can be triaged as coming from a fraudulent source or from a new messaging system, allowing users to easily update their configuration.