If you are a bulk email sender, authentication is a vital component of your email marketing and essential to get right. Without it, you run the risk of high bounces and emails going straight to the junk folder, if they get to the recipient at all.
Setting up email authentication is a technical process and requires access to systems outside of the TouchBasePro system. If terms like TXT records, CNAME records, TTL settings, and public-private keys aren't familiar to you, ask someone in your IT team to help you.
The three major techniques for authentication are SPF, DKIM and DMARC. In this help document, we’ll break down what each of those is used for and how to implement it correctly.
Sender Policy Framework, or SPF, is a domain-based method of determining what IP addresses are allowed to send email on your behalf. SPF allows the receiver to check that email claiming to have come from a specific domain comes from an IP address that has been authorised by the domain’s administrator.
The SPF record is a TXT record in your domain’s DNS. It starts with v=spf and what follows is a list of domains that you allow to send emails for you.
For example, if you are sending from touchbasepro, you’ll have the following record:
v=spf1 include:touchbasepro.email ~all
You can only have one SPF record. If you already have an existing SPF record, you can add extra IP ranges to it with extra include: statements. If you’re not sure, it’s best to reach out to your IT team or domain administrator as having two or more SPF records will invalidate all of them.
DomainKeys Identified Mail, known as DKIM, checks the message content using digital signatures and verifies that it has not been altered. Rather than using digital certificates, the keys for signature-verification are distributed via DNS. This counteracts forged sender addresses (spoofing) and allows the receiver to check that an email claiming to have come from a specific domain was authorised by the owner of that domain and not altered in transit.
The DKIM record is a pair of records, the private key sits with the sender you are authenticating with (e.g. TouchBasePro) and the other half is the public key in your domain’s DNS. This can either be as a CNAME record, or as a TXT record that contains a selector, the word domainkey and your domain. This record combination ensures that each outgoing message is digitally signed.
If you haven't authenticated your sending domain with DKIM, some email clients will flag your emails as coming from a different server. This can potentially cause them to be blocked, or lead subscribers to believe they're receiving spam.
Domain-based Message Authentication, Reporting & Conformance, shortened to DMARC, combines both SPF and DKIM into one standard. It is designed to give email domain owners the ability to protect their domain from unauthorised use by allowing domain owners to publish a policy in their DNS that specifies which mechanism (SPF, DKIM or both) is employed on that domain, how the recipient should deal with an email that doesn’t pass the specified authentication, and a reporting mechanism for failures.
A DMARC record is published in a domain’s DNS as a TXT record. It will start with v=DMARC1 and what follows is the set of instructions on how to handle an email from that domain if it doesn’t align with either SPF, DKIM, or both.
There are three levels of DMARC policies, and jumping straight to the strictest level can have unintended side effects on legitimate emails and affect your entire email ecosystem. The three policies are: do nothing (none), send it to junk/spam (quarantine) or block it entirely (reject).
The industry standard for email verification is to implement all three methods above. SPF guarantees that the server that sent this email is authorised, DKIM guarantees that the email sender and contents are legitimate and haven’t been altered in any way, and DMARC shows your domain is trustworthy and secure, as well as providing full visibility and control over all email that claims to come from your company.