Today we’re rolling out a new tool to tackle email spoofing and phishing and improve email deliverability: The new Email Security DNS Wizard can be used to create DNS records that prevent others from sending malicious emails on behalf of your domain. This new feature also warns users about insecure DNS configurations on their domain […]
Today we’re rolling out a new tool to tackle email spoofing and phishing and improve email deliverability: The new Email Security DNS Wizard can be used to create DNS records that prevent others from sending malicious emails on behalf of your domain. This new feature also warns users about insecure DNS configurations on their domain and shows recommendations on how to fix them. The feature will first be rolled out to users on the Free plan and over the next weeks be made available for Pro, Business and Enterprise customers, as well.
Before we dive into what magic this wizard is capable of, let’s take a step back and take a look at the problem: email spoofing and phishing.
Spoofing is the process of posing as someone else which can be used in order to gain some kind of illicit advantage. One example is domain spoofing where someone hosts a website like
mycoolwebpaqe.xyz to trick users of
mycoolwebpage.xyz to provide sensitive information without knowing they landed on a false website. When looking at the address bar side by side in a browser, it’s very hard to spot the difference.
Then, there is email spoofing. In order to understand how this works, let’s take a look at a Cloudflare product update email I received on my personal email address. With most email providers you can look at the full source of an email which contains a number of headers and of course the body of the email.
Date: Thu, 23 Sep 2021 10:30:02 -0500 (CDT) From: Cloudflare <[email protected]> Reply-To: [email protected] To: <my_personal_email_address>
Above you can see four headers of the email, when it was received, who it came from, who I should reply to, and my personal email address. The value of the
From header is used to display the sender in my email program.
When I receive an email as above, I automatically assume this email has been sent from Cloudflare. However, nobody is stopped from sending an email with a modified
From header from their mail server. If my email provider is not performing the right checks, which we will cover later in this blog post, I could be tricked into believing that an email was sent from Cloudflare, but it actually was not.
This brings us to the second attack type: phishing. Let’s say a malicious actor has successfully used email spoofing to send emails to your company’s customers that seem to originate from one of your corporate service emails. The content of these emails look exactly like a legitimate email from your company using the same styling and format. The email text could be an urgent message to update some account information including a hyperlink to the alleged web portal. If the receiving mail server of a user does not flag the email as spam or insecure origin, the user might click on the link which could execute malicious code or lead them to a spoofed domain asking for sensitive information.
According to the FBI’s 2020 Internet Crime Report, phishing was the most common cyber crime in 2020 with over 240,000 victims leading to a loss of over $50M. And the number of victims has more than doubled since 2019 and is almost ten times higher than in 2018.
In order to understand how most phishing attacks are carried out, let’s take a closer look at the findings of the 2020 Verizon Data Breach Investigations Report. It lies out that phishing accounts for more than 80% of all “social actions”, another word for social engineering attacks, making it by far the most common type of such an attack. Furthermore, the report states that 96% of social actions are sent via email and only 3% through a website and 1% via phone or text.
This clearly shows that email phishing is a serious problem causing Internet users a big headache. So let’s see what domain owners can do to stop bad actors from misusing their domain for email phishing.
Luckily, there are three anti-spoofing mechanisms already built into the Domain Name System (DNS):
However, it is not trivial to configure them correctly, especially for someone less experienced. In case your configuration is too strict, legitimate emails will be dropped or marked as spam. And if you keep your configuration too relaxed, your domain might be misused for email spoofing.
SPF is used to specify which IP addresses and domains are permitted to send email on behalf of your domain. An SPF policy is published as a TXT record on your domain, so everyone can access it via DNS. Let’s inspect the TXT record for
cloudflare.com TXT "v=spf1 ip4:22.214.171.124/22 ip4:126.96.36.199/20 include:_spf.google.com include:spf1.mcsv.net include:spf.mandrillapp.com include:mail.zendesk.com include:stspg-customer.com include:_spf.salesforce.com -all"
An SPF TXT record always needs to start with
v=spf1. It usually contains a list of IP addresses of sending email servers using the
ip6 mechanism. The
include mechanism is used to reference another SPF record on another domain. This is usually done if you are relying on other providers that need to send emails on our behalf. You can see a few examples in the SPF record of
cloudflare.com above: we’re using Zendesk as customer support software and Mandrill for marketing and transactional emails.
Finally, there is the catch-all mechanism
-all which specifies how all incoming, but unspecified emails should be treated The catch-all mechanism is preceded by a qualifier that can be either + (Allow), ~ (Softfail) or – (Fail). Using the
Allow qualifier is not recommended as it basically makes the SPF record useless and allows all IP addresses and domains to send email on behalf of your domain.
Softfail is interpreted differently by receiving mail servers, marking an email as Spam or insecure, depending on the server.
Fail tells a server not to accept any emails originating from unspecified sources.
The diagram above shows the steps taken to ensure a received email is SPF compliant.
203.0.113.10and contains a
Fromheader with the value of
mycoolwebpage.xyzto retrieve the SPF policy for this domain.
203.0.113.10is listed in the SPF record. If it is, the email succeeds the SPF check. If it is not, the qualifier of the
allmechanism defines the outcome.
For a full list of all mechanisms and more details about SPF, refer to RFC7208.
Okay, with SPF we’ve ensured that only permitted IP addresses and domains can send emails on behalf of cloudflare.com. But what if one of the IPs changes owner without us noticing and updating the SPF record? Or what if someone else who is also using Google’s email server on the same IP tries to spoof emails coming from cloudflare.com?
This is where DKIM comes in. DKIM provides a mechanism to cryptographically sign parts of an email — usually the body and certain headers — using public key encryption. Before we dive into how this works, let’s take a look at the DKIM record used for cloudflare.com:
google._domainkey.cloudflare.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDMxbNxA2V84XMpZgzMgHHey3TQFvHkwlPF2a11Ex6PGD71Sp8elVMMCdZhPYqDlzbehg9aWVwPz0+n3oRD73o+JXoSswgUXPV82O8s8dGny/BAJklo0+y+Bh2Op4YPGhClT6mRO2i5Qiqo4vPCuc6GB34Fyx7yhreDNKY9BNMUtQIDAQAB"
The structure of a DKIM record is
<selector>._domainkey.<domain>, where the selector is provided by your email provider. The content of the
DKIM TXT record always starts with
v=DKIM1 followed by the public key. We can see the public key type, referenced by the
k tag, and the public key itself, preceded by the
Besides the TXT record that contains the public DKIM key, receiving email servers will parse an email header that contains the DKIM signature — the part that has been signed with the private DKIM key — besides some other information the email receiver needs to perform the DKIM check. Below is an example of this email header which is part of a Cloudflare product update email:
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1632416903; s=m1; d=cloudflare.com; [email protected]; h=Content-Type:MIME-Version:Subject:To:From:Date; bh=uMixy0BsCqhbru4fqPZQdeZY5Pq865sNAnOAxNgUS0s=; b=LiIvJeRyqMo0gngiCygwpiKphJjYezb5kXBKCNj8DqRVcCk7obK6OUg4o+EufEbB tRYQfQhgIkx5m70IqA6dP+DBZUcsJyS9C+vm2xRK7qyHi2hUFpYS5pkeiNVoQk/Wk4w ZG4tu/g+OA49mS7VX+64FXr79MPwOMRRmJ3lNwJU=
You can see the email domain
d=cloudflare.com, the selector
s=google, the list of headers that are part of the DKIM signature preceded by
h= and the DKIM signature following
Below is a simplified sequence how the signing and DKIM check work:
h) and the email message.
b) using the public DKIM key.
Domain-based Message Authentication Reporting and Conformance, that’s definitely a mouthful. Let’s focus on two words: Reporting and Conformance. DMARC provides exactly that. Regular reports let the email sender know how many emails are non-conforming and potentially spoofed. Conformance helps provide a clear signal to the email receiver how to treat non-conforming emails. Email receivers might impose their own policies for emails that fail SPF or DKIM checks even without a DMARC record. However, the policy configured on the DMARC record is an explicit instruction by the email sender, so it increases the confidence for email receivers what to do with non-conforming emails.
Here is the DMARC record for
_dmarc.cloudflare.com. TXT "v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]"
The DMARC TXT record is always set on the
_dmarc subdomain of the email domain and — similar to SPF and DKIM — the content needs to start with
v=DMARC1. Then we see three additional tags:
The policy tag (
p) indicates how email receivers should treat emails that fail SPF or DKIM checks. Possible values are
none policy is also called monitoring only and allows emails failing the checks to still be accepted. By specifying
quarantine, email receivers will put SPF or DKIM non-conforming emails in the Spam folder. With
reject, emails are dropped and not delivered at all if they fail SPF or DKIM.
The percentage tag (
pct) can be used to apply the specified policy to a subset of incoming emails. This is helpful if you’re just rolling out DMARC and want to make sure everything is configured correctly by testing on a subset.
The last tag we can find on the record is the reporting URI (
rua). This is used to specify an email address that will receive aggregate reports (usually daily) about non-conforming emails.
Above, we can see how DMARC works step by step.
mycoolwebpage.xyzto retrieve the required policies and the DKIM public key.
ruatag this report could also be sent to a different email server which is responsible for that email address.
Other optional tags and the complete DMARC specification is described in RFC7489.
Now that we’ve learned what the problem is and how to tackle it using SPF, DKIM, and DMARC, let’s see how widely they’re adopted.
Dmarc.org has published the adoption of DMARC records of domains in a representative dataset. It shows that by the end of 2020, still less than 50% of domains even had a DMARC record. And remember, without a DMARC record there is no clear enforcement of SPF and DKIM checks. The study further shows that, of the domains that have a DMARC record, more than 65% are using the monitoring only policy (
p=none), so there is a significant potential to drive this adoption higher. The study does not mention if these domains are sending or receiving emails, but even if they didn’t, a secure configuration should include a DMARC record (more about this later).
Another report from August 1, 2021 tells a similar story for domains that belong to entities in the banking sector. Of 2,881 banking entities in the United States, only 44% have published a DMARC record on their domain. Of those that have a DMARC record, roughly 2 out of 5 have set the DMARC policy to
None and another 8% are considered “Misconfigured”. Denmark has a very high adoption of DMARC on domains in the banking sector of 94%, in contrast to Japan where only 13% of domains are using DMARC. SPF adoption is on average significantly higher than DMARC, which might have to do with the fact that the SPF standard was first introduced as experimental RFC in 2006 and DMARC only became a standard in 2015.
font-family:Arial, sans-serif;font-size:12px;overflow:hidden;padding:10px 10px;word-break:normal;}
font-family:Arial, sans-serif;font-size:12px;font-weight:normal;overflow:hidden;padding:10px 10px;word-break:normal;}
|Country||Number of entities||SPF present||DMARC present|
This shows us there is quite some room for improvement.
So what are we doing to increase the adoption of SPF, DKIM, and DMARC and tackle email spoofing and phishing? Enter the new Cloudflare Email Security DNS Wizard.
Starting today, when you’re navigating to the DNS tab of the Cloudflare dashboard, you’ll see two new features:
In order to start using the Email Security DNS Wizard, you can either directly click the link in the warning which brings you to the relevant section of the wizard or click Configure in the new Email Security section. The latter will show you the following available options:
There are two scenarios. You’re using your domain to send email, or you don’t. If you do, you can configure SPF, DKIM, and DMARC records by following a few simple steps. Here you can see the steps for SPF:
If your domain is not sending email, there is an easy way to configure all three records with just one click:
Once you click Submit, this will create all three records configured in such a way that all emails will fail the checks and be rejected by incoming email servers.
example.com TXT "v=spf1 -all" *._domainkey.example.com. TXT "v=DKIM1; p=" _dmarc.example.com. TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s;"
Out you go and make sure your domain is secured against email spoofing and phishing. Just head over to the DNS tab in the Cloudflare dashboard or if you are not yet using Cloudflare DNS, sign up for free in just a few minutes on cloudflare.com.
If you want to read more about SPF, DKIM and DMARC, go check out our new learning pages about email related DNS records.