The IT Nerd

I have a pair of domains that I use for my business. There’s theitnerd.ca which is what I use for email and my website. And there’s itnerd.blog which strictly hosts my blog. That’s on top of the domain that my wife and I use for our personal email. I have been concerned for a while about someone spoofing me and my company and causing repetitional harm to my business or personal life as a result. Which is why I have been wanting to implement DMARC to stop that from happening. Now I’ve been kicking that can down the road until two things happened. The first is that I got a spoofing attack recently from someone who was pretending to have hacked my email in order to extort money from me. In fact, I have written about this sort of scam email here. But since I write about this stuff all the time, it along with the 80 copies of said email got deleted almost instantly as I recognized what it was and took the correct action as a result. But that episode showed that I could be spoofed by a threat actor. Which was of course a bad thing. The second thing was this report from Valimail about a North Korean spoofing attack where the North Koreans were taking advantage of people in my situation. That really got me to move on implementing DMARC because business email compromise as well as phishing are huge problems at the moment. And I don’t want to be part of the problem.

Now before I tell you what I did to address this, I want to explain what DMARC is and why anyone who has a domain that sends and receives email should care:

Domain-based Message Authentication Reporting & Conformance or DMARC is an email security protocol. DMARC verifies email senders are who they say that they are. And you as the sender can set things up to have receivers of emails do one of three things with any email that comes in that fails DMARC verification:

• If an email fails DMARC verification, then do nothing other than report that it failed.
• If an email fails DMARC verification, then quarantine it.
• If an email fails DMARC verification, then reject it.

If you really want to go into the weeds on DMARC, click here to do so. The point of DMARC is to make sure that spoofed email never makes it to the inbox. Because any email that is spoofed is a hit to your online reputation. Or it leaves you open to things like the CEO email Scam or other forms of business email compromise. But the most important reason to implement DMARC is that by not doing so, it will make it harder to send people and companies legitimate emails to them. On top of all of that, Google and Yahoo are requiring DMARC to be implemented on the domains that send them email. And that’s likely to become a common thing with other organizations in the coming months and years. Meaning that if you own a domain, DMARC is a today problem for you.

Now in most cases, you may already have a DMARC policy set up in your domain name server (DNS) records as I did. But chances are that it will likely do next to nothing for you. I will use my domain as an example of this so that you can see what I mean. Here’s the DMARC records that I started out with:

The important thing to note is the “p=none” part. The “p” stands for policy. And while simply having it set to “none” meets the minimum requirements of DMARC that Google and Yahoo stipulate, it does next to nothing to stop the issues that I highlighted above. This is where I started my journey. And it was a bit bumpy from start to finish.

I started with my hosting provider to see if they could assist me. But their tech support people had no clue how to implement DMARC in a way to protect my domain from spoofing and the like. That forced me to do a fair amount of research on my own to figure out what I needed to do. Which often led to contradictory information that I had to sort through. After a few days of doing research and figuring out what was valid information and what was bogus information, I came up with this DMARC policy (click to enlarge):

You’ll notice that this is a whole lot more expansive. Here’s what’s changed:

• I now have p=quarantine along with sp=quarantine. What that means that it is directing the receiver of any email claiming to come from my domain or any sub domain that I have to quarantine any email that fails the DMARC check. Now if I were really strict, I would go for the reject option. But my logic at the time, which I will admit that I am currently rethinking for reasons that I will get to in a minute is that at suspect emails won’t make it to the inbox. Thus quarantine is fine.
• You’ll also notice an “rua” and “ruf” entry with a redacted email address. These are tags that are designed for reporting what’s going on in terms of email being received by other domains. Google for example. Here’s the detail on those two tags:
  • The “rua” tag is for aggregate data reports. The best way to explain that is that these are reports that say “this server connected to me saying that it was you and it passed or failed a DMARC check” at a very high level.
  • The “ruf” tag is for message-specific forensic information that is to be reported to you. As in a specific email had an issue and the receiving server is reporting on it in detail. I will admit that I am rethinking using this for reasons that I will get to in a minute.

As for the redacted email addresses, that’s the email addresses where the reports will be sent to.

