three DNS records that stop email spoofing

hook: your domain can be worn like a mask

someone can send an email that says it's from your domain, land in a real inbox, and your servers never get touched. that's the part people don't get about email spoofing. it's not a hack of your system, it's an abuse of a protocol that was never designed to check who's actually talking. the fix isn't fancy security software, it's three dns records that most domains still don't have set up correctly.

spf: the guest list

spf (sender policy framework) is a dns record that lists which mail servers are allowed to send email claiming to be from your domain. when a receiving server gets a message "from" you, it checks your spf record to see if the sending server is on the approved list.

the record looks something like this:

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

the important part is the ending. -all means "if it's not on this list, reject it." a lot of domains use ~all (soft fail) which basically says "eh, flag it as suspicious but let it through anyway." that's the setting attackers love, because it does almost nothing. if you're setting this up, go with -all once you're confident you've listed every legit sending source (your email provider, your marketing tool, your crm, all of it).

dkim: the signature

spf checks the server, dkim checks the message itself. dkim (domainkeys identified mail) attaches a cryptographic signature to every email you send, generated with a private key your mail provider holds. the public key lives in your dns as a txt record. the receiving server pulls that public key, verifies the signature, and confirms the message wasn't altered in transit and actually came from a server holding your private key.

without dkim, an attacker could technically pass spf checks (rare, but possible with lookalike setups or compromised infrastructure) and still tamper with content. dkim closes that gap by signing the message content itself. most email platforms (google workspace, microsoft 365, sendgrid, etc.) generate this for you, you just have to actually turn it on and publish the record. this step gets skipped constantly because it's "optional" until it isn't.

dmarc: the enforcement policy

here's the part almost everyone misses. spf and dkim exist, but without dmarc, nothing tells the receiving server what to actually do when a message fails those checks. dmarc (domain-based message authentication, reporting and conformance) is the policy layer. it says "if a message claiming to be from my domain fails spf and dkim, here's what to do with it."

v=DMARC1; p=reject; rua=mailto:you@yourdomain.com

the p= tag is the policy: none just monitors, quarantine sends failures to spam, reject blocks them outright. a lot of guides tell you to start with p=none to test safely, which is smart, but the mistake is stopping there forever. p=none collects data but enforces nothing, so spoofed mail using your domain still gets delivered elsewhere while you sit there watching reports. the goal is to work your way up to p=reject.

the rua tag is your reporting address. this is the underrated feature: dmarc reports tell you every time someone tries to send mail as you and fails, which is basically a free early warning system for phishing campaigns impersonating your brand.

verify with dig

you don't need fancy tools to check your own setup, dig does it fine:

dig txt yourdomain.com +short
dig txt _dmarc.yourdomain.com +short
dig txt default._domainkey.yourdomain.com +short

the first pulls your spf record, the second pulls dmarc, the third checks for a dkim key (the selector "default" varies by provider, check your provider's docs for the exact name). if any of these come back empty, that's your exposure right there.

the takeaway

spf says who's allowed to send, dkim proves the message wasn't tampered with, dmarc decides what happens when something fails and tells you about it. skip one and the other two get weaker. most domains have zero or one of these set up correctly, which is exactly why domain spoofing still works so well in phishing campaigns. run the dig commands on your own domain today, check what's actually published, and if you find gaps, fix them in that order: spf, then dkim, then dmarc moving toward p=reject. it's a weekend project that shuts down a whole category of impersonation against your own name.