score // can they spoof your email

can a stranger email your boss "from" you?

yeah. probably. right now, without hacking anything, without stealing a password, someone could send an email that shows up in an inbox looking like it came straight from yourdomain.com. no breach required. it's just how email was built back in the 80s, when nobody thought about strangers lying about who they are. spoiler: strangers lie about who they are constantly.

the fix for this has existed for almost 20 years. it's called spf, and most domains still don't have it set up right. let's check yours.

the one line command

dig +short TXT yourdomain.com | grep spf

swap in your actual domain. here's what each piece is doing:

dig is a tool that asks the internet's phone book (dns) questions about a domain. it's built into basically every mac and linux box, and it's on windows too if you use wsl.

+short tells dig to skip the wall of technical output and just give you the answer, nothing else.

TXT yourdomain.com asks dns for the TXT records on your domain. TXT records are just free text fields domain owners can fill in for all kinds of verification purposes, spf being one of them.

| grep spf takes all the TXT records that come back and filters down to just the one that mentions spf, since a domain can have a bunch of unrelated TXT records for other services.

run it. if something comes back that starts with v=spf1, you have a record. if nothing comes back, you don't, and that's the problem.

what spf actually does

spf stands for sender policy framework. think of it as a guest list you publish for your own domain. it says "here are the mail servers allowed to send email claiming to be from me, anyone else is lying."

a real spf record looks something like this:

v=spf1 include:_spf.google.com ~all

that's saying "google's mail servers are allowed to send as this domain, everything else should be treated with suspicion." the ~all or -all at the end matters a lot. ~all is a soft fail, it tells receiving servers to be suspicious but still might deliver it. -all is a hard fail, it tells them to reject it outright. a lot of domains set up spf, get lazy, and leave it soft, which is like installing a lock and leaving it unlocked.

why this matters even if you're "not a target"

without spf, anyone can craft an email that says it's from billing@yourdomain.com and send it to your clients, your employees, or your family asking for a wire transfer, a password reset, whatever. the receiving mail server has no way to verify it's fake because you never told it what to check.

this is the exact mechanism behind most business email compromise scams. it doesn't require breaking into your accounts. it just requires your domain not having a guest list.

fixing it

if the dig command came back empty, here's what to do:

log into whatever dashboard manages your dns, that's usually your domain registrar or a service like cloudflare. add a new TXT record for your root domain with a value like:

v=spf1 include:_spf.yourprovider.com -all

swap "_spf.yourprovider.com" for whoever actually sends your mail, google workspace, outlook, your hosting company's mail server, etc. if you use more than one sending service, they all get included in the same record. don't publish two separate spf records, dns will ignore all but one and you'll be confused later wondering why it's not working.

once it's live, wait a bit for dns to propagate and rerun the dig command to confirm it stuck.

spf alone isn't the whole story either. pair it with dkim (which cryptographically signs your outgoing mail) and dmarc (which tells receiving servers what to actually do when spf or dkim fail, like quarantine or reject). you can check those with similar dig commands against _dmarc.yourdomain.com. spf without dmarc is a rule nobody's enforcing.

the takeaway

one line in a terminal tells you if your domain is an open door for spoofed email. no scanning tools, no accounts needed, just dig and your own domain. if it comes back empty, that's not a hypothetical risk, that's an active gap someone could be using right now. go check it, fix the record, then check dkim and dmarc while you're in there. fifteen minutes of dns work closes a door that scammers walk through every single day.