Posts

As a DMARC services provider, we get asked this question a lot: “If DMARC just uses SPF and DKIM authentication, why should we bother with DMARC? Isn’t that just unnecessary?”

On the surface it might seem to make little difference, but the reality is very different. DMARC isn’t just a combination of SPF and DKIM technologies, it’s an entirely new protocol by itself. It has several features that make it one of the most advanced email authentication standards in the world, and an absolute necessity for businesses.

But wait a minute. We’ve not answered exactly why you need DMARC. What does it offer that SPF and DKIM don’t? Well, that’s a rather long answer; too long for just one blog post. So let’s split it up and talk about SPF first. In case you’re not familiar with it, here’s a quick intro.

What is SPF?

SPF, or Sender Policy Framework, is an email authentication protocol that protects the email receiver from spoofed emails. It’s essentially a list of all IP addresses authorized to send email through your (the domain owner) channels. When the receiving server sees a message from your domain, it checks your SPF record that’s published on your DNS. If the sender’s IP is in this ‘list’, the email gets delivered. If not, the server rejects the email.

As you can see, SPF does a pretty good job keeping out a lot of unsavoury emails that could harm your device or compromise your organisation’s security systems. But SPF isn’t nearly as good as some people might think. That’s because it has some very major drawbacks. Let’s talk about some of these problems.

Limitations of SPF

SPF records don’t apply to the From address

Emails have multiple addresses to identify their sender: the From address that you normally see, and the Return Path address that’s hidden and require one or two clicks to view. With SPF enabled, the receiving email server looks at the Return Path and checks the SPF records of the domain from that address.

The problem here is that attackers can exploit this by using a fake domain in their Return Path address and a legitimate (or legitimate-looking) email address in the From section. Even if the receiver were to check the sender’s email ID, they’d see the From address first, and typically don’t bother to check the Return Path. In fact, most people aren’t even aware there is such a thing as Return Path address.

SPF can be quite easily circumvented by using this simple trick, and it leaves even domains secured with SPF largely vulnerable.

SPF records have a DNS lookup limit

SPF records contain a list of all the IP addresses authorized by the domain owner to send emails. However, they have a crucial drawback. The receiving server needs to check the record to see if the sender is authorized, and to reduce the load on the server, SPF records have a limit of 10 DNS lookups.

This means that if your organization uses multiple third party vendors who send emails through your domain, the SPF record can end up overshooting that limit. Unless properly optimized (which isn’t easy to do yourself), SPF records will have a very restrictive limit. When you exceed this limit, the SPF implementation is considered invalid and your email fails SPF. This could potentially harm your email delivery rates.

 

SPF doesn’t always work when the email is forwarded

SPF has another critical failure point that can harm your email deliverability. When you’ve implemented SPF on your domain and someone forwards your email, the forwarded email can get rejected due to your SPF policy.

That’s because the forwarded message has changed the email’s recipient, but the email sender’s address stays the same. This becomes a problem because the message contains the original sender’s From address but the receiving server is seeing a different IP. The IP address of the forwarding email server isn’t included within the SPF record of original sender’s domain. This could result in the email being rejected by the receiving server.

How does DMARC solve these issues?

DMARC uses a combination of SPF and DKIM to authenticate email. An email needs to pass either SPF or DKIM to pass DMARC and be delivered successfully. And it also adds one key feature that makes it far more effective than SPF or DKIM alone: Reporting.

With DMARC reporting, you get daily feedback on the status of your email channels. This includes information about your DMARC alignment, data on emails that failed authentication, and details about potential spoofing attempts.

If you’re wondering about what you can do to not get spoofed, check out our handy guide on the top 5 ways to avoid email spoofing.

Breaking Down DMARC Myths

For a lot of people, it’s not immediately clear what DMARC does or how it prevents domain spoofing, impersonation and fraud. This can lead to serious misconceptions about DMARC, how email authentication works, and why it’s good for you. But how do you know what’s right and what’s wrong? And how can you be sure you’re implementing it correctly? 

PowerDMARC is here to the rescue! To help you understand DMARC better, we’ve compiled this list of the top 6 most common misconceptions about DMARC.

Misconceptions about DMARC

1. DMARC is the same as a spam filter

This is one of the most common things people get wrong about DMARC. Spam filters block incoming emails that is delivered to your inbox. These can be suspicious emails sent from anyone’s domain, not just yours. DMARC, on the other hand, tells receiving email servers how to handle outgoing emails sent from your domain. Spam filters like Microsoft Office 365 ATP don’t protect against such cyberattacks. If your domain is DMARC-enforced and the email fails authentication, the receiving server rejects it.

2. Once you set up DMARC, your email is safe forever

DMARC is one of the most advanced email authentication protocols out there, but that doesn’t mean it’s completely self-sufficient. You need to regularly monitor your DMARC reports to make sure emails from authorized sources are not being rejected. Even more importantly, you need to check for unauthorized senders abusing your domain. When you see an IP address making repeated attempts to spoof your email, you need to take action immediately and have them blacklisted or taken down.

3. DMARC will reduce my email deliverability

When you set up DMARC, it’s important to first set your policy to p=none. This means that all your emails still get delivered, but you’ll receive DMARC reports on whether they passed or failed authentication. If during this monitoring period you see your own emails failing DMARC, you can take action to solve the issues. Once all your authorized emails are getting validated correctly, you can enforce DMARC with a policy of p=quarantine or p=reject.

