Being new to the world of email is a daunting thing. I should know. When I joined SparkPost, I knew nothing of the nuances that make email move from sender to inbox. Don’t get me wrong, I knew about SMTP, POP3, and how email moved through the internet. That is the theory of sending email. The practice is far more nuanced. Hopefully, sharing my experience will help you, my fellow developers.
Sending an email through software is generally a trivial task for a software developer. Creating a successful email communication system that allows your organization to effectively engage with an application’s users takes more effort and knowledge, but with a little planning the process can be fairly painless.
Email deliverability is not an exact science. It is a delicate balancing act between many factors in a changing environment. The best practice is for a sender to attempt to balance the scale in their favor by doing the things that we know are good while attempting to avoid the bad. The goal is to ensure that your organization will send email that lands in the recipient’s inbox.
This series will help guide you through the various subjects that you need to know in order to to implement email as a developer. It is a not a comprehensive guide, but it should point you to all the areas that are important for successfully implementing email messaging in an application.
Once we know what sort of email we plan to send, we need to think about what that volume will look like over time. When you are setting up an email service, you will need to think not only about your typical monthly volume of email, but also about the possibility of provisioning burst capacity to accommodate occasional increases in volume.. These estimations should account for the average activity of each day broken down by hour. Weekly and monthly estimations should also be made if you know there will be certain days of the week or month that you send special mailings.
Successfully sending email is all about your organization’s reputation. The content of the email you send is important, but it is a secondary factor to your organization’s email history. Before you start establishing an email reputation, there are some basic factors that the inbox providers look at for determining if you are a serious sender or just a fly-by-night spammer.
The IP addresses of the email servers that send your email is the most basic and oldest method used for establishing and maintaining the reputation of an email sender. SparkPost allows our customers the option of sending email out of a shared pool of IP addresses. Your email will be sent from the same IP addresses as other customers’ email. If your email volume is small, this can make your email more affordable and reduce the complexity of your infrastructure.
SparkPost does allow customers to purchase dedicated IP addresses as well. If you purchase a dedicated IP address, your email will be the only messaging sent on that email address. This allows you to establish and maintain your own IP reputation. If you’re concerned about being able to closely manage your IP reputation, a dedicated IP will give you that control.
If you chose a dedicated IP, you will need to implement an IP warm up plan to start establishing your reputation as a sender before getting to your planned full volume of sending. IP reputation becomes stale and degrades over time which means that if you allow the volume to decrease too much on an IP, you will need to repeat the warm-up process.
The Return-Path domain, also known as the RFC5321. From domain, bounce domain, or Mail From domain, is the way that receiving email servers can provide feedback, known as bounces, to the sending server. SparkPost handles configuration of the Return-Path for our customers, and provides the handling and reporting of bounces automatically.
The Sending Domain, also called the RFC5322. FromDomain, is the part of the email address after the local part, meaning what is after the @ symbol. It is this domain that the user sees in their mail client: From: Awesome Organization firstname.lastname@example.org. There are several mechanisms that are in place that inbox providers, spam filters, and mail clients use to verify that your Sending Domain and email are legitimate.
The Sender Policy Framework (SPF) is a method of validating that a message really originated from your organization. SPF uses a DNS TXT record to set rules that validate that mail comes from a domain authorized by your organization.
The DomainKeys Identified Mail (DKIM) signature allows your organization to take responsibility for the actual message that is sent. DKIM uses private-public key pairs to sign each message with a unique cryptographic signature. If the message is modified in transit, the cryptographic signature will not validate. As long as your organization’s private keys remain secure, no one can spoof messages from your organization, as the DKIM signature would fail validation.
All of these components make up the best way to insure and validate your organization’s reputation: Domain-based Message Authentication, Reporting, and Conformance (DMARC). Although it is not an authentication protocol, DMARC allows your organization to establish and manage trust with your recipients. The reporting portion of DMARC is critical in allowing your organization to actively manage its reputation.
Inbox providers may use one or all of these factors as part of their methods for evaluating email. Your reputation as an email sender will take time to establish and requires vigilance to maintain. The easiest way to protect your sending reputation is to set up and maintain SPF, DKIM, and DMARC.
The most critical aspect to successful email communication is insuring that the people you’re sending to actually want your email. Determining how you will generate and manage your mailing lists is critical to define early on. The number one cause of problems for organizations new to email is using poorly formed or managed lists. These can result in a high number of spam complaints, which means inbox providers could throttle delivery or outright refuse to accept your email.
There are some very basic precautions that you can take in creating and managing lists. Most importantly, your users need to double opt-in for email. Double opt-in is where users sign up for your emails, then confirm via a link that you emailed to them. Double opt-in reduces the chances of unintentional signups and helps ensure compliance with anti-spam laws found in many countries. Later we will talk about how to further improve list management through feedback loops and unsubscribes.
We have laid the groundwork for starting to plan an email implementation based on best practices. So, dig deeper into the above email basics and start planning how you’re going to bring email to your application.
In our next installment, we will build on the topics here to start developing an email platform MVP.
This post was originally posted on SparkPost.