Emails: Technical foundations
Invitations, booking confirmations, reminders, info and thank-you emails – many emails are sent to (potential) attendees as part of an event. And anyone who sends an email naturally wants it to reach the recipient and look just as great as it was designed. Unfortunately, this is not always the case.
To prevent delivery issues or incorrect display of your email, or to respond more effectively to problems, it helps to understand the basic technical functionality of emails. In the following article, we therefore explain the technical basics of emails. We will go step by step through the sending and receiving process. We also explain some authentication methods that you will encounter if you want to send emails via doo with your own sender address.
Glossary
Before we start, we have put together a small glossary with terms that need explanation, which we will use later on.
Email Client/Email Program: The email client is the app you use to read and write emails. This includes, for example, Microsoft Outlook, Apple Mail, Google Gmail, or Mozilla Thunderbird.
Mail Outgoing Server/Mail Incoming Server: A server is a computer that provides services or information to other computers or programs. A mail server sends or receives emails. Especially in large companies, this server can be operated independently by the company. However, the servers are often provided by email service providers, such as Microsoft, Google, or Amazon Web Services (AWS).
Domain: A domain is a unique human-readable address on the internet, for example, doo.net, wikipedia.org, or google.com.
IP Address: An IP address is a unique machine-readable address on the internet. The IP address identifies the server on which the website data or email mailbox is hosted, or from which an email is sent.
Domain Name System (DNS): The DNS is essentially the phone book of the internet. Every URL or email address has a domain, for example, doo.net. The DNS entry for a domain contains the corresponding IP address. When you use a URL or email address, your browser or mail server must first retrieve the IP address from a DNS server before it can send your request to the target server.
DNS MX Record (MX = mail exchange): A DNS entry that assigns the domain to the IP address of the mail incoming server.
Email Header: The header is the top section of an email. In normal email programs, this is not displayed. Only when you open the code of the email do you see the header. The header contains information that is important for sending the email, such as sender and recipient addresses, authentication information for the email, and information on how an email program should display the email.
Deliverability - The Path of an Email to the Recipient's Inbox
Let’s assume you want to send an email to your customer Max as part of an event via doo. For this email to reach Max, a whole series of process steps are necessary. Below, we will take a closer look at this process to understand where problems can occur in the delivery of an email.
Sending the email
You open doo to send an email invitation to your contacts. You have already created the email message, filled in all the details, and set the design and content. You did all this through a visual interface in the doo Email Manager. However, emails are made up of HTML code. Therefore, doo translates your inputs into an HTML code document.
After selecting your recipients, including Max, doo now has a list of email addresses to which the email code must be sent. Now you send the message. The doo outgoing mail server must now send the emails individually to the correct addresses. Let’s look at this using the example of the recipient max@musterfirma.de.
An email address like max@musterfirma.de is human-readable but not machine-readable. Therefore, the domain musterfirma.de must first be translated into an IP address. The outgoing mail server queries a DNS server for the DNS MX record of the domain. With this entry, the server knows where to send the email. If a domain does not exist, for example, due to a typo, there is no DNS entry. Therefore, the outgoing server cannot send the email, resulting in a hard bounce. Otherwise, the email is sent, and the contact is counted as “Sent” in the performance report.
Now the email is routed through the internet to the incoming mail server of the domain musterfirma.de. Even if the email has been sent, it does not necessarily mean it will arrive in Max’s inbox. Therefore, let’s take a closer look at the receiving process.
Receiving the email
The email now reaches the incoming mail server that manages the email inboxes for the domain musterfirma.de. If the incoming server is not reachable, for example, due to a technical failure or overload, it would result in a bounce. Assuming the server is reachable, it does not simply accept the message but first checks whether it is a legitimate email. This is to prevent emails with malicious, harmful, or fraudulent content from reaching Max’s inbox. The server checks several things:
- Authentication
- Reputation
- Content of the email
- Reachability of the address
Authentication of the sender address
Fraudsters repeatedly try to impersonate a sender they are not. To prevent this, the incoming mail server checks the legitimacy of the sender. It tries to determine whether the outgoing mail server is authorized to send for the domain of the sender’s address and whether the content has not been tampered with en route. For this purpose, it queries the DNS server for SPF, DKIM, and DMARC entries for the outgoing server. You may have already encountered these terms if you want to use your own email address as the sender in doo.
SPF stands for Sender Framework Policy. The SPF entry indicates whether an outgoing mail server is authorized to send for the domain of the sender’s address. When setting up your own sender address, you create an SPF entry for doo, declaring that doo’s outgoing server is allowed to send emails on your behalf.
DKIM stands for DomainKeys Identified Mail. To apply DKIM, the outgoing mail server creates a digital signature of the email. It takes a series of data from the email, such as the sender and recipient address, subject, and date. Using a private key, this information is encrypted and included in the email header. The incoming server retrieves the public key from the DKIM entry in the DNS and decrypts the information. This allows it to verify whether the outgoing server had a correct private key and whether the encrypted content has been altered.
DMARC stands for Domain-based Message Authentication Reporting and Conformance. DMARC contains the sender’s instructions on whether SPF and DKIM should be checked strictly or loosely. If SPF and/or DKIM are not met for an email, the DMARC policy also specifies how to handle these emails – whether they should still be delivered, directed to spam, or rejected.
SPF is the most common authentication method. To curb spam and fraud attempts, email providers are increasingly pushing for all three methods to be used. Senders who do not use any or all methods are increasingly being universally rejected or marked as spam by incoming server operators.
Reputation check
In addition to authentication, the incoming mail server also checks the reputation of the outgoing server. It looks to see if the outgoing server appears on blacklists or has a poor reputation. A server ends up on blacklists and gains a bad reputation if too many suspicious emails are sent through it or if too many complaints are registered. For example, a complaint would occur if Max marked your email as spam. You can find a detailed explanation of blacklists, spam, and bounces in our blog article on contact list maintenance in email marketing (Sorry, but this article is only available in German, but thanks to AI, we hope you can easily translate it.).
Email check
The content of the email is also checked by the incoming mail server. If the content is inappropriate or suspicious, the incoming server can mark the email as spam or reject it entirely. What exactly is checked and how it is weighted depends on the recipient’s email service provider, as there are no universal rules. However, there are a few things that are very likely to cause problems. These reasons can include:
- Suspicious “spammy” subject line: Many exclamation marks, certain words like Viagra, or the exclusive use of capital letters trigger spam filters.
- Missing unsubscribe link
- Size of the attachment and/or email content
- Poor image-to-text ratio: If the email consists largely of images and contains little text, this can activate spam filters.
- Suspicious links: For example, links to websites with a poor reputation or links with redirect chains.
- Familiarity of the sender: If the sender is in the recipient’s contacts, this generally increases the likelihood of delivery.
- Links with a different URL in the link description: Especially if link tracking is used for success control, the link description should not consist of the URL of the final target links.
Some email programs have their own spam filters and can still direct an email to spam even if the incoming server allows
Reachability of the Email Address
Through authentication and reputation checks, the sender is verified. However, to deliver an email, the recipient must also be reachable. If this is not the case, a bounce occurs because the email cannot be delivered. Reasons for this include:
- The recipient’s email address does not exist.
- The recipient’s mailbox is full.
- The email mailbox is no longer active or has been blocked.
Email delivery
Based on the checks described above, the incoming mail server now decides whether to direct the message to the recipient’s inbox. If the checks are not passed, the email is either marked as spam or completely rejected. How spam is handled varies and depends on both the operator of the incoming server and the email program and settings of the mailbox. Often, these emails are moved to a spam folder or quarantine area. If an email is completely rejected, it never reaches the recipient’s inbox.
Let’s assume in our example that the email is delivered to Max’s inbox.
Email display
Darstellung der E-Mail in unterschiedlichen E-Mail-Programmen und Versionen
For the email to truly reach the person and not just technically arrive, Max needs to read the email. To do this, he must open it in his inbox.
As mentioned during the sending process, your email is an HTML code document. However, Max wants to see the beautifully designed email, not the email code. Therefore, the code must be converted back into a visual representation. This is the task of the email program that Max uses to open the email. Besides the email program, the device on which the email is opened is also crucial: is it a desktop, a tablet, or a smartphone?
In an ideal world, Max would now see the email exactly as you saw it when you designed it. Unfortunately, this is not always the case. How the email is actually displayed depends on the interaction between the email program, the version of the email program, the device and screen size, the operating system of the device, and user-specific settings.
Device and screen size - Responsiveness of emails
Nowadays, many emails are no longer just opened on PCs but also on mobile devices like tablets or smartphones. The smaller screen sizes create specific requirements for email design. Ideally, you should already ensure that the email looks good on mobile devices during the design process. The responsiveness of an email is crucial for this. A responsive design adapts to the respective screen size. If emails are not mobile-optimized, they may not be readable or only readable with difficulty on a smartphone. The doo email editor is fundamentally designed to create responsive emails. Nevertheless, you should check the mobile display during design, preview, and testing. The editor provides options to set specific settings for larger and smaller screen sizes and to define content that is only displayed on desktop or mobile.
Influence of user-specific settings
User-specific settings can also influence the display of emails:
- Dark mode: Dark mode changes the appearance of your email. Each email program implements dark mode differently, so there is no single way to optimize an email for dark mode.
- Suppressed image loading: Depending on the program and settings, automatic loading of images can be suppressed until it is manually triggered. This means you should consider how your email looks when images are (not yet) loaded.
- Warnings in business mailboxes: Especially in business mailboxes, administrators can enable warnings that are displayed with the email, for example, for unknown senders.
Summary
We’ve seen that there are many factors that can affect the deliverability and display of an email and lead to problems. By being aware of these pitfalls, you can avoid many issues and respond more quickly and effectively if a problem does occur.