DMARC History: Why SPF and DKIM Weren’t Sufficing
DMARC is driven by the authentication results of SPF and DKIM to prevent fraudulent emails sent from your domain from showing up in the primary inboxes of victims. The protocol was developed to minimize the likelihood of someone falling into the trap and sharing sensitive details or sending money to hackers; so, if the recipient is not seeing the email in the first place (because it’s either in the spam folder or has bounced back) then what are the odds of them opening it and getting exploited.
The genesis of DMARC dates back to 2010, when 15 tech biggies came together to build a technology that could shield domains and business owners against phishing and spoofing attacks attempted in their name. Let’s dive into knowing about the DMARC’s journey briefly.
SPF and DKIM: The Foundation Stones of DMARC
SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) were already in play when the need for a better technology was felt. SPF works on the principles of allowlisting, where messages sent from authorized sources are placed in the primary inboxes, and the ones dispatched from unauthorized sources are either marked as spam or rejected.
DKIM uses a cryptographically protected pair of public and private keys to verify a sender’s authenticity and inform the recipient if a message’s content has been played with in transit.
SPF’s Birth
SPF was developed in the early years of the 2000s when Paul Vixie publicly mentioned a protocol that could verify a sender’s authenticity to minimize the likelihood of phishing attacks. It was the time when the limitations of the SMTP (Simple Mail Transfer Protocol) were being felt as it wasn’t serving the purpose of email security well.
During its initial phase, the full form of SPF was Sender Permitted Form, which was later changed to what we know today as Sender Policy Framework.
The current form of SPF works by asking domain owners to enlist all the authorized sending sources in the TXT form in an SPF record, along with instructions for recipients on how to handle illegitimate messages sent from their domain. You can direct recipients’ mailboxes to mark illegitimate messages as suspicious and place them in the spam folder or reject their entry altogether, which also means email bounce-back.
However, SPF still has some shortcomings, like it breaks if a message is forwarded, which means the authentication process either comes to an end or goes haywire altogether.
DKIM’s Birth
DKIM was structured and introduced after SPF out of necessity to have a protocol in place that would work with forwarded emails and verify if a message’s content was not tampered with in transit. It was built by combining Cisco’s Identified Internet Mail (IIM) and Yahoo’s DomainKeys, hence the name DomainKeys Identified Mail.
Cisco’s IIM adds cryptographic signatures to an outgoing email so as to verify if it’s sent from authorized and legitimate sending sources or not. This basically indicates if a malicious actor has tried to squeeze themselves into a company’s email system and tried sending a phishing email or not. This verification process is done at the receiver’s end and involves Mail Transfer Agents (MTAs) or Mail User Agents (MUAs).
On the other hand, Yahoo’s DomainKeys ensures a message’s content hasn’t been altered in transit. The methodology revolves around rapid assessments using a binary “yes or no” method, directing emails either to the spam folder or the inbox. It’s based on signatures and originally utilized a key pair; public and private keys.
Gmail, Fastmail, AOL, and Yahoo were among the first few users of DKIM, and its adoption grew swiftly over the years.
DMARC’s Journey
Here’s a breakdown of DMARC’s genesis and journey-
2010-2012-The Ideation and Development Years
The insufficiency of SPF and DKIM led to the development of DMARC in 2010 when 15 organizations, including PayPal, Microsoft, Yahoo, and Google, joined hands to contribute their expertise and resources towards building a protocol that could bar phishing attempts.
The primary aim was to enable email recipients’ mail servers to send feedback to senders’ domains on the authentication status of messages. This would help them fine-tune and adjust their email security practices. Its first specification came out on January 30th, 2012.
2012-2017- The Years of Slow Adoption
Not many IT and cybersecurity experts were aware of DMARC’s existence, which led to a rather slow adoption over the next 5 years. Later, in 2015 and 2016, Google and Yahoo made some strict email security policies, including the adoption of DMARC so that businesses could be impelled to deploy email authentication protocols.
The reasons behind its slow adoption were the lack of stricter and mandatory policies and the shortage of cybersecurity experts proficient in the deployment, management, monitoring, reporting, and troubleshooting of SPF, DKIM, and DMARC.
2018 and onwards
The legislative and judiciary branches were behind private organizations in terms of DMARC adoption, but the scenario has changed significantly. In fact, in the UK, it’s compulsory for all government services to be DMARC compliant.
In 2020, the total number of valid DMARC policies observed in the DNS rose by 42.9% to reach 2.7 million. The DNS now hosts a total of 3.46 million valid DMARC policies, marking a 28% increase in the first half of 2021. In fact, Google and Yahoo are now pushing DMARC adoption for bulk emailing and have set February 2024 as the deadline.
