Sender Policy Framework

What happened here was, first of all, a somewhat targeted email arriving.

Luckily, the email was detected by anti-malware and also would have, uh, been blocked by, well, your usual DKIM and SPF, uh, precautions which, uh, the sender domain had enabled properly.

But where it got interesting was when Jan actually analyzed the malware itself.

There are two components to the malware that are playing together.

It depends on your three things.

So SPF, DKIM, and DMARC.

So Center Policy Frameworks, which essentially, are you allowed to send mail? Domain Keys, Identified Mail, that's DKIM.

So Cryptographic Signature, which proves you're real.

Finally, a TXT record is a notes field attached to your domain that other systems can read.

It's become the workhorse of verification, and the email authentication records from the five forces, SPF and DMARC, are among them, and they live there.

Episode 11 writes those records.

Today, you just need to recognize where they live.

Adding a little to the trying to figure out what's real or not, one of the ways about the way they phished coming through a known and validated provider meant that these phishing emails completely passed DKIM.

You know, their DMARC and SPF, they had all the right markings because this Brevo connection was a legitimate one.

So, you know, that just makes it harder to find certain types of advanced phish when they're actually taking, uh, control of your own infrastructure through really an identity issue, a credential issue, but one that was exposed through SSO.

So def- I'm, I'm glad that even our original analyst would notice this was a phish email so long ago.

I would leave it where it already is, because putting your authoritative DNS on the same single server as your mail means one outage takes out both.

Five records: type name value Y your server IP the forward half of reverse DNS MX, priority ten, where inbound mail goes TXT SPF TXT or DKIM public key DKIM text mark the last three are where the real work is, and they get their own sections below.

One note on Cloudflare if you use it, the A record must be DNS only, gray cloud, not proxied.

Proxying it breaks mail entirely, because the world would resolve to Cloudflare's IPs rather than yours, and your PTR would no longer match anything.

Now the actual work starts.

The scoreboard, mail-tester.com gives you a throwaway address, you send a message to it, and it grades what arrives out of ten.

It is the fastest feedback loop in this discipline, and it checks roughly: Does your IP have a PTR record, and does that name resolve back to the same IP? Does the domain publish SPF, and does your sending IP pass it? Is the message DKIM signed, and does the signature verify? Does the domain publish DMARC, and does SPF or DKIM align with the from header? Is your IP on any blocklist? What does SpamAssassin think of the content? The trap is that these look like six independent items and they are not.

Four of them are the same fact stated four times, and if you treat them separately you will fix them one at a time forever.

Email now requires proof of identity.

The major mailbox providers, Google and Microsoft among them, now expect senders to authenticate their email using published standards with intimidating names and, well, their acronyms, SPF, DKIM, and DMARC.

In plain terms, these are records you publish alongside your domain that let receiving servers confirm a message really came from you.

Without them, legitimate mail, your invoices, your receipts, your newsletters, lands in spam, and or it vanishes entirely.