Authenticating your emails using SPF, DKIM and DMARC

Email: it may seem like a simple thing, but it keeps any organization running smoothly. Although it was used only by a niche crowd at its inception, now, owing to its reliability, it has taken its rightful place in everyone's workspace.

Despite using emails every day, many of us know little about how email delivery really works. Right after you click "Send," a series of verification protocols come into play to ensure that your emails reach the intended inbox.

If you own a business, particularly an online venture, the importance of these protocols becomes even more pronounced when you have to send transactional emails. These emails are not only essential and time-sensitive, they should be automated. For these emails to reach their intended destination, your sender reputation must be high—meaning your IP address and domain can be trusted to not send spam emails. You can achieve this by legitimizing your domain by adding the SPF, DKIM, and DMARC records to your DNS server. These records will provide credibility to the domain and tell the receiving server that you are trustworthy.

Let's take a look at each of these records to see how they help improve your email deliverability.

SPF:

The Sender Policy Framework (SPF) is an anti-spoofing method by which the receiving server is made aware of all the servers that can send emails on your behalf. By adding this record, you provide a public list of the servers that can send emails for you.

Why add an SPF record?

Although adding an SPF record is not mandatory, doing so will improve your credibility. This way, the receiving server will know that your domain is trustworthy and this increases the chances of your email reaching your clients promptly. This in turn will improve your sender reputation and your delivery rate.

How SPF works

A typical SPF record in ZeptoMail looks like this:

v=spf1 include:zeptomail.net ~all

This is a TXT record, meaning the record contains human-readable text information. You should publish this record in your domain's DNS server, which is a public repository that can be accessed by all servers.

An SPF record contains the following parts:

• V=spf1

        This tag specifies the version of the SPF record and it should be placed In the beginning.

• Include

        This is used to specify the authorized servers that can send emails on your behalf. You can combine multiple server names in the include tag. For example,         you can include zylker.com and zeptomail.net as: V=spf1 include:zeptomail.net include:zylker.com ~all.

•  All

        This tag comes at the end of the SPF record.

   -all - all of the unspecified IPs are not authorized and they will be rejected.

  ~all - the unspecified IPs are marked as soft fail, meaning, the server will accept the mail, but it will be marked as an SPF fail.

  +all - all of the IP addresses are authorized. Thus, when the incoming server receives an email, it checks the SPF records for the authorized servers. If the sending server is mentioned in the SPF record of the domain, the emails will pass the SPF check. Otherwise, the necessary action will be performed based on the "all" tag.

DKIM:

While SPF is used to allow only authorized servers to send emails, the Domain Keys Identified Mail (DKIM) method ensures your email’s contents are not modified in transit.

Why use DKIM?

DKIM protects you against phishing and spoofing attacks, so even if someone tries to masquerade as you, they will not be able to send emails to your clients. Like SPF, DKIM keeps your emails from being redirected into spam folders, thus improving your IP reputation and deliverability.

How DKIM works

When you send an email, the contents are converted to a hash value—a set of strings or a signature and it is sent along with the email. This hash value is encrypted using a private key. This key will be stored in the server sending your emails.

Now, when the receiving server intercepts this email, it looks for a key to decrypt the hash value. This key, known as the public key, should be published in your DNS server. Once this public key is obtained, the receiving server computes certain parts of the hash with this key to build its own hash value. This new value is compared with the encrypted hash sent along with the email. If the values match, then the email passes the DKIM inspection. If not, we know that the message has been tampered with.

 To enable DKIM, you will have to publish the public key in your DNS server. If you are using an email service provider to send your emails, the key will be provided to you.

The public key given to you will have this format:

K=rsa;

p=*********

• K=rsa

  The "K" denotes that we are adding a key and "RSA" is the key type.

• P=

  This indicates that we are entering a public key. It is then followed by a string of letters (called a string value), which is the actual key.

DMARC:

Now that we have covered SPF and DKIM, let's take a look at how they work with Domain-based Message Authentication, Reporting, & Conformance (DMARC) providing an added layer of security.

 SPF and DKIM work as a great team to tell the receiving server which emails to allow and reject. DMARC, on the other hand, tells it what to do with the emails that haven't cleared authentication. In addition to this, DMARC records also send reports to the email addresses specified in the DMARC record with data of the emails received by the domain.

