Authentication is considered as an important mechanism for your e-mail program.
ISPs and webmails have been tightening their filtering rules over the years in order to protect their users from spam and phishing.
In order ensure an optimal deliverability/delivery of your communications, you should implement the most common authentication mechanism available:
- Sender Policy Framework (SPF)
- DomainKeys Identified Mail (DKIM)
- Domain-based Message Authentication, Reporting and Conformance (DMARC)
In this article, I will explain how to implement the above listed authentication mechanism.
Sender Policy Framework (SPF)
The SPF is used to allow an IP address or a set of IP addresses to send communication on behalf of your domain name or subdomain.
Let’s say that the from email address I am using to send out communication is “email@example.com” and the IP address of the mail server sending my communications is “188.8.131.52”.
In order to allow SPF signing for all outbound emails being sent from my mail server, I will setup an SPF record at my domain’s registrar level by adding the following entry:
email.deliverability.guru. IN TXT "v=spf1 ip4:184.108.40.206 -all"
The above entry tells the receiving mail server that the server with IP address “220.127.116.11” is allowed to send communications on behalf of “email.deliverability.guru”, this can be checked on the email header of the received communication which should appear as follow:
Received-SPF: pass (domain of email.deliverability.guru designates 18.104.22.168 as permitted sender)
SPF is the minimal required authentication mechanism for sending communications to ISPs and webmails. This is also the case for lot of businesses.
DomainKeys Identified Mail (DKIM)
A DKIM record is composed of two parts, one being the private key which should be setup on your mail server (the one sending the actual communications) and the public key which should added as a dns TXT entry at your domain registrar.
Your DKIM key pair can easily be generated online using dkimcore.org. I am using the subdomain “email.deliverability.guru” for this example, the key pair is composed of:
A Private key
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----
A Public key
-----BEGIN PUBLIC KEY-----
-----END PUBLIC KEY-----
The selector is part of the DKIM record, it does allow to publish multiple DKIM keys on your domain or subdomain.
When you create a DKIM signature for your communications, you will need to specify which private key to use. The related DKIM key is totally bound to the specified selector. The associated public key is published in the DNS on a domain or subdomain which also need to contain this selector:
In our example, we will use the selector “one”, which will give us the following DKIM record to be added to our domains registrar DNS:
one._domainkey.email.deliverability.guru. IN TXT "v=DKIM1;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCl2G3Hvbndic2HRXorxfmdRCpEw8W9LPZ489Brz6RLbZPlmxbvae1KlFDZife3/zfKIAQ9WsjvqRPefJxV/ZNABmqOW09B6arzShAwYpIwwsszhIO8EmDmNqPIcbJWOaDA6F6Wo4VRNVuBVE+JwIcn1YJr+Ijr3wBYhv7B0ArxEwIDAQAB"
The DKIM signature will be validated at the receiving mail server by the following entry in the email header of the communication received:
dkim=pass (ok) firstname.lastname@example.org header.s=one;
Domain-based Message Authentication, Reporting and Conformance (DMARC)
Designed to give the ability to give domain owners to protect their domains from unauthorized use also known as “email spoofing”.
Once the DMARC DNS entry is published, any receiving mail server can authenticate the incoming email based on the instructions published by the domain owner within the DNS entry. If the email passes the authentication checks it will be delivered and can be trusted. If the email fails the check, depending on the instructions held within the published DMARC record the email could be delivered, quarantined or rejected.
Different DMARC policies can be set at your domain registrar’s level.
_dmarc.email.deliverability.guru IN TXT "v=DMARC1; p=none; rua=mailto:email@example.com;"
The above DMARC policy will instruct the receiving mail server to only send aggregated reports to the email address “firstname.lastname@example.org”, this does not instruct the receiving mail server to apply any filtering policy.
_dmarc.email.deliverability.guru IN TXT "v=DMARC1; p=quarantine; rua=mailto:email@example.com;"
The above DMARC policy will instruct the receiving mail server to “quarantine” the messages that fails DMARC check. The term “quarantine” means that the receiving mail server can treat the related message in different ways:
- deliver to junk folder: deliver the related message into the recipient’s spam folder
- temporarily hold the message for non compliance and perform additional analysis to decide whether the message should be delivered to the recipient or not
- Use it to improve its spam filtering systems which is likely to result in the related message to be considered as spam
_dmarc.email.deliverability.guru IN TXT "v=DMARC1; p=reject; rua=mailto:firstname.lastname@example.org;"
The above DMARC policy will instruct the receiving mail server to reject all messages which are failing DMARC check.
The receiving mail server which usually react in two different ways:
- Refuse to accept non-compliant emails and report it to the domain owner
- Accept initial SMTP delivery but prevents delivery to the final recipient for non-compliance. When delivery fails, one the following would happen:
– A non delivery message will be returned (bounce)
– The related message is silently dropped
The must have authentication mechanism are SPF and DKIM which are widely used, if possible it is also recommend to implement DMARC to ensure that your domains are fully protected against email spoofing.