What Is Email Authentication And Why Is It Important?

Authentication technology allows the receiver of an email and the Internet Service Provider (ISP) to confirm the identity of the sender. If the identity of the sender can not be authenticated, then ISPs may reject the message, or put it through additional filters to determine if it should be delivered. Without authentication, your chances of being filtered by major ISPs are greatly increased and the chances of them blocking spoofed messages impossible. Email authentication is important because it addresses one of the fundamental security problems inherent to email sending technology. By exploiting such weaknesses phishers and spoofers have been able to thrive. Authentication is integral to preventing phishing and other fraud while playing a key role in the emerging reputation and accreditation systems that will drive the future of email.

Email authentication is a collection of techniques aimed at equipping messages of the email transport system with verifiable information. It is a coarse-grained authentication, usually at Administrative Management Domain (ADMD) level and implies no sort of authorization.

10 Steps to setup Email Authentication server side 
(our own experience, work in progress)

• Step 1 (Domain). Get an Internet domain name, for our purposes, were going to use cfts.co as our domain example. First, you’ll need your own domain if you want to receive messages directly to your server. You can register your domain at CFTS. When you register a domain, you need to provide the IP address and hostname of at least 1 DNS server for your domain, although most registration services require 2 or 3 DNS servers, 2 geo/subnet separated preferably.

• Step 2 (Fixed IP). Get an Internet IP for email use, if it is for organisational use might be better to make sure your mail IP is separate and/or additional from your internet pipe, a fixed IP is better, you can use dynamic IP but then things start to get messy.

• Step 3 (Host Name). Define a unique and service-specific, hostname for e-mail use (FQDN) from that IP (Here are some examples: mail.cfts.co | mail1.cfts.co | smtp.cfts.co | imap.cfts) If you have multiple domains, you should ensure that the FQDN is from the most credible domain (i.e. from your true company domain) - not from an alias, nor a service only, domain. A good FQDN can make troubleshooting a whole lot easier down the road while also showing your most credible/responsible side.  In our case ‘jails.cfts.co’ and ‘mail2.cfts.co’

• Step 4 (PTR). Configure e-mail server EHLO/HELO to match unique hostname string (from Step 3). In this case, mail1.cfts.co This step is commonly overlooked and the default internal server name is used instead when left unchanged; which may be hard to see from within your own network - others will see it when you try to send them email from a host name that is not a proper FQDN and/or does not match the rDNS = message rejected.

• Step 5 (MX). Create an MX record to accept mail at that host/IP (from Step 2), for your domain (from Step 1)

• Step 6 (SPF). Create a TXT record for SPF that allows only authorized FQDNs & IPs to send email from your domain. cfts.co.              v=spf1 mx a -all 
  - Any server/s covered by your mx records do not need to be listed again!
  jails.cfts.co.      v=spf1 a ip4:78.129.251.193/32 -all
  mail2.cfts.co.    v=spf1 a ip4:78.129.251.192/32 -all For domains that do not send mail or not used/parked, create a TXT record with:
  <domain>.               v=spf1 -all
  This will help protect your brand and domain from being spoofed and sending others spoofed emails in your name.

• Step 7 (DKIM). Create TXT record,  DKIM (DomainKeys Identified Mail) is an important authentication mechanism to help protect both email receivers and email senders from forged and phishing email. Forged email is a serious threat to all parties in an email exchange. _domainkey.cfts.co.                   t=y; o=~; r=;
  _adsp._domainkey.cfts.co.        dkim=all
  mail2._domainkey.cfts.co.        v=DKIM1; k=rsa; n=2048; p=<public key string> Private Key should never be given out, that always remains with the server DKIM checks the message content, deploying digital signatures. Rather than using digital certificates, the keys for signature-verification are distributed via the DNS. That way, a message gets associated to a domain name.
• Step 8 (DMARC).  Create a TXT record, DMARC is an email authentication protocol. It builds on the widely deployed SPF (from Step 6) and DKIM (from Step 7) protocols, adding a reporting function that allows senders and receivers to improve and monitor the domain to help protect against fraudulent/spamming emails claiming to be from the said domain. In 2007, PayPal pioneered this approach and worked out a system with Yahoo! Mail and later Gmail to collaborate in this fashion. The results were extremely effective, leading to a significant decrease in suspected fraudulent email purported to be from PayPal being accepted by these receivers. The goal of DMARC is to build on this system of senders and receivers collaborating to improve mail authentication practices of senders and enable receivers to reject unauthenticated messages. _dmarc.cfts.co.      v=DMARC1; p=none; rua=mailto:; ruf=mailto:;fo=1;adkim=s;aspf=s;sp=reject Check what the above means here, and test yours here, this is very strict so you must make sure that everything is right before you implement as above, if your note sure I would advise something like this: _dmarc.cfts.co.     v=DMARC1; p=none; rua=mailto:<email@domain>;; ruf=mailto:,mailto:<email@domain>;;fo=1

