Email Spoofing Prevention
Check your SPF and DMARC records, build a DMARC record to publish, and read SPF, DKIM and DMARC explained in the order you should actually implement them.
Find it with dig +short TXT yourdomain.com and paste the line starting v=spf1.
This one lives on a subdomain: dig +short TXT _dmarc.yourdomain.com.
Name: _dmarc.yourdomain.com Type: TXT Value: v=DMARC1; p=none; sp=none; fo=1
fo=1 asks for a failure report when either SPF or DKIM fails, rather than only when both do. Publish at p=none first and read the reports for a few weeks before you move the policy up.
SPF, DKIM and DMARC, in the sequence to implement them
The sequence matters. Publishing an enforcing DMARC policy before the sender inventory is complete is how a company stops receiving its own order confirmations.
01 · Inventory everything that sends as your domain
Before any DNS change, list every system that puts your domain in a From address: the mail platform, the CRM, the invoicing system, the ticketing tool, the recruitment portal, the marketing suite, and the application server that sends password resets.
This step is why rollouts fail. A record published without the full list eventually blocks a system nobody remembered, usually the one that sends invoices.
02 · Publish SPF, ending in ~all
One TXT record at the apex, listing each sender. Start with softfail rather than hardfail: it tells receivers your intent without bouncing legitimate mail you overlooked.
One SPF record per domain. Two v=spf1 records is a permanent error and neither will be used.
03 · Turn on DKIM at every sender
Each platform generates a key pair, you publish the public half at the selector it gives you, and it signs outbound mail with the private half. Most providers have this as a one-click setting with a CNAME to paste.
DKIM is what survives forwarding. SPF breaks when a mailing list relays your message; the DKIM signature travels with it, which is why DMARC needs only one of the two to pass.
04 · Publish DMARC at p=none and actually read the reports
Monitoring mode changes nothing about delivery, and the aggregate XML tells you which senders pass, which fail, and which you had forgotten. Give it a few weeks of normal business activity.
The reports are XML sent daily by each receiver. Either feed them to a parser or use a reporting service; an unread mailbox is the same as no reporting.
05 · Fix alignment, then move to quarantine
DMARC needs the visible From domain to align with the SPF or DKIM domain. A sender that passes SPF on its own bounce address still fails DMARC if the two do not match. Once the reports are clean, move to p=quarantine.
Alignment, not authentication, is where most surprises turn up. A platform can pass SPF perfectly and fail DMARC every time.
06 · Move to p=reject, and keep reporting on
Reject is the point at which spoofed mail claiming to be you is refused rather than filed in a junk folder. It is the only setting that actually stops the attack.
Leave rua= in place afterwards. A new SaaS tool added without DKIM will now bounce silently, and the reports are how you find out.
The failure modes we see most
Drawn from what turns up repeatedly on engagements, rather than from the specifications.
DMARC parked on p=none indefinitely
By far the most common. The record is published, a compliance checklist gets ticked, and it stays in monitoring mode for years. p=none blocks nothing whatsoever: anyone can still send mail as your domain and it will be delivered. If you take one thing from this page, it is that publishing DMARC and enforcing DMARC are different projects.
SPF exceeding the ten-lookup limit
Every include, a, mx, ptr, exists and redirect costs a lookup, and each include drags in that provider's own record with its own lookups. Past ten, receivers return permerror and SPF stops passing for your legitimate mail as well. Domains hit this by accumulating SaaS senders, never removing the ones they stopped using. Flattening tools help but need re-running whenever a provider changes their ranges.
Subdomains left unprotected
The apex is locked down while sp= is absent or set to none, so invoices.yourdomain.com can be spoofed freely. Attackers read DNS as well as you do, and a plausible-looking subdomain is more than sufficient for a phishing message. Publish a restrictive SPF and DMARC on non-sending subdomains too.
Alignment misunderstood
SPF checks the envelope sender, which the recipient never sees; DMARC checks the header From, which they do. A marketing platform sending with its own bounce domain passes SPF and fails DMARC alignment. The fix is usually a custom sending domain plus DKIM at the platform, not a wider SPF record.
Treating this as the whole of email security
SPF, DKIM and DMARC stop mail claiming to come from your exact domain. They do nothing about a lookalike domain registered yesterday, a compromised mailbox at a supplier, or a display name that reads as your finance director from a free webmail account. Those are the attacks that actually take money, and they need user training and payment controls rather than DNS.