PSA: Protect Your Email with DMARC

In the last few months, I’ve seen an uptick in spoofed emails being sent with my own personal email domain. Not only is this extremely annoying, but more problematic is that recipients receive spam and phishing emails from what seems to be my personal mail account, simply by spoofing the from address. I don’t know why domain and email address has been “chosen” for this, but I guess this is fallout from the LinkedIn breach way back in 2012.

I didn’t think there was much I could do about this, but a recent tweet by my friend Per Thorsheim sent me down the rabbit hole.

So, obviously there are options available to me that I was completely unaware of. I haven’t managed any public facing email services for 6-7 years, so I’ve not kept up with whatever has been happening in that particular space. Also, my personal email domain has been hosted by Google since 2008, so I haven’t really managed that either. Set and forget, right? Well, not quite.

So, what is this DMARC thing? It stands for Domain-based Message Authentication, Reporting & Conformance, and is a way to try and validate that emails from a given domain is being sent using one of the valid mail servers configured for that domain. In order to be able to use DMARC, you first need to first have Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) configured for you domain.

Here are the resources I used to get all of this configured for my domain:

  1. Configure SPF records to work with G Suite
  2. Authenticate email with DKIM
  3. Add a DMARC record

Less than 24 hours after configuring everything, I received my first DMARC Aggregate Report which is basically an XML file showing what has been going on.

Since this file is a bit hard to read on it’s own, I uploaded it to DMARC Analyzer, and even though I knew a lot of email was being send with my email address as the reply to address, I was quite surprised to see that in less then 24 hours after I set up the DMARC DNS records, a total of 295 emails had been rejected by mail servers all over the world, most of them sent from mail servers in Vietnam. I do not send 295 emails a day with my personal email account, and absolutely none of them from Vietnam. In fact, during the time-frame of this initial aggregate report, I sent zero emails – as seen in the screenshot from the report.

I have now configured my DMARC DNS txt records to send emails directly to  DMARC Analyzer, and I’m looking forward to seeing how these numbers add up over time. I’m currently on a free trial plan, and looking to evaluate which of the available DMARC Analyzers out there I want to use permanently.

At least now receiving email servers have a fighting chance of rejecting fake emails from my domain, since it’s now possible to verify that they are sent through a valid source.

Even if you don’t have problems with someone spoofing your email addresses, please spend 10 minutes configuring this for your domain as well. You never know when something like this might occur, and it’s better to build your defences before you get attacked. That way you stand a chance of stopping it before it gets as ugly as it did in my case.

And Per, you are a gentleman and a scholar. Even if I did manage to investigate and set this up on my own, cake and coffee is still on me!

VMware vSAN 6.6 – What’s New for Day 2 Operations?

VMware has just announced vSAN v6.6, with over 20 new features. While new and shiny features are nice I’d like to highlight a couple that I think might be undervalued from release feature-set perspective, but highly valuable in day to day operations of a vSAN environment, otherwise known as Day 2 operations.

vSAN Configuration Assist is one such new feature. While it’s true that it helps first time configuration of a greenfield installation with vSAN (no more bootstrapping, yay!), it also helps with Day 2 operations.

It helps configure new hosts added to an existing vSAN enabled cluster, but it also makes it possible to automate updating of IO controllers, both firmware and drivers directly from within vCenter. As everyone should know by now, vSAN is highly dependent on drivers and firmware being on supported levels. This improvement helps the improved vSAN Health Check (Enhanced Health Monitoring) alert you when new and verified drivers/firmware are available, and if the controller tools are available on the ESXi host, it can also update the firmware for you.

Directly from vCenter, utilising maintenance mode like you’re used to from patching your ESXi hosts from VMware Update Manager (even if it’s not integrated into VUM at this point).

This new features takes the vSAN HCL list to a new level, it’s no longer just a list over supported IO controllers and their firmware and drivers, it’s a now also a software distribution point. At the moment Dell EMC, Fujitsu, Lenovo and SuperMicro are all supported vendors for this new distribution model, hopefully the rest will follow suit quickly.

The second feature I would like to highlight as a Day 2 operations enhancement, is the new vSAN Cloud Analytics feature. If you participate, in the Customer Experience Improvement Program (CEIP), it will enable custom alerting for your environment, based on your own environment. For instance, if a new Knowledge Base article is published, that pertain to your specific setup, it will alert you about it. One example might be if you have Intel X710 NICs, which can cause PSODs — Wouldn’t it be nice if you got alerted that this might be an issue, and then told how to remediate it? Well, with vSAN 6.6 you’ll get exactly that.

With vSAN 6.6 you get both automated, and verified, firmware/driver upgrades, as well as proactive alerting for potential issues through the hive-mind that is the analytics service. This is what VMware calls Intelligent Operations and Lifecycle Management in this release, and it’s really hard to argue with that.

Of course, vSAN 6.6 provide other Day 2 Operations enhancements as well, like Degraded Device Handling (DDH), Simplified Stretched Cluster Witness replacement procedures, Capacity and Policy Pre-Checks and access to the vSAN control plane trough the ESXi Host Client, but I’ll leave those for later posts.

Cross vCenter VM Mobility Fling – macOS?

Fatal error: Call to private method CodeColorer::performHighlightCodeBlock() from context '' in /home/ on line 55