• Step 9 (rDNS). Create a rDNS entry for IP (from step #2) that matches the EHLO/HELO string (from step #4) Getting a rDNS to match your EHLO basically tries to prove that "you are who you say you are." This is done from the ISP end.
• Step 10 (default email addresses)
  for reports of spam, abuse, and technical issues. Since abuse and postmaster are reserved aliases, you can't use them as usernames or nicknames. There's no reason to create them all as individual e-mail accounts. You can just set up forwarders or aliases that lead to a generic site.admin@ account and set up a filter for that in your mail client to keep the noise isolated, I tend to to make a postmaster@ account with abuse@ and webmaster@ aliases. webmaster@ is where good-natured people do things like report broken links, it happens more than you'd think!
  abuse@ is nice to have, it sometimes keeps people from going directly to your host/data centre/bandwidth provider in the event that someone found a way to use your server to send SPAM.
  postmaster@ is handy to check, and make sure root's mail is also sent there, at the least it will show you if your mail server is configured incorrectly, it will also catch bounces that let you know you have a spammer. A very important 'also' is that SSL providers will send a confirmation email to one of the above addresses, so you need to be able to receive it. See also RFC 2142 (tools.ietf.org/html/rfc2142) for more information on this, again a must-read.

If this seems a bit overwhelming contact us and we can walk you through it or do it for you just give us a call

Will Authentication Solve My Delivery Problems?

It’s important to note that email authentication like SPF and DKIM will not solve your deliverability problems. Validating a domain does not speak to the content or value of the message, only to the identity of the responsible sender.  Authentication will make it harder for your domains to be forged and is critical to your brand reputation and subscriber trust. However, authentication will not compensate for weak practices around content, permission standards, bounce handling, complaints or filter triggers This guide provides guidelines and recommendations for legitimate businesses seeking to improve their deliverability rates and protect the brand from domain forgery and phishing scams, points are in a general order of implementation and should be followed unless you know what you are doing.

Will Authentication Solve My Phishing and Spoofing Problems?

Just as SPF and DKIM will not solve your deliverability problems, it will not stop phishing and spoofing attacks unto itself. Before an ISP can block a spoofed email, it must be sure that all the email sent from a particular domain is authenticating properly and that unauthenticated email should be blocked.  In order to achieve this, companies need to be able to view all the email streams that are being sent from that domain and monitor whether or not they are being authenticated with SPF and DKIM. Once authentication is validated, the domain can be placed on an email domain registry list utilized by ISPs to block unauthenticated emails and stop phishing and spoofing emails at the gateway. Security, IT and marketing professionals need to reduce the risk of fraudulent email activity against their brand and customers and secure the email channel for trusted customer communication. Today SPF and DKIM along with authentication monitoring and ISP registry tools can help to protect their brands against phishing and spoofing attacks. But it can, and should, be used as a basic troubleshooting checklist to recheck and confirm that the basic steps in your email setup are in compliance.

Other Information
What is SPF
What is DMARC
What is DKIM
RFC5321 for Simple Mail Transfer Protocol
RFC6376 for DKIM
Protecting Parked Domains Best Common Practices

Tools
SPF record check
SPF Query tool (highly recommended to test various SPF scenarios)
Create SPF record tool
Create DMARC record tool
DMARC e-mail test tool
DMARC analysis tool
SMTP Mail Server test (alternative to MXToolbox, good for servers that have a long delay period before responding)
DNS Check tool (alternative to MXToolbox)
Generic test toolbox (MXToolbox)
Generic test toolbox (ViewDNS, another super tool like MXToolbox)
View DNS Zone records

The above tools and information offer no 'magic bullet' you still need to know what your doing, for instance, if like us you have a long (25 seconds) initial response time, you will often have SMTP timeout errors when testing with these tools, 25 seconds is within the permitted delay period allowed so no issue for legitimate and properly setup mails servers, however to spammers time is money. Some very good documentation on this subject can be found here.