While email authentication protocols may appear complex and technical, they provide a crucial standardization framework. Email marketers can appreciate the convenience of adhering to a unified set of protocols across various mailbox providers, sparing them from the burden of navigating diverse authentication requirements.
Now, let’s delve deeper into the four pillars of email authentication: SPF, DKIM, DMARC, and BIMI.
SPF
The Sender Policy Framework, commonly known as SPF, stands as an email authentication protocol designed to specify which IP addresses or hostnames are authorized to send emails on behalf of a particular domain.
Implemented as a DNS TXT entry, SPF allows the receiving mail server to verify the legitimacy of an email purporting to originate from a specific domain by cross-referencing the sending IP address with the authorized entries in the SPF record. This verification process involves the receiving server querying the DNS records to retrieve rules associated with the bounce or return-path domain, subsequently comparing them with the entries in the SPF record to validate the correspondence.
Failure to implement SPF significantly heightens the risk of messages being flagged as spam by mailbox providers.
In some instances, Email Service Providers (ESPs) handle SPF implementation automatically by furnishing both the IP address and the return path. However, for senders dispatching a high volume of emails, opting for a dedicated IP address is preferable to maintain control over sender reputation. It’s important to note that in the case of shared IP addresses, updating the SPF record may become necessary when transitioning between ESPs.
One drawback of SPF is its ineffectiveness in scenarios involving email forwarding. Instances where emails are forwarded pose a challenge as SPF validation may fail, potentially preventing messages from reaching recipients beyond the sender’s immediate list. This limitation is particularly pertinent for brands relying heavily on email word-of-mouth strategies, where forwarding plays a significant role in message dissemination.
DKIM
DomainKeys Identified Mail, abbreviated as DKIM, marks the culmination of efforts to combat email forgery by merging two pioneering methods developed in 2004: Yahoo’s “DomainKeys” and Cisco’s “Identified Internet Mail.”
DKIM operates by incorporating an encrypted key, termed a digital signature, into email headers to facilitate sender verification and establish a link between a message and its originating domain. This digital signature must be configured within the sender’s DNS record.
Conceptually, DKIM functions as a unique watermark or fingerprint specific to each email sender. Unlike SPF, DKIM signatures remain effective even when emails are forwarded.
At the core of DKIM lies a pair of keys essential for its operation. Administrators generate both a public key, which resides within the DNS record, and a private key utilized by mail servers during the transmission process to authenticate the email’s origin. The private key functions as the DKIM signature embedded within the email header.
Upon receipt, the receiving mail server employs the digital signature to ascertain the location of the public key for authentication purposes. Subsequently, the public key is utilized to validate the encrypted key within the DKIM signature, establishing a definitive connection between the email and the sending domain where the public key is housed.
Despite the robust security measures implemented by DKIM, there remains a possibility for hackers to compromise DKIM keys and exploit them for sender impersonation. To mitigate this risk, it is advisable to periodically change DKIM keys, typically several times per year.
An article published on CircleID.com in 2015 highlighted concerns about certain Email Service Providers (ESPs) sharing DKIM signatures among multiple customers. This practice poses significant risks, as a compromised digital signature could potentially affect numerous companies simultaneously. While it’s hoped that such issues have since been addressed and rectified, it’s prudent for senders to inquire with their ESPs regarding their DKIM practices.
If you’re tasked with generating your own digital signature, DKIM generators are available to streamline the process of creating email authentication records. Additionally, our blog offers valuable insights into DKIM signatures, along with an example record, to aid in your understanding and implementation of this essential email authentication protocol.
DMARC (Domain-based Message Authentication, Reporting, and Conformance)
DMARC, short for Domain-based Message Authentication, Reporting, and Conformance, owes its inception to PayPal, which spearheaded the development of this technology to enhance existing email authentication methods. PayPal, a frequent target of cybercriminals employing fake emails for impersonation, collaborated with other prominent brands and major mailbox providers to introduce DMARC.
Unlike traditional email authentication protocols, DMARC functions not as a standalone protocol but rather as a policy that receiving mail servers consult before delivering an email. Serving as a pivotal determinant of message handling in the event of authentication failures, DMARC policies are published as DNS records.
This policy, also referred to as Domain-based Message Authentication, Reporting, and Conformance, serves as a framework specifying whether a sending domain utilizes SPF, DKIM, or both authentication protocols. DMARC is often lauded for harmonizing SPF and DKIM, leveraging both protocols within a common framework to maximize efficacy.
Given the potential repercussions of erroneously blocking legitimate emails, DMARC offers a nuanced approach to handling authentication failures. Recognizing that genuine emails may occasionally fail DKIM and SPF authentication for various reasons, mailbox providers may opt to deliver such messages if they appear to originate from a legitimate sending domain. DMARC provides clarity in such scenarios by delineating specific actions to take.
DMARC policies afford senders the flexibility to establish a framework outlining their email authentication methods and dictating the treatment of messages that run afoul of the policy. Domain owners can choose from three options to specify the handling of emails failing DMARC validation:
[1] None: No specific action is taken.
[2] Quarantine: Suspicious emails are routed to the recipient’s spam or junk folder.
[3] Reject: Emails failing DMARC validation are outright rejected, preventing delivery to the recipient’s inbox.
Indeed, while a DMARC policy that outright rejects unvalidated emails represents the strongest stance against unauthorized senders, it also comes with potential risks. In scenarios where SPF and DKIM authentication failures occur, implementing a DMARC policy that rejects such emails could result in legitimate emails from the domain being halted as well.
This situation arises because DMARC policies mandate strict adherence to authentication protocols. If SPF and DKIM authentication processes fail for any reason, even legitimate emails may be subject to rejection under a DMARC policy set to “reject.” Consequently, email flow from the affected domain may be disrupted, impacting communication with recipients.
Given this potential drawback, domain owners must exercise caution and consider the implications before implementing a DMARC policy with a “reject” action. It’s essential to balance the need for stringent security measures with the risk of inadvertently blocking legitimate emails. Depending on the organization’s risk tolerance and operational requirements, alternative DMARC policy actions such as “quarantine” or “none” may offer more flexibility while still providing a degree of protection against unauthorized senders.
Implementing a DMARC policy offers several benefits, including the receipt of regular DMARC reports. These reports provide valuable insights such as:
* Identification of servers and third parties sending emails on behalf of the specified domain.
* Percentage of emails successfully passing DMARC authentication.
* Details on servers or third parties sending emails that fail DMARC validation.
* Actions taken by receiving mail servers on unauthenticated emails.
Despite its advantages, DMARC is not without its limitations. Similar to SPF, DMARC can encounter issues with email forwarding, and its setup may pose challenges for senders. Moreover, concerns regarding the potential disruption of legitimate email flow often discourage the adoption of stringent DMARC policies.
However, successfully implementing a DMARC policy can serve as an effective deterrent against phishing attempts that seek to impersonate the sending domain.
As of 2024, Gmail and Yahoo have introduced new requirements mandating the use of DMARC alongside SPF and DKIM for bulk senders. While a DMARC policy of “p=none” is currently acceptable, this is considered the minimum standard. The ultimate goal for mailbox providers is to encourage broader adoption of DMARC. Eventually, an enforced DMARC policy of either “p=reject” or “p=quarantine” will be required.
It’s important to note that while a DMARC policy of “p=none” is permitted at present, it may not suffice in the future. However, according to Marcel Becker of Yahoo, enforcing DMARC is advantageous for all stakeholders involved—mailbox providers, senders, and email recipients alike—making it a win-win-win situation.
BIMI
BIMI, the newest addition to the email authentication suite, operates differently from its counterparts SPF, DKIM, and DMARC. Unlike Gmail and Yahoo’s requirements for the implementation of SPF, DKIM, and DMARC, there’s no mandate for senders to adopt BIMI. Rather, BIMI serves as an incentive for organizations to embrace robust email authentication protocols.
BIMI stands for Brand Indicators for Message Identification. Its unique feature is its visual impact on subscribers’ inboxes. When correctly implemented, BIMI displays a branded logo designated by the organization next to its messages in the inbox.
This logo serves as a tangible indicator of trustworthiness. Its presence signifies that the email has passed through stringent authentication checks, including other email authentication protocols. Consequently, subscribers can rely on the displayed logo as an assurance of authenticity.
The significance of the BIMI logo lies in its ability to instill trust. Even if malicious actors succeed in delivering phishing emails, the absence of the verified logo signals to recipients that the email may not be legitimate. Thus, BIMI adds an extra layer of confidence for subscribers, bolstering trust in the authenticity of emails they receive.
To qualify for mailbox providers to display a BIMI logo, it’s imperative to have a fully operational DMARC policy along with SPF and DKIM records set up. BIMI serves as a culmination of sorts, rewarding organizations for their commitment to other email authentication methods.
Similar to other authentication protocols, BIMI is managed through a TXT record linked to a domain’s DNS. However, before incorporating a BIMI record, it’s essential to ensure the existence of a properly formatted logo.
BIMI logos must adhere to specific criteria to be compatible. They should be SVG files in the shape of a perfect square, capable of being cropped into a circle. Additionally, they require a solid background and must be published via HTTPS. Moreover, BIMI logo files should be compact, not exceeding 32kb in size. Lastly, to meet standards, the logo must be a registered trademark.
The journey towards BIMI adoption gained momentum when Google initiated a Gmail pilot program for BIMI in 2020. Subsequently, in July 2021, Gmail officially rolled out full support for BIMI. Additionally, in 2023, Apple announced its support for BIMI logos within its Apple Mail client, starting with iOS 16. This development holds significant implications, considering the substantial user base of Gmail and Apple Mail. It underscores the value of investing time and effort into setting up email authentication protocols.
By implementing BIMI, organizations can enhance subscriber confidence in the authenticity of their emails. For further guidance, resources, and tools related to BIMI, visit BIMIGroup.org. Additionally, gain insights from experts in the field by participating in our Ask Me Anything (AMA) session on Brand Indicators for Message Identification.
Conclusion
Should you use all 4 authentication protocols?
Absolutely, using all email authentication protocols is highly recommended.
In the realm of email authentication, the adage “two heads are better than one” perfectly encapsulates the synergy between SPF and DKIM. Likewise, adding DMARC to the mix amplifies the effectiveness of these protocols, akin to the notion that “three is the magic number.”
As previously mentioned, DMARC serves as a crucial component for maximizing the benefits of SPF and DKIM, as well as enabling the display of a BIMI logo. Thus, a comprehensive approach that incorporates all authentication protocols ensures optimal email security and integrity.
While the setup process may require time and effort, the investment is undeniably worthwhile, particularly for organizations with the necessary resources. However, it’s important to note that email marketers need not navigate the intricacies of authentication protocols alone. Collaboration with IT teams or individuals possessing technical expertise is often essential for configuring DNS records effectively. Additionally, involvement from Email Service Providers (ESPs) may be necessary, while support from colleagues, vendors, or security consultants can aid in troubleshooting any issues that arise during the setup process.
In summary, leveraging all email authentication protocols is vital for bolstering email security and ensuring deliverability. With the right support and resources, email marketers can successfully implement robust authentication methods to safeguard their email communications.
