Can anyone send email that looks like it came from your domain?

A stranger types [email protected] into the From field of an email they wrote on a server you've never heard of. Does it land in your customer's inbox looking, in effect, signed by you?

For most domains that have never thought about it, yes. Your test email arrived, customers get their receipts, email works, and you moved on months ago. But the protocol that decides whether a given server is allowed to use your domain is opt-in, and the default is wide open. If you never published the record that says "only these servers send my mail," then every server on the internet is on the list.

What a stranger actually does

Sending mail that claims to be from [email protected] takes about as much effort as sending a normal email. The From header is just a string the sender writes. There is nothing in the base email protocol that checks whether the server typing it has any right to your domain. A scammer spins up a cheap relay or uses any of the ready-made phishing kits, sets the envelope and header to your domain, writes "your invoice is overdue, update your card here," and presses send.

The only thing standing between that message and the inbox is whether the receiving mail server bothers to ask: does yourdomain.com publish a list of who's allowed to send for it? That list is the SPF record. It's a single TXT record in your DNS.

If you don't have one, the receiving server has nothing to check against. It can't tell a forgery from a real receipt, so it leans toward delivering. Your customer sees a perfectly spelled sender, no typo to catch, your name in the header, and a link.

What an SPF record is, exactly

SPF stands for Sender Policy Framework, and it is one line of text. It lives at the root of your domain as a TXT record and names the servers and services allowed to send mail using your domain. A typical one looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net -all

Read it left to right. v=spf1 declares the version. Each include: pulls in the sending servers for a service you actually use, Google Workspace and SendGrid here. The piece that does the real work is at the end. -all means "everything not listed above fails, reject it." That hyphen is the whole point.

Two ways to get this wrong, and the scanner flags both. The first is having no SPF record at all, in which case receivers have nothing to enforce. The second is publishing +all, which says "anything passes," and is somehow worse than nothing because it looks deliberate. People paste +all while debugging delivery and forget to change it back. The record is there, it's just waving every server through.

A softer ending, ~all, means "soft fail, accept but mark suspicious." It's a reasonable place to pause while you confirm your sender list, then you tighten it to -all.

Why this connects to your other DNS records

SPF on its own tells receivers who may send. It does not tell them what to do when a message fails, and it doesn't survive forwarding cleanly. That's the job of DMARC, which sits on top of SPF and turns "this failed" into an actual instruction. A lot of domains publish SPF, feel covered, and never notice that their DMARC policy is set to p=none and enforces nothing. The two work as a pair: SPF says who may send, DMARC says what to do when something fails the check. Publish only the first and you've named the rule without anyone to act on it.

How to check, then fix

You don't need any access to your mail server to check this. SPF is public DNS, readable by anyone, which is exactly why an attacker can read it too. From a terminal:

dig +short TXT yourdomain.com

Look for a line starting v=spf1. If nothing comes back, you have no SPF record. If you see +all anywhere in it, that's an open relay policy. Either way, mail can be spoofed as you today.

; no record at all, or worse:
yourdomain.com.  TXT  "v=spf1 +all"
; +all = every server on earth may send as you

The fix is to publish a TXT record that includes the mail services you genuinely use and ends in -all. List every sender. If you send transactional mail through SendGrid, marketing through Mailchimp, and staff mail through Google, all three need to be in there or your own legitimate mail starts failing. Get the list right, set the hard -all, and the forgeries stop having a clear path.

SurfaceCheckr reads your SPF record the same way a receiving mail server does, from the outside, with no access to your DNS panel or your mailbox. It tells you whether the record exists, whether it ends in a hard fail, and whether you left +all sitting there. It can't send mail as you to prove the point, and it won't, but it sees the exact gap an attacker would use. Once you've closed SPF, the next thing worth reading is what p=none in your DMARC record actually permits.