4. I don’t need to enforce DMARC (p=none is enough)

When you set up DMARC without enforcing it (policy of p=none), all emails from your domain—including those that fail DMARC—get delivered. You’ll be receiving DMARC reports but not protecting your domain from any spoofing attempts. After the initial monitoring period (explained above), it’s absolutely necessary to set your policy to p=quarantine or p=reject and enforce DMARC.

5. Only big brands need DMARC

Many smaller organizations believe that it’s only the biggest, most recognizable brands that need DMARC protection. In reality, cybercriminals will use any business domain to launch a spoofing attack. Many smaller businesses typically don’t have dedicated cybersecurity teams, which makes it even easier for attackers to target small and medium-sized organizations. Remember, every organization that has a domain name needs DMARC protection!

6. DMARC Reports are easy to read

We see many organizations implementing DMARC and having the reports sent to their own email inboxes. The problem with this is that DMARC reports come in an XML file format, which can be very difficult to read if you’re not familiar with it. Using a dedicated DMARC platform can not only make your setup process much easier, but PowerDMARC can convert your complex XML files into easy-to-read reports with graphs, charts, and in-depth stats.

 

Email is often the first choice for a cybercriminal when they’re launching because it’s so easy to exploit. Unlike brute-force attacks which are heavy on processing power, or more sophisticated methods that require a high level of skill, domain spoofing can be as easy as writing an email pretending to be someone else. In a lot of cases, that ‘someone else’ is a major software service platform that people rely on to do their jobs.

Which is what happened between 15th and 30th April, 2020, when our security analysts at PowerDMARC discovered a new wave of phishing emails targeting leading insurance firms in the Middle East. This attack has been just one among many others in the recent increase of phishing and spoofing cases during the Covid-19 crisis. As early as February 2020, another major phishing scam went so far as to impersonate the World Health Organization, sending emails to thousands of people asking for donations for coronavirus relief.

In this recent series of incidents, users of Microsoft’s Office 365 service received what appeared to be routine update emails regarding the status of their user accounts. These emails came from their organizations’ own domains, requesting users to reset their passwords or click on links to view pending notifications.

We’ve compiled a list of some of the email titles we observed were being used:

*account details changed for users’ privacy

You can also view a sample of a mail header used in a spoofed email sent to an insurance firm:

Received: from [malicious_ip] (helo= malicious_domain)

id 1jK7RC-000uju-6x

for [email protected]; Thu, 02 Apr 2020 23:31:46 +0200

DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;

Received: from [xxxx] (port=58502 helo=xxxxx)

by malicious_domain with esmtpsa (TLSv1.2:ECDHE-RSA-AES2  56-GCM-SHA384:256)

From: “Microsoft account team” 

To: [email protected]

Subject: Microsoft Office Notification for [email protected] on 4/1/2020 23:46

Date: 2 Apr 2020 22:31:45 +0100

Message-ID: <[email protected]>

MIME-Version: 1.0

Content-Type: text/html;

charset=”utf-8″

Content-Transfer-Encoding: quoted-printable

X-AntiAbuse: This header was added to track abuse, please include it with any abuse report

X-AntiAbuse: Primary Hostname – malicious_domain

X-AntiAbuse: Original Domain – domain.com

X-AntiAbuse: Originator/Caller UID/GID – [47 12] / [47 12]

X-AntiAbuse: Sender Address Domain – domain.com

X-Get-Message-Sender-Via: malicious_domain: authenticated_id: [email protected]_domain

X-Authenticated-Sender: malicious_domain: [email protected]_domain

X-Source: 

X-Source-Args: 

X-Source-Dir: 

Received-SPF: fail ( domain of domain.com does not designate malicious_ip_address  as permitted sender) client-ip= malicious_ip_address  ; envelope-from=[email protected]; helo=malicious_domain;

X-SPF-Result: domain of domain.com does not designate malicious_ip_address  as permitted sender

X-Sender-Warning: Reverse DNS lookup failed for malicious_ip_address (failed)

X-DKIM-Status: none /  / domain.com /  /  / 

X-DKIM-Status: pass /  / malicious_domain / malicious_domain /  / default

 

Our Security Operation Center traced the email links to phishing URLs that targeted Microsoft Office 365 users. The URLs redirected to compromised sites at different locations around the world.

By simply looking at those email titles, it would be impossible to tell they were sent by someone spoofing your organization’s domain. We’re accustomed to a steady stream of work or account-related emails prompting us to sign into various online services just like Office 365. Domain spoofing takes advantage of that, making their fake, malicious emails indistinguishable from genuine ones. There’s virtually no way to know, without a thorough analysis of the email, whether it’s coming from a trusted source. And with dozens of emails coming in everyday, no one has the time to carefully scrutinize every one. The only solution would be to employ an authentication mechanism that would check all emails sent from your domain, and block only those that were sent by someone who sent it without authorization.

That authentication mechanism is called DMARC. And as one of the leading providers of email security solutions in the world, we at PowerDMARC have made it our mission to get you to understand the importance of protecting your organization’s domain. Not just for yourself, but for everyone who trusts and depends on you to deliver safe, reliable emails in their inbox, every single time.

You can read about the risks of spoofing here: https://powerdmarc.com/stop-email-spoofing/

Find out how you can protect your domain from spoofing and boost your brand here: https://powerdmarc.com/what-is-dmarc/