Now, let’s talk about the reports that I mentioned earlier. They show up in your inbox in xml format that isn’t human readable. To solve that problem, I use the MX Tools DMARC Report analyzer which makes these reports human readable. That way I have visibility into what’s going on from an email perspective. And I set aside a few minutes every day to read these reports. I admit that it’s bit time consuming. But it ensures that I don’t find out about my bad news from CNN so to speak.

As an aside, the above is not meant to be a how to guide. I’m offering this up to help to illustrate the process of implementing DMARC. If you’re planning on doing this, you should seek professional assistance from an expert on the subject if you are not sure how to proceed.

Clearly, this is a lot of work. And I had to do versions of this for not only both my business domains, but my personal one as well. And I wished at the time that there was some sort of best practise guide or something similar that would have made it easier for me to do this. Then it dawned on me that I can’t be the only person who has this challenge. Thus I decided to reach out to DMARC experts Valimail as I had been writing about them for some time on this very topic. At the same time I could run my DMARC setup by them as they are the experts in DMARC and see what I could improve on as I admit that I kind of YOLO‘ed this. The result of that request was that Valimail or more accurately Seth Blank the CTO of Valimail was kind enough set aside some time for me to flesh out what DMARC is and why you should care, along with having a quick look at my setup.

Now I’ve already covered the what DMARC is and why you should care part above. But during our discussion, I asked him what the best practise in terms of a DMARC policy is as I could not find a straight answer on that. His answer is that in short, your DMARC policy should be set to reject any email that doesn’t come from your domain. However quarantine works as well because emails will not be hitting the inbox as well. And if emails are not hitting the inbox and being routed to being put into quarantine, people are more likely to take a more critical look at what’s in there. Or to put it another way, the receivers of your email are less likely to get compromised by a threat actor. Now using the quarantine policy is one of the things that I am rethinking at the moment as I am now toying with the idea with switching to the reject policy. That I am going to take a wait and see approach on my personal and company domains based on what’s in the reports that get sent to me. Though, on my itnerd.blog domain, I made the switch to the reject policy as I don’t send or receive email from that domain at all. Thus if anyone gets an email that ends in “@itnerd.blog”, it’s guaranteed to be a spoofed email. Making the reject policy the right choice. The other thing that Mr. Blank pointed out is that I have a “ruf” tag in my DMARC setup. The potential problem with that tag is that I am going to get reports about specific emails that have issues, and they may have information in those reports that potentially violates the GDPR. Also, the reports that this tag enables goes deep into the weeds. And chances are that going deep into the weeds will not be required 99% of the time. So I’ll be removing this tag later today.

The one thing that Mr. Blank emphasized to me was that besides brand protection and stopping things like spoofing and business email compromise is the fact that implementing DMARC properly can increase the deliverability of emails to your recipients. Mr. Blank cited the HMRC in the UK and its battle with fraudsters. Prior to implementing DMARC, fraud using the HRMC domain was out of control. And legitimate HMRC emails were not making it to the inbox. But after implementing DMARC, this happened:

HMRC was able to reduce spoofing by half a billion emails, which is fantastic. But we also improved delivery rates of genuine emails from 18% to 98%, all through the implementation of Dmarc. Nothing extra – the very same thing that reduced the spoofing also increased the delivery of genuine emails.

Now nobody should expect that stunning result by implementing DMARC, but as Mr. Blank put it, implementing DMARC reduces the noise. And forces threat actors to change their tactics as a domain with DMARC that is properly implemented is simply not as vulnerable to spoofing or business email compromise. At the same time, your legitimate emails are much more likely to hit the inbox. Meaning your communications are more likely to be seen and more likely to be effective. Thus implementing DMARC is unquestionably a worthwhile exercise.

Here’s the bottom line. If you own a .com, .ca, .biz or some other domain, you should be looking at setting up DMARC. It’s going to make sure that your emails are more likely to reach their intended recipients. And it’s going to ensure that your online reputation remains intact. Both of which are very good things.

I’d like to thank Seth Blank of Valimail for his time in terms of researching this story and his guidance in terms of getting my DMARC setup right.

This entry was posted on May 16, 2024 at 9:07 am and is filed under Commentary with tags DMARC, Valimail. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.