Email was developed in the early 1970s when the internet was still a research project with mainly university networks connected. It relies on the Simple Mail Transfer Protocol (SMTP), which is a protocol designed to transmit messages between systems. At the time when email was developed, security was not really a concern. Everyone on these networks could be trusted; why on earth would someone abuse it?
A few decades later it’s hard to imagine the internet and email without security. Email as we know it today is heavily abused with spoofed emails, trying to cheat and mislead people. Techniques which can help to protect against spoofing are SPF, DKIM and DMARC. In this post we will explain what these protections are and how they work.
By default, email clients only show a few pretty lines including the
From address is called the
header-from address. The tricky part is: it does not mean that an email really came from that header-from address. There is another one not displayed, which is called the
An email actually consists of two parts. The first part is SMTP with the envelope-from, responsible for the email delivery. The second part is the message, the actual email with the header-from. The header-from and the envelope-from are independent from each other, these can be different addresses. If an email client shows email@example.com (header-from) the SMTP headers could contain firstname.lastname@example.org (envelope-from), which is not displayed.
Having different addresses is by design, because sometimes it is necessary to change the envelope-from. This is also why email addresses can be spoofed, because both addresses can be anything and recipients (mostly) only see the header-from address.
Sender Policy Framework (SPF) is currently probably the most applied email protection. A SPF record is actually a record in DNS with a list of servers which are authorised to send mail for a specific domain. If a SPF record is published, a receiving server is able to validate if an email is coming from an authorised server. Depending on the SPF policy, an email may
SoftFail (move to spam) or
Example SPF record in DNS:
v=spf1 is currently default, it defines the protocol version. The other mechanisms tell a receiving server that only the
MX records and the included SPF record from
_spf.exonet.nl are authorised to send mail for
-all matches anything else. This one tells a receiving server to reject a mail if it was not send from an authorised server.
SPF does have it’s limitations. A big shortcoming is that it only protects the envelope-from address. Which means if an email passes SPF checks, the header-from may still be a spoofed address. SPF also breaks email forwards if the forwarding server is not published in the SPF record from the original sending domain. Sender Rewriting Scheme (SRS) is an attempt to fix this problem, but it’s currently not widely implemented. Even with SRS support a forward may still break with DMARC (explained below).
DomainKeys Identified Mail (DKIM) uses cryptographic keys to add signatures on emails, which can be verified with a cryptographic public key in DNS by receiving mail servers.
Example DKIM record in DNS:
mail._domainkey contains the selector (
v=DKIM1, the key type
k=rsa followed by the actual public key
If an email has been signed with DKIM, the headers will have a DKIM-Signature which consists of hashed values (header fields and message body). These values are generated with the private key, which is only known to the owner of the sending domain.
This signature shows that the signing domain
d=example.com with selector
s=mail can be used to lookup the public key in DNS. The other lines are the header fields
h=, the body hash
bh= and the signature data
b=. The hashed values and the signature combined with the public key can be verified by a receiving server and must match to pass a validation. If any of the header fields or the message body has been altered during the email delivery, the validation will fail.
However, an attacker can also setup DKIM and sign malicious emails from another domain. For example, an attacker could use email@example.com (envelope-from) and sign all the headers including firstname.lastname@example.org (header-from). The DKIM validation would perfectly pass, because a receiving server only verifies the DKIM record for example.com (
DKIM helps to validate the actual email content and headers, but it doesn’t prevent attackers from abusing the header-from address. It also doesn’t tell what a receiving server should do if a signature validation fails. This is where DMARC comes into the picture.
Domain-based Message Authentication, Reporting and Conformance (DMARC) is an anti-spoofing protection built on top of SPF and DKIM. It allows the owner of a domain to control email for a domain by publishing a DMARC policy in DNS. The policy tells a receiving server to either
quarantine (move to spam) or
reject (do not accept) the email if a validation fails. The biggest advantage of DMARC is that it also checks the header-from address.
Example DMARC record in DNS:
_dmarc is a default prefix for DMARC. The TXT record contains the protocol version
v=DMARC1, the policy
p=reject and a reporting email address
rua=mailto:<...>. The reporting email address is useful for domain administrators to analyse email delivery. If a receiving server supports DMARC, it will send reports to the
DMARC uses a concept which is called alignment. This checks if the
header-from matches with the
envelope-from (SPF) or with the
d=domain (DKIM). A DMARC policy requires that either SPF and/or DKIM passes. It does not require both to pass because, if an email has been forwarded, SPF checks will probably fail but DKIM should still pass (if nothing has been altered). However, even if SPF and DKIM both pass, DMARC still fails if the alignment does not match.
SPF, DKIM and DMARC together can be considered a best practice to finally prevent spoofing and make email more trustworthy. In an ideal world every domain would have these anti-spoofing protections enabled. Unfortunately it is not always that simple because a domain can have multiple mail servers on various locations. It requires some investigation first before all protections can be enabled. However, we do believe it is worthwhile to implement these protections because both, the owner of a domain and the recipients, will benefit from it.
Exonet supports SPF, DKIM and DMARC and we currently publish a SPF record (neutral) for all domains we manage. Our servers support DKIM signing but it is not enabled by default for domains. For customers who want to enable this and need help with the implementation, please feel free to contact our support department.