DMARC (Domain-based Message Authentication, Reporting & Conformance) is an email authentication protocol designed to protect your organization's email domain from being used in email spoofing.
Email spoofing is often used for social engineering attacks like business email compromise attacks, phishing or spear phishing emails, emails scams and other cyber attacks.
How Does DMARC Work?
DMARC leverages the existing authentication techniques, Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM), DMARC adds reporting and guidance about whether to accept unauthenticated emails, send them to the spam folder or outright reject them.
Once a domain owner publishes a DMARC record in their DNS records, they can gain insight into who is sending emails on behalf of their domain. This information can be used to understand if any fraudulent email is being sent and allows email senders and receivers to determine the authenticity of an email.
While not all receiving mail servers perform a DMARC check, it is becoming increasingly common and is supported by most popular email providers.
How Does SPF and DKIM Work?
SPF checks if the IP address of the sending server is authorized by the owner of the domain that appears in the SMTP MAIL FROM command.
DKIM allows parts of emails to be cryptographically signed, and the signature must cover the from field. Within the DKIM-Signature mail header, the d= (domain) and s= (selector) tags specify where in the DNS to retrieve the public key for the signature. A valid signature proves the signer is a domain owner and the from field hasn't been modified since the signature was applied.
What is in a DMARC Record?
It's best to walk through an example DMARC record, let's use UpGuard's:
v=DMARC1;p=none;fo=1:d:s;rua=mailto:dmarc@upguard.com;ruf=mailto:dmarc@upguard.com;adkim=s;aspf=r
The first part v=DMARC1 is the identifier the receiving email server looks for when scanning the DNS record for the domain name it received the email from. If the domain does not have a txt record that begins with V=DMARC1, it will not run a DMARC check.
p=none tells the receiving server what to do with messages that fail DMARC. In UpGuard's case, the policy is set to none. This tells the receiving server to take no action if a message fails DMARC but it can still be valuable for the sender because DMARC sends reports to alter the domain owner of any DMARC failures.
It is generally recommended to deploy DMARC in "monitor mode" to collect data from participating receivers. Once the data shows legitimate emails are passing authentication checks, you can change the DMARC policy to request that failing messages are quarantined (p=quarantine) or even rejected (p=reject).
The next part fo is forensic reporting options. "1" generates a report if any mechanism fails, "d" generates a report if DKIM signature fails to verify and "s" generates reports if SPF fails. The other option is "0" which only generates reports if all underlying authentication fails.
rua=mailto:dmarc@upguard.com tells the receiving server where to send aggregate reports of DMARC failures. These reports are sent on a daily basis and include high level information about DMARC failures rather than specific details about each incident. This can be any email address you choose.
ruf=mailto:dmarc@upguard.com tells the receiving server where to send forensic reports of DMARC failures. Forensic reports are sent in real-time and contain details about each individual failure. Unlike rua, ruf relies on the email address provided being the part of the same domain as the DMARC record is published for.
adkim=s sets strict DKIM alignment meaning that the DKIM portion of DMARC authentication only passes if the d= field in the DKIM-Signature exactly matches the from domain. It can also be set to relaxed "r" that passes the DKIM authentication portion of DMARC authentication if the DKIM d= field matches the root domain of the from address.
aspf=r sets relaxed SPF alignment meaning the SPF portion of DMARC will pass if the from header shares a common organizational domain. It can also be set to strict "s" which requires exact matching between the SPF record domain and an email's from header.
Other mechanisms can be included in the DMARC record including:
- rf: tells the receiving server what kind of reporting the policyholder wants
- pct: tells the receiving server how much of their mail should be subjected to DMARC policy's specifications
- sp: Tells the receiving server whether or not to apply the DMARC policy to sub domains.
Why is DMARC Important?
DMARC is important because it helps end users and email providers differentiate between legitimate and illegitimate email messages by providing information about which emails to deliver and which should be sent to spam or outright rejected.
Organizations are often targets of phishing, spear phishing or other social engineering campaigns that represent significant cybersecurity risk.
Several methods have been introduced to identify these cyber threats however:
- The mechanisms work in isolation
- Each receiver makes unique decisions about how to evaluate results
- The legitimate domain owner never gets feedback
DMARC attempts to coordinate these methods to:
- Allow domain owners to signal they are using email authentication (SPF and DKIM), provide an email address to gather feedback about emails from their domain (legitimate and illegitimate) and provide a policy to apply to emails that fail authentication (report, quarantine, reject).
- Allow email receivers to be certain a given sending domain is using email authentication, evaluate SPF and DKIM along with what the end user sees in their inbox, determine the domain owner's preference for emails that fail authentication and provide the domain owner with feedback about emails using their domain.
Cyber criminals may use email spoofing as part of a larger cyber attack, e.g. a data breach of sensitive data like protected health information (PHI) and personally identifiable information (PII).
Alongside authentication, DMARC can be configured to report unauthorized activity which can assist in digital forensics and IP attribution.
What are the Benefits of DMARC?
- Publishing a DMARC record protects your organization's reputation and brand by preventing unauthenticated parties from spoofing your domain, it can even improve the deliverability of your emails by improving your email reputation.
- DMARC reports can increase the visibility of your email security program by providing information about who is sending email from your domain.
- Establishes a consistent policy for dealing with messages that fail to authenticate, improving global cyber resilience and cyber security.
Does DMARC Prevent Phishing?
DMARC prevents phishing that relies on email spoofing. For example, if the owners of example.com use DMARC to protect their domain, it would do nothing to prevent phishing campaigns sent from example.net
That said, email spoofing is a common attack vector. However, it's important to understand that DMARC does not address typosquatting (sending from a domain that is similar to the target domain e.g. example.com vs exampIe.com) or display name abuse (modifying the "From" field).
What is the History of DMARC?
Email authentication technologies SPF and DKIM were developed over a decade ago to provide greater assurance of the identity of the sender of an email. While adoption of SPF and DKIM has steadily increased the problem of deceptive and fraudulent emails hasn't abated.
While it was thought that email receivers would easily be able to differentiate fraudulent emails from the ones properly authenticated, it did not work out that way for a number of reasons:
- Senders have a complex email environment with many systems sending email, often including third-party vendors. Ensuring each email can be authenticated using SPF and DKIM is complex, particularly when environments are in flux.
- Domain owners can send mixed messages some of which can be authenticated and email receivers are forced to discern between legitimate and fraudulent messages that can't authenticate. Spam algorithms are error prone and constantly evolving to respond to changing tactics of phishers and spammers, this results in some fraudulent emails reaching inboxes.
- Senders receive poor feedback on email authentication deployments. Without emails bouncing, there is no way to determine how many legitimate emails are being sent but not authenticated or even the scope of email spoofing of the sender's domain. This makes troubleshooting email authentication hard and even harder in complex email environments.
- Even if a sender is able to verify all legitimate emails are authenticated, email receivers are wary to reject unauthenticated emails because some legitimate messages may be unsigned.
This led to DMARC, which allows senders and receivers to share information with each other. Receivers can supply senders with information about their email authentication structure while senders can tell receivers what to do with unauthenticated messages.
In 2007, PayPal worked closely with Yahoo! Mail and later Gmail to build out this approach.
By 2012, the first DMARC specification was published to help prevent email spoofing.
And in March 2015, the IETF RFC Editor published RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC) on the Independent Submission Stream and it is in the process of being adopted as the official input to the IETF DMARC Working Group.
Today, DMARC specification is worked on by many industry leaders:
- Receivers: AOL, Comcast, Google, Netease, Microsoft, Yahoo, Mail.Ru, XS4ALL and Yandex
- Senders: American Greetings, Bank of America, Facebook, Fidelity Investments, LinkedIn, PayPal, JPMorgan Chase and Twitter
- Intermediaries and vendors: DMARC Analyzer, Valimail, Agari, EasyDMARC, Cloudmark, Netcraft, Mailreport, ReturnPath, Redsift OnDMARC, Trusted Domain Project and Symantec
What are Common DMARC Misunderstandings?
With DMARC, organizations can avoid ransomware and other types of malware delivered through phishing emails and increase email deliverability.
DMARC won't fix deliverability instantly. While placing a DMARC record (and enforcing it) helps improve the security of your email channel and helps emails land in the primary inbox of the receiver, it's not a guarantee.
Another common mistake is to set DMARC to a reject policy. This can be a good move if your organization is dealing with phishing and email spoofing. However, it can also lead to legitimate emails being blocked. It's often better to use the quarantine or none options and monitor for failures.
The big mistake many organizations make is only monitoring their own DMARC presence. The mitigation of third-party risk and fourth-party risk should be part of your overall information security, data security and network security. If your third-party vendors are processing sensitive data, personally identifiable information (PII) or protected health information (PHI) you need to be monitoring them for DMARC.
Otherwise, attackers may use email spoofing on their domains to target your organization leading to data breaches and malware infections. Invest in vendor risk management and develop a robust third-party risk assessment framework and cyber security risk assessment process.
Look for vendors with SOC 2 assurance, ask to see their information security policy and think about information risk management holistically.
How UpGuard Can Help You Monitor You and Your Vendors for DMARC
UpGuard Vendor Risk can minimize the amount of time your organization spends managing third-party relationships by automating vendor questionnaires and continuously monitoring your vendors' security posture over time while benchmarking them against their industry.
Each vendor is rated against 50+ criteria such as presence of SSL and DNSSEC, as well as risk of domain hijacking, man-in-the-middle attacks and email spoofing for phishing.
To measure your risk of suffering a data breach, click here to request your free security score now!