DMARC is a standard that the domain admin publishes on their DNS server. The admin should specify the authentication methods available for their domain and the actions a server should take if a particular email fails the authentication.

Like SPF and DKIM, a DMARC policy is also a TXT record. It looks like this :

"v=DMARC1; p=none; rua=mailto:admin@yourdomain.com"

• V= 

  This indicates the version of the DMARC policy used.

• P= 

  This tag indicates the policy. It can have three values - none, quarantine or reject. This indicates the action to be performed on the email.

• Rua=

  This tag is the email addresses to which the DMARC reports should be sent.

• Pct 

  This tag is followed by a number and it indicates what percentage of your emails for which the action you've chosen in the p tag should apply. If PCT is not included, then it indicates that 100 percent of the emails are covered.

It's recommended to roll out your DMARC policy in phases. This makes it easier to review the emails you send. Here is how DMARC is implemented:

The DMARC policy is published in the corresponding DNS server. The receiving server looks up the DMARC policy published in the domain mentioned in the sender's address.

Now, DMARC is evaluated based on the following three factors:

1. If the SPF records match.

2. If DKIM validation is passed.

3. If there is domain alignment.

Based on the above information, the receiving domain will implement the DMARC policy and will either accept, reject, or flag the email.

Domain alignment: 

Domain alignment is checked by first obtaining the domain in the "from" address and the return path address or "bounce address."

For the domains to align, the following conditions must be true:

For SPF: The "from" address domain and the "bounce address" domain should match.

For DKIM: The "from" address domain and the domain in its DKIM signature should match.

The above alignment can either be strict (the domains must match entirely) or relaxed (main domains should match but subdomains don't need to). These conditions should be included in the policy updated in the sending domain.

Thus, DMARC combines the functionality of SPF and DKIM to protect your domain. At ZeptoMail, we mandate adding both SPF and DKIM before adding your DMARC policy.

 Why should I authenticate my domains? 

Just as you wouldn't walk into a dark alley in an area you don't trust, recipient servers won't deliver email from a domain with a poor track record. They'll deem those transactional emails untrustworthy and send the emails to the recipient's spam folder.

If you want your emails to arrive in their intended inbox, authenticating your domains will help you in the following ways:

Builds trust:

Trust is an important pillar of any business. In this era of online businesses, you should do everything you can to build this trust, and since emails are often the first points of contact between you and your customers, emails that land in the spam folder don't help your brand make a good first impression. Authenticating your domain will tell the receiving server that your brand can be trusted, which is an important step toward showing your customer that you can be trusted as well.

Helps you reach your clients:

Transactional emails are often time-sensitive and need to reach the intended destination at the desired time. Even a slight delay in receiving transactional emails will be a cause of angst for them. If your emails are constantly being sent to spam, your clients might miss important information. The delivery of your emails will be affected, and you might also run into problems with your ESP. However, you can avoid this by validating your domains.

 Increases brand reputation:

Building your brand identity takes enormous amounts of work. You do not want to jeopardize your brand reputation or your clients by allowing someone to steal your identity and use it for unscrupulous purposes. Although transactional emails are user-specific, if someone constantly uses your account to send out unsolicited emails, then that is going to create problems.

Thus, it is important to protect your domain and identity.

SPF, DKIM, and DMARC in ZeptoMail:

SPF, DKIM, and DMARC come into play whenever you send an email. Their role becomes even more significant when sending transactional emails that carry crucial information to your customers. This is the reason authenticating your domain is mandatory when creating your ZeptoMail account. We have made it easier for you by providing all the necessary records to be published in your DNS server. Furthermore, our help guides give you all the information required to set up your account. We also have an amazing support team who are always happy to help our users.

While it may seem overwhelming, if you're unfamiliar with the logistics of sending transactional emails, we cannot stress enough how important it is to authenticate your domain. This is a non-negotiable part of building your brand and for a good reason.

Sending transactional emails from a trustworthy domain will build trust with both your existing and potential customers. To help you do this, we here at ZeptoMail have made this process as easy as possible.

In the meantime, give our latest updates a try and share your feedback with us on social media, through email, or in the comments below!

You can also follow us on Twitter and LinkedIn and join our community forum for regular updates.