A recent great article by BleepingComputer about domain hijacking and DMARC abuse reminded me that many companies and people do not understand DMARC well enough to understand what it does and how it helps to prevent phishing.
And look-alike and neglected domains challenge its protective value to unknowledgeable email recipients. This article is about how to understand and proactively use DMARC.
DMARC
First, a quick little intro to DMARC for readers not familiar with it. Domain-based Message Authentication, Reporting and Conformance (DMARC), Sender Policy Framework (SPF), and Domain Keys Identified Mail (DKIM) are three related global anti-phishing standards that allow email recipients to verify if an email that claims to be from a particular sending domain is really from the domain it claims.
In short, it helps to prevent email domain spoofing. For example, if an email claims to be from microsoft.com, is it really from microsoft.com? DMARC operations rely heavily on DNS from both a sender’s and receiver’s configuration and use.
Note: The acronym DMARC can refer to just the DMARC standard by itself or can refer to the collection of all three related standards. Most of the time, you can figure out how it is being used by looking at the overall context, although you may need to clarify.
Email senders can use DMARC to protect their email domains from spoofing by spammers and phishers. Email recipients can use DMARC to verify that received emails were truly sent from the domains claimed. Every organization sending or receiving email should enable all three DMARC standards for both sending and receiving.
With DMARC, email senders configure and publish their DMARC, SPF, and DKIM records (in DNS). Email receivers (e.g., email servers, email clients, mail user agents, mail transfer agents, mail delivery agents, etc.) can access those records and use them to verify emails claiming to be sent by related domains. In most cases, DMARC checks are already automatically applied to all emails received by users, whether they know it or not. Not all, but most. Email senders, however, must often proactively configure and enable DMARC, and many do not.
If you want to learn more about DMARC, you can watch my free KnowBe4 webinar on it. I even dedicate an entire must-read chapter on it in my latest book, Fighting Phishing: Everything You Can Do To Fight Social Engineering and Phishing.
If you receive an email, it will more than likely already have the outcome of one or more DMARC inspection statuses (for DMARC, SPF, and DKIM), applied to and impacting where the email is sitting in your inbox folder and also stated in plaintext in the email header. If you know how to view an email header, you will see DMARC=, SPF=, and DKIM= listed in the header along with the outcome of the related inspection. Here is an example from a partial text extraction of an email header from a legitimate email in my inbox:
The most common DMARC status check answers are PASS, FAIL, or NONE (in uppercase or lowercase), although there can be other status outcomes. PASS (or pass) means the email’s claimed originating domain was verified as accurate. FAIL means one or more of the checks failed. And you may see NONE, meaning the involved claimed sending domain did not have one or more DMARC protocols enabled. Some statuses may indicate errors or include one of the other status outcomes (i.e., pass, fail, or none) in the status label and can usually be read as being a pass, fail, or none.
Emails (good or bad) from appropriately DMARC-configured domains will usually pass all DMARC checks. An email with all three DMARC statuses marked as PASS is essentially verified as, “This email is from the domain claimed.” DMARC failures are essentially saying, “This email was not from the claimed domain”, although there are some instances due to misconfiguration or lax administration that will cause “false-positive” DMARC failures even if the email really did come from the claimed domain. Emails that fail one or more checks should automatically end up in your Spam, Trash, Junk folder, or be rejected by the involved email client or server before reaching the user.
An email with a DMARC status of NONE should be treated as untrusted although some receiving email servers/clients treat it the same as a FAIL and some treat it as a PASS.
How To Use DMARC
If an email has failed one or more DMARC checks, then you should not trust that email as coming from the claimed domain and treat it accordingly. It could be a false-positive, but it is often because the email is not from the claimed domain and is (possibly) malicious.
DMARC is a success. DMARC checks have forced most phishers to give up domain name impersonation of legitimate domains (e.g., microsoft.com, facebook.com, twitter.com, etc.). Now it is the rare phishing email that claims to be from a domain where it was not sent from…but there are three main problems to lookout for, covered below.
Look-Alike Domains
The first is look-alike domains. Phishers often create brand new domains that look like they should belong to the legitimate brand being impersonated. Here are some examples:
- com
- be.4.com
- com
None of those three domains are the valid domain names for the legitimate brands. They just sort of look like the legitimate ones. The phishers are hoping that most email receivers do not notice that the domains are not the real ones. Phishers create these fake look-alike domains by the tens of thousands a day. And some of them are fairly convincing-looking.
You can find out if your organization’s domain is being spoofed using KnowBe4’s free Domain Doppelganger tool.
The problem is that most of these look-alike domains not only look like the real domain, but also pass all three DMARC checks. That is because the phisher created the domain, legitimately owns it, and also configured the rogue domain to pass all three DMARC checks. In fact, a higher percentage of rogue domains use DMARC than legitimate domains. That is because if the phishers did not enable and use DMARC, all their malicious emails would end up in the user’s Spam folder or be rejected.
So, it is not at all unusual (i.e., it’s very common) for malicious, look-alike domains to pass all three DMARC checks. DMARC does not tell anyone whether a particular claimed domain is malicious or not. All DMARC says is “That email came from the place claimed.” No more. No less.
The way I use DMARC when I am looking at an email coming from a slightly off-brand name (e.g., droppedboxx.com) is to look and see if the email passed all its DMARC checks, and if it did, I say to myself, “Yep, that email really did come from that domain!” Then, I figure out if that claimed domain is legitimate or not.
DMARC is really useful.
The second problem is that phishers often create email addresses (known as friendly names that we see when we open an email) that often try to impersonate a brand name. For example, verifylogonbankofamericacom@hotmail.com. The email address was just something the phisher made up that had the words bankofamericacom in it hoping that some percentage of users would see it and think it said bankofamerica.com. And it works, a lot. It is important to teach yourself and others how to correctly interpret email addresses and domain names.
More importantly, DMARC does not read or care about the email address except for the domain name. The domain portion of an email address is the only thing that DMARC cares about. The PASS, FAIL, or NONE, is evaluated only on the domain name portion of the email address.
But there is a third problem popping up referenced in that BleepingComputer article I mentioned in the first sentence of this article.
Hijacked Subdomains
Legitimate organizations often let unused domains and subdomains languish. This is never good. In the article, one of the examples they give is marthastewart.msn.com. It was registered by someone for Martha Stewart in 2001. Between now and then, with its ad campaign and services no longer used, it became neglected and no longer officially registered to the legitimate party that created it.
Phishers detected this and re-registered the abandoned domain with another registrar (often using new DNS CNAME records), becoming the new owners. Viola! They own the subdomain (until someone legal for Martha Stewart gets involved). The phishers created DMARC records for it and started sending phishing emails posing as Martha Stewart. It can take days to weeks before someone who manages the Martha Stewart or MSN brands notices and understands enough of what is going on to do something about it.
Hijacked DMARC
This is even a worse abuse of trust. Phishers looked for a neglected (expired in DNS) domain previously registered by the legitimate owner in DMARC. It’s very common for legitimate brands to register two or more IP addresses or domain names in SPF as being “authorized senders” for their email. Sometimes, there can be a dozen or more. Here’s KnowBe4’s SPF record for example:
v=spf1 include:mailsenders.netsuite.com include:_spf.google.com include:mail.zendesk.com include:stspg-customer.com mx:spe.intercom.io ip4:23.21.109.212 ip4:23.21.109.197 ip4:52.49.201.246 ip4:52.49.235.189 ip4:54.172.84.90 ip4:147.160.167.0/24 ip4:168.235.226.71 ip4:168.235.226.72 ip4:168.235.226.73 ip4:168.235.226.74 ip4:168.235.233.211 ip4:168.235.233.212 ip4:168.235.233.213 ip4:192.254.121.248 ip4:167.89.63.53 exists:%{i}._spf.mta.salesforce.com -all
Each of those domain names and IP addresses listed above are allowed to send emails on behalf of KnowBe4. In KnowBe4’s case, we have many authorized senders because we send simulated phishing campaigns from many different domains, allowed marketing activities, and other allowed email operational functions. Phishers will look for forgotten, but legitimate domains that are accidentally left as an authorized sender in some legitimate brand’s SPF record. It’s easy to do.
The phisher just downloads the legitimate brand’s SPF record and then sees if each is still actively registered to the brand in DNS. They will occasionally find an IP address or domain that appears in the SPF record but is not currently registered in DNS. Then they will re-register the forgotten domain, taking ownership, and start sending phishing emails to victims posing as the legitimate brand. When a receiver’s email client or server checks to see if the received phishing email is legitimate using DMARC, it will appear to be authentic, according to the SPF record.
The lesson is organizations using DMARC must keep up with their DMARC records and make sure that what domains and IP addresses are included are still owned, authorized, and registered in DNS by the brand. All brands must keep up with what domains and IP addresses are still registered and authorized, and actively look for and handle any abandoned “orphan” domains and IP addresses. This is doubly true if that abandon remains registered in DMARC. Simple neglect can lead to trust issues with your customers.
The BleepingComputer article is excellent and goes into all the necessary technical details. Suffice it to say, these DNS and DMARC shenanigans often trick people. You must educate yourself and others about these sorts of tricks. DMARC is a great tool in fighting phishing, but it has also become a tool of the phishers. Learning how to use DMARC and what it does and does not mean is crucial to remain safe.
Remember, DMARC verifies if the email is or is not from the claimed domain. It does not determine if the origination domain is malicious or not. All it can do, if the DMARC checks are valid, is verify that, yes, the email did come from the claimed domain. After that, it is up to the user (or email checker) to determine if the email’s origination domain is legitimate or not for the claims being made.
Here's how it's done:
