Why Some Phishing Emails Are Mysteriously Disappearing

Phishing is the absolute worst.

Unfortunately, sometimes phishing campaigns use Cloudflare for the very convenient, free DNS. To be clear –– there’s a difference between a compromised server being leveraged to send phishing emails and an intentionally malicious website dedicated to this type of activity. The latter clearly violates our terms of service.

In the past, our Trust and Safety team would kick these intentional phishers off the platform, but now we have a new trick up our sleeve and a way for their malicious emails to mysteriously disappear into the ether.

SMTP - the protocol used for sending email - was finalized in 1982, when it was just a small community online. Many of them knew and trusted each other, and so the protocol was built entirely on trust. In an SMTP message, the MAIL FROM field can be arbitrarily defined. That means you could send an email from any email address, even one you don’t own.

This is great for phishers, and bad for everyone else.

The solution to prevent email spoofing was to create the Sender Policy Framework (SPF). SPF allows the domain owner to specify which servers are allowed to send email from that domain. That policy is stored in a DNS TXT record like this one from cloudflare.com:

$ dig cloudflare.com txt
"v=spf1 ip4:199.15.212.0/22 ip4:173.245.48.0/20 include:_spf.google.com include:spf1.mcsv.net include:spf.mandrillapp.com include:mail.zendesk.com include:customeriomail.com include:stspg-customer.com -all"

This says that email clients should only accept cloudflare.com emails if they come from an IP in the ranges 199.15.212.0/22, 173.245.48.0/20, or one of the IP ranges found in the SPF records for the other domains listed. Then if a receiving email server receives an email from someone@cloudflare.com from the server at 185.12.80.67, that email server would check the SPF records of all the allowed domains until it finds that 185.12.80.67 is allowed because 185.12.80.0/22 is listed in mail.zendesk.com’s SPF record:

$ dig txt mail.zendesk.com
"v=spf1 ip4:192.161.144.0/20 ip4:185.12.80.0/22 ip4:96.46.150.192/27 ip4:174.137.46.0/24 ip4:188.172.128.0/20 ip4:216.198.0.0/18 ~all"

Additional methods for securing email were created after SPF. SPF only validates the email sender but doesn’t do anything about verifying the content of the email. (While SMTP can be sent over an encrypted connection, SMTP is notoriously easy to downgrade to plaintext with an on-path attacker.)

To verify the content, domain owners can sign email messages using DKIM. The email sender includes the message signature in an email header called DKIM-Signature and stores the key in a DNS TXT record.

$ dig txt smtpapi._domainkey.cloudflare.com
"k=rsa\; t=s\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPtW5iwpXVPiH5FzJ7Nrl8USzuY9zqqzjE0D1r04xDN6qwziDnmgcFNNfMewVKN2D1O+2J9N14hRprzByFwfQW76yojh54Xu3uSbQ3JP0A7k8o8GutRF8zbFUA8n0ZH2y0cIEjMliXY4W4LwPA7m4q0ObmvSjhd63O9d8z1XkUBwIDAQAB"

There’s one more mechanism for controlling email spoofing called DMARC. DMARC sets the overarching email policy, indicates what to do if the policies are not met and sets a reporting email address for logging invalid mail attempts. Cloudflare’s DMARC record says that noncomplying emails should be sent to junk mail, 100% of messages should be subject to filtering and if policies are not met, send the report to the two email addresses below.

$ dig txt _dmarc.cloudflare.com
"v=DMARC1\; p=quarantine\; pct=100\; rua=mailto:rua@cloudflare.com, mailto:gjqhulld@ag.dmarcian.com"

When an email server receives an email from someone@cloudflare.com, it first checks SPF, DKIM and DMARC records to know whether the email is valid, and if not, how to route it.

For known phishing campaigns using the Cloudflare platform for evil, we have a DNS trick for getting their phishing campaigns to stop. If you remember, there are three DNS records required for sending email: SPF, DKIM and DMARC. The last one is the one that defines the overarching email policy for the domain.

What we do is rewrite the DMARC record so that the overarching email policy instructs email clients to reject all emails from that sender. We also remove the other DNS record types used for sending email.

"v=DMARC1; p=reject"

When an email client receives a phishing email, the corresponding DNS records instruct the client not to accept the email and the phishing email is not delivered.

You can see it in action on our fake phish domain, astronautrentals.com.

astronautrentals.com is configured with an SPF record, a DKIM record, and a DMARC record with a policy to accept all email.

However, because it is a known (fake) phishing domain, when you query DNS for these records, SPF will be missing:

$ dig astronautrentals.com txt
astronautrentals.com.	3600	IN	SOA	art.ns.cloudflare.com. dns.cloudflare.com. 2026351035 10000 2400 604800 3600

DKIM will be missing:

$ dig _domainkey.astronautrentals.com txt
astronautrentals.com.	3600	IN	SOA	art.ns.cloudflare.com. dns.cloudflare.com. 2026351035 10000 2400 604800 3600

And DMARC policy will be rewritten to reject all emails:

$ dig _dmarc.astronautrentals.com txt
"v=DMARC1\; p=reject"

If we try to send an email from @astronautrentals.com, the email never reaches the recipient because the receiving client sees the DMARC policy and rejects the email.

This DMARC alteration happens on the fly –– it's a computation we do at the moment when we answer the DNS query –– so the original DNS records are still shown to the domain owner in the Cloudflare DNS editor. This adds some mystery to why the phish attempts are failing to send.

Phishing is the absolute worst, and the problem is that it sometimes succeeds. Last year Verizon reported that 30% of phishing emails are opened, and 13% of those opened end with the receiver clicking on the phishing link.

Keeping people safe on the internet means decreasing the number of successful phishing attempts. We're glad to be able to fight phish using the DNS.