The word hardening is an IT security term loosely defined as the process of securing a system by reducing its surface of vulnerability.
This guide is intended to help domain owners and system administrators to understand the process of email hardening. By adopting the SPF, DKIM and DMARC email security standards for your domain, you can reduce fraud, while improving deliverability of your email.
Given that email has existed for over 40 years, and was never intended to be a secure communication channel, we must accept that email is not, and will never be completely secure. Hence we use the term hardening and not securing.
As the adoption of email grew, its users became more vulnerable to fraud than ever before. The email standard was expanded with several mechanisms that aim at reducing fraudulent and spam emails. These standards are often not fully understood and offer a lot more features than commonly applied. Moreover, most of these techniques require the domain owner to make certain adjustments to the domain before it can be used, so these systems are not enabled by default.
There are many ways email can be exploited to perform fraudulent activities. In IT-security terms we say that email has a large attack surface. Discussing (and preventing) all possible attacks would result in a very lengthy article.
The kind of hardening that we'll discuss in this article is aimed at spam- and fraud-prevention, and deliverability. By deploying the standardised techniques SPF, DKIM and DMARC it will be harder for unauthorized senders to abuse your domain. These techniques also improve the deliverability of your legitimate email.
Please note that the hardening techniques described here are applicable to email that is sent from your domain name, not email that is sent to your domain. These techniques do not prevent spam, viruses or phishing attacks sent to your organisation. It will not prevent someone breaking into your mailbox.
One final disclaimer: these methods generally improve deliverability of email messages, but this is by no means a 'SEO for spam filters' guide, if such a thing could even exist.
If you are sending unsolicited email, do not expect any of these techniques to help you with fooling a spam filter.
The goal of this email hardening guide is to prevent fraudulent actors from sending email on behalf of your domain name. We do this by giving the receiver of your email as much information as possible on the authenticity of your email. This helps the receiving system with making an informed decision on the likelihood of the email being fraudulent or spam.
You want to give the receiver as much information as possible on whether:
The more information is supplied, the better the receiving service will be at judging if the email is real or fraudulent (spam). This reduces both false positives (legit email being marked as fraud or spam), as well as false negatives (spam or fraudulent email being passed as legitimate).
The type email hardening we'll explain in this article consists of the following steps:
Question: can you name all services that are sending email on behalf of your domain?
It may sound like a simple question, but the sources of email quickly grow as an organisation builds. It is not just the email that you sent from your email client. Think of invoices that are being sent from your accounting software, newsletters from a service like Mailchimp, you may use a service like Zendesk for customer support. All these services are sending email on behalf of your domain. There are also less obvious sources, such as automated crash reports from your servers, or your customer portal that is sending transactional emails such as password reset emails. That long forgotten SaaS platform you once set up may still be sending email on behalf of your domain.
Any of these may be misconfigured, which may impact your domain reputation in a way that a receiver cannot reliably determine if an email is legitimate or not.
It is possible to monitor all email that is being sent on behalf of your domain. DMARC, an email security standard, makes it possible to request receivers worldwide to send reports on email that has been received from your domain. These reports will give you valuable information on which services are sending the emails, which services received them and whether the emails were passed or rejected based on the SPF and DKIM security standards.
A DMARC report aggregator service, such as Mailhardener, is then used to combine those numerous reports into an overview of which services are sending email and how the receivers processed them.
Hardening step 1: Use a DMARC aggregator service to monitor the email traffic from your domain.
One of the first spam and fraud countermeasures was an extension to the email protocol known as the sender policy framework, or SPF in short. SPF allows a domain owner to publish a policy of which services are allowed to send email on behalf of the domain.
An SPF policy is published as a DNS record under the domain that is used in the sender address. A receiving email system will check for the existence of the DNS record and use that to determine if the sender was allowed to send email on behalf of the domain.
If the sender is not in the SPF list, the receiver will treat the email with extra caution, performing stricter spam detection, or even reject the email completely. If the sender passes SPF inspection the receiver has a good indication that the email is probably legitimate.
SPF has its problems though.
An email message can contain multiple sender addresses (read more about that here). There is a sender address on the email 'envelope', and the email message itself. These do not necessarily have to be the same.
For SPF validation the receiver only inspects the so called 'envelope' address to determine the sender. Most email programs do not show the envelope address, only the sender address on the email message itself. Thus, a spammer can simply use an envelope address of a domain that they control and use your domain as the sender in the email message itself. This allows them to pass SPF validation, while not being authorized to send email on behalf of your domain.
Many email services use this as a 'trick' to work around having to get their customers to configure and maintain SPF records.
In email security terms we speak about SPF alignment. If the envelope and sender address on an email are from the same domain, the email is considered aligned. SPF unfortunately allows unaligned email to pass inspection. An additional email security standard known as DMARC was introduced to mandate SPF alignment. More about this later.
SPF validation can break when email is being forwarded by a forwarding service.
For example: if
oldcompany.com re-brands itself as
newcompany.com, they usually set up a forwarding service so that all email received on
oldcompany.com is automatically forwarded to
Naturally they want to keep the original sender address when the email is forwarded.
So when you send an email from
olddomain.com it will be forwarded to
This is a completely legitimate use-case, but this also means that
olddomain.com just sent an email on behalf of
yourdomain.com by forwarding it.
Short answer: yes, but don't rely on just SPF for hardening.
Due to the problems with forwarding, and many email services deliberately sending email with unaligned sender addresses, it is not practical for receivers to strictly obey SPF validation. There are also a lot of domains that have misconfigured SPF, or have not deployed SPF at al. As a result, receiving email systems cannot use SPF to it's envisioned potential, because a strict SPF policy would cause a lot of legitimate email to become undeliverable.
SPF still has value though.
An aligned SPF pass gives the receiver a high confidence that the sender was authorized to send email on behalf of the domain. An unaligned SPF pass gives less certainty, and may cause the receiver to do stricter spam inspections further down the line. An SPF failure indicates that the sender most likely was not allowed to send email on behalf of the domain.
|SPF result||Information to receiver|
|Aligned pass||High confidence that this sender was allowed to send email on behalf of the domain|
|Unaligned pass||Some confidence that this sender was allowed to send email on behalf of the domain|
|No usable SPF||The receiver will use a neutral 'result' for SPF. This may cause false positives and false negatives in spam/fraud detection|
|Soft fail (
||Email has a medium high possibility of it being fraudulent or spam. Email may still be accepted, but likely marked as fraudulent.|
|Hard fail (
||Email has a high possibility of being fraudulent or spam. Email may be rejected completely, or otherwise marked as fraudulent.|
However, due to the sheer amount of SPF misconfiguration the receiver may still pass the email, this can be dependent on the domain reputation.
As a domain administrator you should strive towards the goal of having all your authorized senders included in our SPF policy. Preferably, if the sending service supports it, you should also make sure that the email is being sent with an aligned sender address. This usually requires you to make some configuration changes to the sending service. A good place to start is by searching for *[service name] SPF alignment*.
You use DMARC reporting to validate that every sender is always passing SPF in an aligned way. This greatly improves deliverability, and allows you to set a strict SPF and DMARC policy once all senders are passing.
In a typical deployment scenario a domain usually starts with a
~all (soft-fail) mechanism in their SPF policy.
With a soft-fail policy the domain declares that it is not (yet) willing to give a strong statement on how email that fails SPF validation should be handled by the receiver.
Using DMARC monitoring it is then confirmed that all legitimate senders are passing SPF validation (whether being aligned or not, more about this in step 4 of this guide).
Once all services are passing SPF validation, the policy is adjusted to use
-all (fail), which is the strongest statement a domain can make about how receivers should treat email that does not pass SPF validation.
Hardening step 2: Get all your senders SPF aligned, use DMARC monitoring to confirm.
Due to the shortcomings of SPF, a second method of battling spam and fraudulent email was introduced with the rather technical name domainkeys identified mail, or DKIM in short.
With DKIM email is signed with a cryptographic signature. This signature proves that the email is authentic (not changed) and that the sender is authorized to send email on behalf of the domain.
To use DKIM correctly, the public key for the signature is placed as a DNS record under your domain. By doing so you tell the receiver: trust the sender if the DKIM signature matches this key.
As DKIM is entirely optional, any email without a DKIM signature will still be accepted by the receiver. But an email with an (aligned) DKIM signature gives the receiver a higher confidence during spam and fraud detection.
An issue with DKIM is that email services can self-sign the DKIM signature, meaning that the DKIM public key is hosted at their domain, not yours. In email hardening terms we speak of DKIM alignment, a DKIM signature is aligned if the DKIM public key is published under the same domain as is used in the sender email address. With an unaligned signature the receiver can still validate authenticity (the email was not changed since it was sent), but not authorization.
Be aware that most email services (such as Gmail, Outlook and Yahoo) will report a DKIM inspection as passed, even if the DKIM signature isn't aligned. To make sure that all your email is signed and aligned, use DMARC monitoring.
|DKIM result||Information to receiver|
|Aligned pass||High confidence that the sender is authorized to send email on behalf of the domain. Email is also authentic.|
|Unaligned pass||Email is authentic, but sender may not be authorized to send email on behalf of the domain|
|No DKIM||Receiver does not use DKIM (a 'neutral' pass), which can result in false positives and false negatives in spam/fraud detection|
|DKIM fail||High confidence that email is not authentic, higher chance of sender not being authenticated. Receiver may reject the email, or pass it with a high fraud/spam rating|
In a typical situation
Hardening step 3: Confirm that all your email services are DKIM aligned.
Domain-based Message Authentication, Reporting and Conformance (DMARC) is an email standard that makes it possible to advise receivers on how to treat email from your domain. DMARC also makes it possible to ask receivers to send reports on the SPF and DKIM inspection results of email they received from your domain. This is the reporting that we have discussed in step 1.
DMARC is, like SPF, a policy that you publish as a DNS record under your domain. You use DMARC to advise receivers to expect SPF and/or DKIM alignment for all email from your domain, and what to do if the email does not pass alignment.
The most significant value in a DMARC record is the
p (policy) value.
It advises the receiver on what to do if an email results in neither an aligned SPF pass, nor an aligned DKIM pass.
Note that unaligned SPF or DKIM passes do not count towards a DMARC pass.
||If an email fails both DKIM and SPF alignment, quarantine this email. What quarantining means differs per receiver, but usually it means the email ends up in the spam or junk folder of the recipients inbox.|
||If an email fails both DKIM and SPF alignment, the receiver should reject the email. The email will not be delivered to the recipient's inbox.|
DMARC removes a lot of guesswork from the receiver. A DMARC policy (other than
none) tells the receiver to expect the domain is using SPF and DKIM.
Since SPF can 'break' (become unaligned) when an email passes through a forwarding service, you should not rely on SPF alone when using a DMARC policy. DKIM is a much better mechanism, as it is cryptographically secured, isn't affected by forwarders and as a bonus it also adds authentication. The combination of DKIM with DMARC is the recommended way of preventing fraud and improving deliverability of your email.
In a typical DMARC adoption process you'd start with DMARC in
none mode to monitor email traffic (explained in step 1 of this article).
Once all your email services are correctly set up to produce aligned SPF and DKIM results, most organisations will switch to a
quarantine policy, and eventually to a
For large email environments it is also possible to 'ease-in' the policy using the optional
pct (percentage) setting in the DMARC policy, to slowly migrate from one policy to the other.
Hardening step 4: Publish a strict DMARC policy.
The threat surface of email is rather large, but with the help of this guide you should have a fairly good grip on reducing that threat surface. By hardening your email you make it much harder for fraudulent email being sent using your domain name. When implemented correctly this should also help with deliverability, thus reducing the changes of your email being flagged as spam.
To recap the steps:
p=rejectonce all services are passing SPF and/or DKIM alignment.
With the SPF set to
-all and a
p=reject DMARC policy you give a strong statement towards receivers that only properly aligned email is allowed to pass.
Now your domain is hardened against fraudulent actors trying to send email on behalf of your domain. This also gives a lower chance of legitimate email from your domain being marked as spam.