top of page
  • OpaCyber

Why your outbound email security sucks and what you can do about it - part 5

So we’ve looked at setting up your outbound email to be in compliance, using SPF, Dkim & Dmarc but here are a few real-world examples of what happens when organisations don’t get it right


Here’s a received email with a faulty SPF record with analysis using MS Defender:

Defender sees this email as a phish:

Action: blocked; reason: Defender thinks the email is spoofed:

Oh dear, absolutely nothing going well here: 🤦‍♂️

We used a tool to examine the actual SPF record for the sender and it looks like this:

If we analyse that:

  • v=spf1. Correct. There’s only one “V” so it’s always spf1

  • mx. Not needed (for this particular record)

  • That’s fine. It means they are using Microsoft 365

  • Skip this next value for a minute

  • Looks OK. Appears to be a mailing-list application like Mailchimp, Sendgrid etc

  • -all. Perfect

*The value we skipped and obfuscated ( would be VERY weird) looks like it was a mail server used before MS365 was implemented, so should have been removed. So is that what is causing the problem with the Permanent Error then?

Using another tool we get the answer:

“Test: SPF Record Null Value”. “Result: A null DNS lookup was found for include (”

That one value doesn’t resolve, therefore it’s an invalid SPF value, which makes THE WHOLE SPF record invalid! (so it will be ignored, as if there wasn’t one there at all)

This email is from an organisation who would like to be paid for something. Not exactly helping yourselves, are you? 🤦‍♂️


Here’s analysis of a received email where Dkim doesn’t align. We chose this example because this is a VERY common problem:

This sender is using MS365. Microsoft include a default Dkim record but it is for the TENANT domain not the VANITY (registered) domain

To explain: when you create a MS365 account you are given the option of what you wish to call it (and it has to be available within the Microsoft system)

Say, for instance, you start a company called “Bob’s Widgets” and you register a domain with a hosting provider call “bobswidgets[.]com”

When you create a MS365 tenant you can, if it’s available, choose bobswidgets as well but in the Microsoft system the domain will be bobswidgets[.]onmicrosoft[.]com

During the set up process of MS365 the VANITY (registered) domain (“bobswidgets[.]com”) can be added

The thing that is not well documented, and therefore many organisations don’t do it, is that a Dkim record (or two, actually, for MS365) should be added for the Vanity domain


Although there are many examples we could show you of improper Dmarc setup, we went for this one as despite seeing hundreds of thousands of DNS records we believe this is a first 🤦‍♂️

First, let’s look at what was received:

In spam filtering the message says: “Failed to get DMARC data for this message. Reason: unknown”

OK, so the rest of the results show that SPF and Dkim were authenticated but alignment failed. This is because the email is being sent by a mailing list provider (think Mailchimp, Constant Contact, Sendgrid etc). Using that type of sender is fine as far as it goes but this organisation is going to have problems next year (that’s a teaser for another post in the New Year 😉) as it is not set up correctly

Looking at the same message in MS Defender we see much the same error message "Dmarc Permanent Error"

What on earth?...

Time to use Terminal to investigate 🔬🔍

This is the SPF record:

This is fine, technically. It does mean that this actual domain can't send "regular" email because the "-all" value is usually set AFTER the allowed senders and indicates "any other sender - fail". In this case it is probably OK as the organisation might only be sending email via the mailing list service

HOWEVER, this is where the proverbial wheels fall off 🤦‍♂️

This is the Dmarc record:

Notice anything? The Dmarc record has the same value as the SPF record, so it's not a Dmarc record at all 🤦‍♂️

This from a MAJOR online provider of travel and hotel bookings...

That's the last in the series on email settings for "regular mail". Watch out for something in the New Year that's going to cause some serious issues for A LOT of email senders 😱

Previous post, Dmarc:


bottom of page