Sender Authentications

Now as in the previous blogs of deliverability series, we have discussed a good amount of information about lists hygiene, engaging content, IP/ domain reputation, spam filters and others. In this blog I’ll try to put some of the important factors to consider in the sending server, especially if you are configuring your sending environment from the scratch.

IP and Domains

In previous blog, we discussed building and maintaining the reputation of originating IP and Domain. In this blog we’ll concentrate what other steps that you need to take with the originating IP and domain, in order to configure your system properly for better delivery rates.

Setup rDNS

rDNS or reverse DNS is opposite to forward DNS, and resolves the IP address to domain name. As subscribers inbox are flooded with spam and forged emails, ISPs (Including Major ISPs) take this very sensitively that no email which looks illegitimate reaches the user’s inbox. Let’s be simple on it without using technical terms. When your sending server connects other system to deliver an email, the other system looks if the originating IP resolves to the domain it claims to be coming from. If the information successfully resolves to the right domain, the server would accept the incoming email. But in case of not being able to resolve to the sending domain, ISPs would suspect the incoming email and would not deliver it to the recipient.

Email Authentication (DNS Records)

Email authentications benefit both sender and the recipient (Recipient’s ISP). For the sender, it offers opportunity to publish policies and announce legitimacy of the email they are sending, while it provides recipient with an ability to protect the inbox by getting swamped from unwanted and unsolicited emails.

DKIM (Domain Key Identified Emails)

This email security standard is initiative to stop spam/forged emails to get any success with the subscriber’s inbox. The pair of public and private key helps verifying the message source to confirm that the message hasn’t been changed during transit. When you setup your mail server, make sure you generate accurate DKIM value, a public key to be able to setup within domain’s DNS panel and private key for the sending server.

SPF (Sender Policy Framework)

SPF also known as sender policy framework offers recipient server an ability to verify if the sending server is allowed to send on behalf of the sending domain. Like DKIM, SPF is also a TXT DNS entry, and primarily be used to control email spoofing by offering an extra security layer. Implementing it right will make the recipient’s system to recognize if the sending server is authorized to send email on behalf of particular domain. So unless your server isn’t configured with accurate SPF entry, your sending domain will most likely to appear as forged to the ISPs, and your message will not be accepted.

DMARC (Domain Based Message Authentication, Reporting and Conformance)

Like the earlier discussed email authentications, DMARC is intended to give recipient’s side better control to judge the legitimacy of an incoming message, and the sending side an ability to publish policies to improve sending reputation and enhance effectiveness against spamming and spoofing. One needs to have both DKIM and SPF in-place before configuring the DEMARC.  You are required to publish TXT record in your domain’s DNS to configure the DMARC; the process can sometimes be tricky and may need technical assistance to get it configured correctly. Implementing the key values of DMARC, domain reporting and domain alignment, ensures that the email is authenticating its earlier setup values of DKIM and SPF.

For improved deliverability, make sure you have all these sender authentications and polices published correctly as recommended. If you don’t want your sending reputation to suffer from a drawback, go through from the earlier discussed topics of deliverability series.

Deliverability Series

Sender Authentications

A series in which we discuss some of the important factors help improving email delivery.
  1. Mumara
  2. Sender Authentications