50% of companies we know have domains that are vulnerable to email spoofing

In this post, Peter Burchhardt highlights some of the risks associated with email spoofing — and what Titanium Birch does to check that we've configured our domains correctly for emails.

---

We’ve been running due diligence on the various companies we interact with, including vendors and investment targets. One element of our process has been to assess a firm’s email security risks. It takes just a few seconds using tools like dmarcly.com’s DMARC checker to notice common issues in the way a company’s domain is configured with respect to emails.

We found it odd that we were seeing issues with several firms that we spot-checked, so we checked systematically: we exported the list of domains with which titaniumbirch.com exchanged emails recently and used dmarcly.com to automatically check their configuration.

Here are the results:

Our analysis showed that 50% of the firms with whom we interact were unnecessarily vulnerable to being impersonated (email spoofing), putting at risk email recipients, other firms, and their own brand value and reputation.

Our findings surprised us: they show that 34.2% of firms don’t have DKIM/DMARC enabled, and that many of those who have enabled DKIM/DMARC have it set quite loosely.

Here’s an explanation of the pie chart:

Category	Meaning
🟢 Looks good - policy set to “reject”	It’s very unlikely for any receiving email system to get fooled. Such sender domains publish a cryptographic “public key” and tell the world that any email claiming to use their name must provide proof that they possess the matching private key. And if they fail to provide that proof, the recipient’s email client should block the email from reaching the recipient.
🔴 High risk - no DMARC/DKIM at all.	Without DKIM, emails cannot provide cryptographic proof that they’re authorised to represent the domain in question. Without DMARC, receiving email clients might not perform supplementary authentication checks beyond those covered by SPF and DKIM. This makes it too easy for attackers to send emails that a recipient might assess to be valid.
🟠 Medium risk - policy set to “none”	That means the domain owners have set up a way for emails to provide cryptographic proof, but oddly they’re telling the world that “if an email fails to provide the proof, then that might be OK/expected; let the email proceed to the recipient anyway.” Why would that be? Typically this setting is used when an organisation is just starting to use these features and isn’t yet confident that all of its emails can provide the cryptographic proof.
🟡 Low risk (but a bit odd) - policy set to “quarantine”	Such domains instruct receivers to mark as spam any email that fails the cryptographic proof. Why not set it to “reject” outright to block unqualified emails from reaching the recipients?

We’re currently guiding some of those firms through fixing their email authentication configurations, specifically to publish DKIM/DMARC for their domain. We hope this blog post can call attention to the issue and get more firms to configure their systems well.

Recommendations from Google and Microsoft

Our findings are intriguing because major email providers like Google Workspace and Microsoft 365 encourage IT admins to enable DMARC and DKIM when configuring emails. Email authentication is good for security. The reasons are complex — we won’t go into them — but Google and Microsoft support these features and urge their use for good reasons.

How we check that we’ve set things up correctly

To convince ourselves we’ve set up our domain for email correctly, we use one of the many DMARC tools out there (we have a subscription to dmarcly.com).

We type our domain name into https://dmarcly.com/tools/dmarc-checker. We expect the tool to indicate that they didn’t find any obvious issues. Getting the config wrong might create email deliverability problems, and tools like dmarcly.com guide an IT admin through rolling it out in a safe way.

What’s at stake?

We sat down with Timothy Tan, a former colleague of Peter’s, to find out how difficult it is for attackers to trick a recipient’s email client into allowing an impersonated email to enter someone’s inbox. Tim is a member of Singapore’s growing community of cybersecurity experts with rich experience in email-based attacks.

Says Tim: “It’s hard to generalise, since much also depends on the configuration of the receiving party’s email system, though it’s safe to say that owners of a domain have a responsibility to configure their system in a sensible way.

“Owners of a domain have a responsibility to configure their system in a sensible way.”

— Timothy Tan

“That means having enabled technology called SPF, DKIM and DMARC. With any of those missing or misconfigured, there’s a real risk of recipients being duped into thinking that a fake email is valid.

These technologies were created to solve a real problem, and I think it’s reasonable to expect any IT admin to use them. A common mistake is only relying on SPF. That’s not enough — there are resources on GitHub explaining how to circumvent SPF for domains that don’t use DKIM-DMARC.”

In short: the risks are real. Many of the problems we described in our threat model start with email, so it’s a low-effort high-return task to set it up well.