Learn more about the DMARC authentication standard, and how Mimecast uses DMARC, SPF and DKIM to protect against malware and targeted cyberattacks.
Anyone involved in email security today is likely familiar with the DMARC standard and its role in helping to secure email from threats like spam, phishing and email spoofing. But what is DMARC exactly, and how does it add another layer of security to business email systems?
DMARC is Domain-based Message Authentication, Reporting and Conformance, a technical standard that helps protect email senders and recipients from advanced threats that can be the source of an email data breach. DMARC email security provides a way for domain owners to outline their authentication practices and specify the actions to be taken when an email fails authentication. DMARC also provides a way for recipients to report on email that fails authentication.
DMARC benefits businesses by providing another layer of protection that guards against attacks like impersonation fraud, where an attacker uses a legitimate domain to send a fraudulent message.
Now lets get into some of the specifics of DMARC.
Sending a fraudulent email from a legitimate domain is one of the techniques used by cybercriminals to trick users into divulging sensitive information or wiring money to fraudulent accounts. DMARC email security protocols can help to prevent this specific type of attack by allowing senders to notify recipients that their messages are protected by SPF and/or DKIM authentication and providing instructions for what to do if an email passes neither one of those authentication methods. Essentially, DMARC email security takes the guesswork out of the way that receivers handle failed messages, minimizing the recipient's exposure to potentially fraudulent email and helping to protect the sender's domain from being used fraudulently.
While DMARC email security can be highly effective at stopping a particular kind of attack, cybercriminals are very adept at finding many ways of breaching an organization's security. That's why so many companies turn to Mimecast for solutions that combine DMARC email security with other highly effective and multilayered defenses.
Sender Policy Framework, or SPF, is an email validation protocol used to verify the legitimacy of a sender's domain by defining which IP addresses are allowed to send email from a specific domain. DMARC is an authentication protocol that builds on the SPF standard and enables domain owners to specify how email should be handled when it fails authentication.
DomainKeys Identified Mail (DKIM) is another authentication protocol that allows a sender to digitally sign an email with the organization's domain name, ensuring the message's authenticity. As with SPF, DMARC builds on the DKIM standard by enabling senders to say how messages that fail authentication should be treated.
DMARC is a protocol for authenticating that an email sent from an organization's domain is a legitimate message and not fraudulent.
A DMARC record appears in the sending organization's DNS database. Published as text (TXT) resource records (RR), DMARC records specify what the recipient of an email should do with mail that fails authentication.
DMARC domain alignment is part of the DMARC compliance and validation process. For SPF, domain alignment requires that a message's From domain and its Return-Path domain must be the same. For DKIM, domain alignment means that the From domain and a message's DKIM signature must be a match.
Learn more about the DMARC authentication standard, and how Mimecast uses DMARC, SPF and DKIM to provide advanced malware protection from impersonation fraud and other targeted attacks.
A DMARC record is a DNS TXT record published in a domain’s DNS database that tells receiving mail servers what to do with messages that don’t align or authenticate with SPF and DKIM. The DMARC record enables reports to be sent back to the domain owner about which messages are authenticating and why.
All DMARC rulesets are specified in the DMARC record. A DMARC record enables email sending organizations to inform ISPs (like Gmail, Microsoft, Yahoo! etc.) whether a domain has implemented DMARC.
A DMARC record is published in the DNS as a TXT record and the TXT record name can be set as “_dmarc.yourdomain.com.” where “yourdomain.com” is replaced with the organization’s actual domain name (or subdomain).
DMARC TXT record example:
v=DMARC1; p=none; rua=mailto:firstname.lastname@example.org; ruf=mailto:example@ example.com; fo=1;
The DMARC policy instructs email receivers how to process emails that they receive and is also published in the DMARC record. When deploying DMARC there are 3 policies available that can be published to eventually work towards an enforced reject policy that instructs email receiving systems to only accept legitimate messages.
Available DMARC policies:
Monitor policy: p=none
The none (monitoring only) policy: p=none. This policy enables organizations to instruct email receiving systems to send DMARC reports to the address published in the RUA or RUF tag of the DMARC record. The monitoring only policy helps to gain insights on an email channel as it provides information on who is sending email on behalf of a domain. The p=none policy will not affect the email deliverability.
Quarantine policy: p=quarantine
The quarantine policy: p=quarantine. Besides sending DMARC reports, the quarantine policy instructs email receiving systems to deliver email that are not DMARC compliant into the spam folder. Enforcing the p=quarantine policy will mitigate the impact of spoofing although spoofed emails will still be delivered to the receiver (spam folder).
Reject policy: p=reject
The reject policy: p=reject. Besides sending DMARC reports, the DMARC policy reject instructs email receiving systems to reject all (malicious) messages that are not DMARC compliant and to deliver all DMARC compliant emails into the primary inbox.
This enforced DMARC policy significantly mitigates the impact and risk of spoofing.
DMARC enables an organization to publish policies to its DNS record that define its practices for email authentication and provides instructions for receiving mail servers about how to enforce them. Essentially, DMARC helps receiving mail servers determine if an incoming message “aligns” with what is known about the sender, and how to handle messages that don’t align.
Specifically, DMARC enables receiving mail servers to check for alignment between the “header from” domain name and the “envelope from” domain name that is used during SPF authentication, and alignment between the “header from” domain name with the “d= domain name” in the DKIM signature.
If a message fails both SPF and DKIM authentication and alignment, receiving mail servers can check the sender’s DMARC email security policy to decide whether to accept, block or quarantine the email message. DMARC also reports the outcome of this decision back to the sending domain owner, providing clearer insight into messages sent from the domain.
Benefits of implementing DMARC email security include:
DMARC can help to successfully prevent direct domain spoofing, where attackers use an organization’s exact domain name in the “from” address within an email. However, DMARC cannot prevent look-alike domain spoofing, where attackers use a domain name that is a slightly altered version of a legitimate domain. Also, DMARC cannot prevent display name spoofing, where the name of the sender appears to be a trusted contact even though the underlying “from” email address may not be legitimate. And DMARC can’t provide protection against newly registered domains that are often used to initiate attacks for several hours or days before being shut down. For these reasons, most organizations opt for a multilayered approach to email security that uses DMARC in association with a variety of other defenses.