DMARC (Domain-based Message Authentication, Reporting & Conformance) is an email authentication protocol, which includes a reporting function that allows domain owners to improve the protection of the domain from spoofing attacks and monitor the domain’s email activities.
DMARC leverages the existing email authentication techniques SPF (Sender Policy Framework) and DKIM (Domain Keys Identified Mail). These techniques help in email authentication. DMARC record setup helps the domain owner to identify the policy (e.g., do nothing, quarantine the message, or reject it). The recipient will be able to apply the policy on emails failing the DMARC authentication. However, there are prerequisites:
Domain owners (Senders) need to implement email authentication protocols and publish DMARC policies on public DNS.
Email receivers need to implement email verification mechanism for authentication protocols.
1. When an email is sent by the domain (or someone spoofing the domain), the recipient mail server checks to see if the domain has a DMARC record.
2. The recipient mail server then performs DKIM and SPF authentication and alignment test to evaluate three key factors of the message:
Is the message’s DKIM signature valid?
Is the email received from a registered IP addresses in the sending domain’s SPF records?
Is the message’s headers pass domain alignment tests?
3. With this information, the server is ready to apply the sending domain’s DMARC policy to decide whether to accept, reject, or quarantine the email.
4. Lastly, the receiving mail server will send a report on the outcome of this message and all other messages they see from the same domain. These reports called DMARC Reports. These reports are sent to the email address specified in the domain's DMARC record. There are two types of DMARC reports; Aggregate (RUA) and Forensic (RUF) reports:
Aggregate DMARC reports (RUA)
Sent on a daily basis
Provides an overview of email traffic
Includes all IP addresses that have attempted to transmit email to a receiver using original domain name
Forensic DMARC reports (RUF)
Only sent for failures
Includes original message headers
May include the original message
Inventory of all email senders using the valid email domain.
Detect misconfigurations of SPF and DKIM records.
Provides insights and reports on all email domain activity.
Control the emails that fail in authentication with a policy to apply (none, quarantine, reject).
Increase email deliverability.
Protect against spoofing emails.
DMARC is powerful, but there are also some misunderstandings about DMARC:
There is a wide range of email attacks that need to be prevented such as phishing and spam emails with malicious attachments. It is important to note that DMARC is designed to protect against emails that appear to be originated from a trusted domain, where in fact they are spoofed emails. DMARC does not inspect the content of the attachment to verify its integrity. Thus, implementing DMARC protocol does not mean that the email is 100% protected, but it adds a security layer against spoofing email attacks.
Some entities want to stop spoofed emails that using their domain immediately by placing a DMARC record and enforcing this to a 100% p=reject policy. This is indeed effective to block spoofing attacks immediately; however, this will also lead to legitimate email being lost. NCA advices to start with a p=none policy and to monitor the results, adjust SPF and DKIM authentication accordingly, and then enforce the policy.
DMARC is not designed to protect the inbound part of the email traffic; DMARC protects the outbound part of the email traffic. However, DMARC can be effective on the inbound email traffic only if the sending domains has DMARC authentication on their side.
It is important to note that a DMARC policy instructs to handle the emails according to the DMARC policy, but email receivers are not obligated to take the DMARC policy into account. Email receivers sometimes use their own local policy. This means that an email failing the DMARC checks can land into the inbox of the receiver, even when enforced the DMARC policy reject.
The Sender Policy Framework (SPF) is an email-authentication technique, so that the domain owners can provide a list of authenticated sending servers on their public DNS and when a receiving email server sees an email from their domains, it crosschecks the sender’s IP address with the list provided in the public DNS. SPF is one of the authentication techniques on which DMARC based on. DMARC uses the result of the SPF checks and add a check on the alignment of the domains to determine its results.
SPF is a great technique to add authentication to emails. However, it has some limitations, which need to be considered:
SPF does not validate the "From" header but uses the "envelope from" to determine the sending domain. This "From" header is shown in most clients as the actual sender of the message.
SPF authentication will fail when an email is forwarded. At this point, the 'forwarder' becomes the new 'sender' of the message and will fail the SPF checks performed by the new destination.
SPF lacks reporting which makes it harder to maintain.
SPF by itself is still effective, but cybercriminals have come up with ways to bypass the IP address verification phase. However, SPF technology became relevant again by incorporating it into DMARC.
DKIM (Domain Keys Identified Mail) is an email authentication technique that allows the receiver to check if the received email was authorized by the domain owner. This is achieved by adding a digital signature to the header of the email.
Implementing the DKIM standard will improve email deliverability. If DKIM record is used along with DMARC (and even SPF), it will provide protection against malicious emails sent on behalf of the domain.
DKIM relies on cryptography, allowing senders to generate a pair of keys (Public and Private), which are used to "sign" emails. The PUBLIC KEY is published in public DNS and the PRIVATE KEY is kept on the sender mail server.
The sender mail server creates a hash value for the outgoing email then encrypt that hash value with private key and add the encrypted hash value (DKIM signature) to the message’s header.
After receiving the email, the receiver can verify the DKIM signature using the public key registered in the DNS. It uses that key to decrypt the DKIM signatures in the header to get the hash value created by the sender and recalculate the hash value from the email received. If these two hash values matches, the recipient Email Gateway knows that the email has not been altered. This gives the user a confirmation that the email was actually sent from the domain owner.