Email is a fickle thing …
There are a huge amount of dependencies involved in what seems like a small task – sending an email. What started out as a simple method of exchanging messages has morphed over the years into a cobbled-together monster as needs changed and especially businesses required a more robust and featureful method for exchanging information. Approximately 250 billion emails are sent each day of which around 10-15% are genuine so email is still heavily utilised.
Note only does email have to deal with the underlying ephemeral infrastructure of the internet, but it also has to deal with spam, blacklisting, bad MIME implementations and flaky email servers.
Email delivery is not guaranteed, no matter how much we would like it to be. But we can improve things to the point where email delivery, in- and outbound, will have a higher chance of delivery.
A number of frameworks have been introduced in recent years to provide authentication/identification of email:
- sender policy framework (SPF) – check if a server is authorised to send email for a domain
- domain keys identified email (DKIM) – check if emails from a specific domain are authorised using sigital signatures
- domain message authentication, reporting and compliance (DMARC) – protect domains from email spoofing (this is basically an extension/combination of SPF and DKIM)
These frameworks work to detect domain or email address spoofing attacks. Domains that have published records for these methods are essentially trusted more than domains that do not have these records. In addition, the signature verification method of DKIM means that a domain signature can’t be spoofed. In the combined method, DMARC, organisations have a strong and proven method for protecting their email domains.
So how do these methods work?
SPF
A DNS record of type TXT or SPF is added for the domain in question, and any IP addresses, hostnames or other domains that should be authorised to send email for the domain, are added to this record. When someone receives email indicated as being from your domain, the recipient server can check if the sender server is authorised. There are 3 actions that the recipient server can take:
- PASS – the email is sent on without adjustment
- FAIL – the email is blocked
- SOFTFAIL – the email is accepted but tagged as having failed the check
DKIM
A digital signature (PKI) is added to a DNS TXT record for the domain in question and emails from this domain have the DKIM-Signature header appended. Recipient systems then check this signature header against the one published in the DNS record to confirm its authenticity.
DMARC
Policies are generated and stored in DNS TXT records. These records check if the FROM: field is aligned with SPF or DKIM. Alignment can be strict or relaxed.
In conclusion, and using the above methods, one can prevent their domain from being used in email spoofing attacks; as well, you can also verify senders of email as being authentic. The basis for these checks and preventions are the ownership of a domain by the organisation in question – if you own your domain, only you can add the necessary records to implement these frameworks. In doing so, you are assumed to have a higher trust than others, and there is a better chance of your emails being received.
Anti-spam solutions also take SPF/DKIM/DMARC headers into account when scoring emails for spam, generally adding a negative value to the score thereby improving the chances of delivery and non-tagging as spam.
These frameworks are designed to improve email delivery and in general, they succeed quite well. Make sure you are using 1 or more of these methods with your email domains.