DMARC benefits businesses by providing another layer of protection that guards against attacks like impersonation or email fraud.
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 supports businesses by adding a layer of protection that prevents attacks like impersonation fraud, where an attacker uses a legitimate domain to send a fraudulent message.
A DMARC record is a DNS TXT record published in a domain’s DNS database that tells the receiving email server 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. 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).
An example of a DMARC TXT record:
v=DMARC1; p=none; rua=mailto:example@example.com; 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 three 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 are:
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).
The reject policy: p=reject. Besides sending DMARC reports, the DMARC policy 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.
A DMARC report is a feedback report sent by participating mailbox providers to the domain owner after they evaluate messages against that domain’s DMARC policy. Its purpose is to show how email claiming to come from your domain is being authenticated and whether those messages are passing or failing a DMARC check.
This is often the first step in confirming whether your domain is publishing a valid policy and whether messages are aligning correctly. Organizations can use a DMARC record checker to validate their DNS record, review syntax, and spot publishing errors before they affect enforcement.
Most organizations rely on aggregate reports, which provide a summarized view of email activity, including sending sources, sending IP addresses, SPF and DKIM results, and alignment outcomes. These reports help identify legitimate senders, detect unauthorized use of your domain, and spot configuration issues that may affect enforcement or deliverability.
If you are building a new policy from scratch, a DMARC record generator can also help create a properly formatted record before you publish it to DNS.
Sending a fraudulent email from a legitimate domain is one of the techniques used by cyber criminals 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, cyber criminals 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.
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.
Discover how Mimecast’s single platform can protect your people, AI, and data.
See how Mimecast protects your people, AI, and data in a single platform.
GlossaryEmail & Collaboration Security
GlossaryEmail & Collaboration Security
GlossaryEmail & Collaboration Security
