Email has become integral to our lives, allowing us to communicate efficiently and effectively. It’s simple to use and all around us - at work, home, and on the move.
Email communication and its smooth operation are crucial for the functioning of every business, regardless of its size or industry.
Because we all use email daily, email may seem straightforward at first glance. However, behind the simple act of emailing lies a complex ecosystem involving many nuts and bolts, such as domain authentication, DNS records, and compliance with various protocols, labeled under the mysterious word “deliverability.”
These components ensure that emails reach their intended recipients’ inboxes and maintain the sender’s integrity and reputation.
The foundation of email deliverability lies in the technical setup of the email infrastructure. Upon that foundation are several building blocks, including “domain authentication.” With the new sender’s guidelines, domain authentication is now mandatory, and it verifies that the email sender is authorized to send emails on behalf of that domain. Domain authentication relies on protocols two protocols, SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail), and appropriate records in the domain's DNS. On top of those two protocols, DMARC (Domain-based Message Authentication, Reporting, and Conformance) helps protect domains and brands against email spoofing and phishing attempts. Another protocol that depends on the previous three protocols is BIMI (Brand Indicators for Message Identification) -- it’s the brand’s logo that acts as a modern wax seal (usually with a VMC certificate) to provide recipients with visual proof of the authenticity of the sender logo and domain.
For email users, the smooth operation of email communication involves just clicking the send button. However, it relies on a sophisticated yet delicate infrastructure that ensures emails are delivered reliably and securely.
The (Non) Learning Organization
Despite the importance of email to organizations, I see this among IT personnel in companies, startups, and enterprise organizations. Companies lack internal processes and procedures related to managing organizational email infrastructures. For example, if the marketing department starts working with a new ESP, marketing automation, or CRM, they simply notify the IT about updating records that need to be made in the DNS. Usually, there are no procedures in the IT department regarding recording and revalidating this information after a period of time, to ensure it’s still relevant and that the records are needed in the DNS.
The DNS Challenge
DNS is a crucial component of every business. In many businesses, the domain registrar manages their domain’s DNS, meaning management remains with the registrar (GoDaddy or Namecheap, etc.). However, most times, the DNS can be (and should be) managed separately from the domain registrar, but the management is done externally with another service: web hosting.
It is recommended that the DNS be managed separately for security and redundancy purposes. To achieve this, the domain owner can set the Name Server records (NS records) at the domain registrar and direct the DNS management to an external service.
CloudFlare is a secure, well-propagated DNS server with over 12,500 networks (Nodes) worldwide, and it is fast and free. It also has an exciting feature that can help the IT people organize the DNS mess: a comment line can be added to each record that explains the purpose of that line in the DNS and who in the organization requested its definition. You can also create a tag for each record.
The SPF Challenge
IT personnel in the organization sometimes make errors, such as adding multiple SPF records or using outdated SPF records in the DNS. Another concern is that SPF authentication could be compromised for specific email platforms if the IT department does not monitor DNS records and their relevance. This is because the SPF record may exceed the permitted limit of up to ten DNS lookups, causing some email platforms to fail to authenticate SPF. While there are solutions for this issue, allowing outdated platforms poses a security risk and is a liability for the organization.
The DKIM Challenge
Another example relates to the DKIM record (an additional protocol for domain authentication). Some organizations implemented DKIM a few years ago with a size of 1024K (or even 512K). In contrast, today, because of security considerations, it is advisable to implement a record of size 2048K.
For security reasons, it is also recommended that the DKIM record be replaced (rotated) from time to time. It’s not always clear who handles DKIM Rotation. Is the rotation performed by the ESP or by the organization itself?
Many organizations overlook these significant matters and are often unaware that this will become an increasingly significant problem as time passes and the organization accumulates more email platforms (or other platforms that send emails on behalf of the organizational domain).
The DMARC Challenge
Before the “new sender’s guidelines” (Yahoogle), senders could send well-authenticated emails without having a DMARC record. One of the few new things in the “new sender’s guidelines” is that DMARC has become mandatory. If you look at the typical recommended DMARC record, almost every ESP recommends this record: V=DMARC1; p=none. This is a useless record because it missed the email address for receiving DMARC reports (no RUA tag). Even if there is an email address in the DMARC record, it is often an email address inside the organization that no one checks, or if someone monitors it, the reports are in XML format and difficult to interpret without a DMARC monitoring tool.
The goal of DMARC is to protect the brand and the domain. For this purpose, one must go through the “DMARC journey” from p=none through p=quarantine to (preferably) p=reject.
DMARC reports serve as a discovery mechanism that allows revealing all the platforms sending emails on behalf of a domain. This reveals infrastructures that no one inside the organization remembers exists, but which still send email on behalf of the organization’s domain, like old development servers or legacy systems. Some are no longer relevant and can be deprecated (removing records from the DNS), and some require fixing the authentication and alignment.
I sometimes see DMARC records in reject mode without a reporting address (without RUA), and it is clear that since there is no reporting, no one has undertaken the DMARC journey.
Deliverability issues often arise in these organizations because the sending infrastructures were not properly defined. In addition, the receiving servers in the domain’s DMARC record were instructed to quarantine or reject emails from the organizational domain if there was a problem with authentication or alignment.
DMARC reports can provide interesting insights. The image above shows an e-commerce brand that sends around 60 million monthly emails. This indicates that the brand can send emails from multiple dedicated IP addresses, but DMARC reports reveal they use a shared pool provided by their ESP.
This client already achieves pleasing results this way, but in such a business, any improvement, even the smallest, can be reflected in an improved bottom line.