Preface
Work sent out an email this week. Phishing attempts were up. Fake emails with weird reference numbers, PDF attachments, links to "secure files." The usual stuff. Don't click, call to verify, forward to IT.
I read it, nodded, moved on.
But one line stuck with me. It said if an account gets compromised, attackers could use our real email address to target other companies. Not just us. Other people too, using our name.
So I started wondering. If someone wanted to send an email pretending to be us, could they?
Turns out there's a way to check. And you don't need any special access to do it.
Show Original
Every email you get has a hidden layer underneath it. Click the three dots on any message in Gmail, hit "Show Original," and you get a wall of technical text. Most people never see this. It's the stuff mail servers say to each other behind the scenes, basically a paper trail proving where an email actually came from.
I opened one of our normal work emails and looked.
Three things matter here. SPF, DKIM, and DMARC. Think of them as three different ways of proving "yes, this email really came from who it says it did."
SPF passed. DKIM passed. Good signs.
Then DMARC. Also passed. But next to it, in parentheses, sat this:
p=NONE
What That Actually Means
DMARC isn't just a pass or fail check on one email. It's also a policy, a standing instruction telling other mail servers what to do if an email fails the check. Something like "if this fails, reject it" or "if this fails, send it to spam."
p=none means the instruction is: do nothing. Log it, maybe, but deliver it anyway.
So if someone sends an email that fails every check, an email that is clearly not from us, pretending to be from us, the policy currently says let it through.
That's the gap. Not "someone is doing this right now." Just, the door is unlocked.
Following the Trail
I wanted to know more. Where does our domain's setup actually live? Who controls it?
$ dig SOA ourdomain.org
;; ANSWER SECTION:
ourdomain.org. 2560 IN SOA ns1.somehost.example. hostmaster.ourdomain.org.
One command, and there it is. A hosting provider I'd never heard of. Something left over from years ago, probably whoever built the original website, long before email moved to its current home.
A couple more lookups confirmed the rest:
$ dig TXT ourdomain.org
;; ANSWER SECTION:
ourdomain.org. 14400 IN TXT "v=spf1 include:_spf.google.com ~all"
$ dig TXT _dmarc.ourdomain.org
;; ANSWER SECTION:
_dmarc.ourdomain.org. 14400 IN TXT "v=DMARC1; p=none;"
The first one is correctly pointed at the right servers. The records prove we are who we say we are. Everything checks out, except that second one, still sitting on "do nothing."
Is This a Big Deal?
Not really. Nobody got hacked. Nothing is actively broken. This isn't the phishing emails landing in everyone's inbox, that's a separate problem, solved by the usual stuff, don't click links, verify by phone, report it.
This is just a setting. One that's been sitting on the default "off" position, probably since whoever set it up years ago never came back to finish the job. That happens. A lot of orgs have this exact gap and never know it.
But "not a big deal" and "not worth fixing" aren't the same thing. The fix is free. It's one line in a settings panel. And it closes a door that, right now, is just sitting open.
Why I'm Writing This Down
I didn't find this because I have special access or some security tool. I found it because I was curious, and curiosity plus a terminal will get you pretty far.
That's kind of the whole point. Most people assume the technical stuff behind email is some locked box only IT can see into. It's not. It's mostly just text, sitting right there, if you know where to look.
Sometimes that's all curiosity is for. Not to fix everything yourself. Just to notice the thing, write it down clearly, and hand it to someone who can.