Email spoofing happens when someone sends a message that appears to come from your domain without your permission. The recipient sees your brand in the From field, opens the message because they trust it, and may hand over credentials, pay a fraudulent invoice, or click a malicious link.
The frustrating part is that, by default, nothing on the internet prevents this. You have to actively publish a small set of DNS records that tell receiving mail servers how to recognize and reject forgeries.
This guide walks through exactly what those records are, how they work together, and the single step most people skip that leaves their domain spoofable even after they have done what feels like the hard work.
Why does email spoofing work in the first place?
The address you see in your mail client — the From header — is just text. The original email standards were written for a small, trusting network of academic and government machines, and they never required the sender to prove that the From address belonged to them. Any server on the internet can connect to a recipient's mail server and announce that it is sending mail as your domain. There is no built-in check.
That is the whole problem. A receiving server, on its own, has no way to know whether billing@yourcompany.com was really sent by your company or by an attacker on a rented server.
The fix is not to change the email protocol — that ship sailed decades ago — but to layer authentication on top of it. You publish records that let receivers verify the sender, and a policy that tells them what to do when verification fails.
Which records stop spoofing — SPF, DKIM, or DMARC?
Email authentication rests on three DNS records. They are often described as interchangeable, but they do different jobs, and only their combination actually stops From-address spoofing.
SPF — who is allowed to send
SPF (Sender Policy Framework) is a TXT record that lists the servers authorized to send mail for your domain. A receiver checks whether the connecting server's IP is on that list. A typical record looks like this:
v=spf1 include:_spf.google.com include:spf.protection.outlook.com -allThe crucial part is the ending. -all means "reject anything not listed" (a hard fail); ~all means "treat as suspicious" (a soft fail).
The catch: SPF validates the hidden Return-Path (envelope) address, not the visible From header your users actually read. An attacker can pass SPF on their own throwaway domain while still forging your brand in the From field, so SPF alone does not protect the address people see.
DKIM — proving the message was not tampered with
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each outgoing message. Your mail provider signs the message with a private key, and receivers verify it against a public key you publish in DNS. A valid DKIM signature proves two things: the message genuinely passed through a server that holds your key, and the contents were not altered in transit. Like SPF, though, DKIM on its own does not require the signing domain to match the visible From address.
DMARC — the record that actually stops spoofing
DMARC (Domain-based Message Authentication, Reporting and Conformance) is the piece that ties everything together. It does two things SPF and DKIM cannot do on their own:
- Alignment. DMARC requires that the domain validated by SPF or DKIM matches the domain in the visible
Fromheader. This is the mechanism that finally protects the address your users read — the exact thing attackers forge. - Policy. DMARC lets you tell receivers what to do with mail that fails:
p=none(monitor only),p=quarantine(send to spam), orp=reject(refuse delivery entirely).
Alignment is the key insight. Without DMARC, a forged message can sail through because some domain passed SPF or DKIM, even if it was not yours. With DMARC alignment enforced, a message claiming to be from your domain must actually authenticate as your domain — or it gets quarantined or rejected.
Step by step: from zero to enforced
Set the records up in order. Each one builds on the last, and the final step — moving DMARC to enforcement — is what actually delivers protection.
1. Publish SPF
Add a single TXT record at your root domain listing every service that sends mail for you (your mailbox provider, marketing platform, helpdesk, invoicing tool, and so on). End it with -all. A domain can have only one SPF record, so merge all sources into one line rather than creating several. Keep the number of DNS lookups under ten or SPF will fail with a permerror.
2. Enable DKIM
Turn on DKIM signing in your mail provider's admin console. The provider generates a key pair and gives you a CNAME or TXT record (the public key) to publish in DNS, usually at a selector like selector1._domainkey.yourdomain.com. Once published, the provider signs all outbound mail automatically. Verify in the console that signing is active before moving on.
3. Roll out DMARC: p=none → reject
Start in monitoring mode so you can see what is being sent under your name without breaking legitimate mail:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.comThe rua address collects aggregate reports from receivers, showing every source sending as your domain and whether it passed authentication. Review these reports for a few weeks, fix any legitimate sender that is failing, then tighten the policy to p=quarantine, and finally to p=reject. Only at p=reject (or quarantine) is your domain genuinely protected.
Provider-specific instructions differ slightly. See our walkthroughs for DMARC setup on Google Workspace, DMARC setup on Microsoft 365 / Office 365, and configuring SPF and DKIM on GoDaddy. You can also follow the official guides from Google, Microsoft, and GoDaddy.
p=none — your domain is still fully spoofable. Nothing instructs receivers to reject forgeries; p=none only watches them go by. Enforcement (p=quarantine or p=reject) is the step that actually prevents spoofing. If you do one thing from this guide, move DMARC past monitoring mode.Run a free, passive check of your domain's SPF, DKIM, and DMARC records to see whether forged mail would actually be rejected.
Check if your domain can be spoofed →What about parked and non-sending domains?
Spoofing protection is not only for the domain you send mail from. Any domain you own — old brands, typo-catcher domains, internal-only names, or domains you registered but never use — can be spoofed just as easily. Attackers often target these precisely because nobody bothered to lock them down. A domain that sends no email should explicitly say so.
For every parked or non-sending domain, publish three things:
- An SPF record that authorizes no senders at all:
v=spf1 -all - A DMARC record set straight to reject — there is no legitimate mail to break, so skip the monitoring phase:
v=DMARC1; p=reject; - A null MX record declaring the domain accepts no mail:
0 .
Together these tell the world that the domain neither sends nor receives email, so any message bearing its name is illegitimate and should be thrown away. It takes minutes per domain and closes a door attackers love to find open.
Frequently asked questions
For the full picture, read our pillar guide on email authentication, and if a scan flagged your policy, see why a DMARC policy of p=none is not enough or why DMARC fails and how to fix it. If a scan flagged your SPF, see how to fix SPF too many DNS lookups and how to fix multiple SPF records.