How to stop email spoofing: the complete sequence

Email spoofing is somebody sending mail that claims to be from your domain when it is not. Not a lookalike domain, not a hacked mailbox. Your actual domain, in the From line, on an invoice with someone else’s bank details.

Nothing in email stops this by default. The From address is just text, the same way a return address on an envelope is just ink. The only thing that stops it is a set of DNS records you publish saying which servers may send for you, and what receivers should do when something fails that test.

The FBI’s Internet Crime Complaint Center recorded $3,046,598,558 in reported business email compromise losses in 2025, the second largest category of loss it tracks. This is the control that addresses it.

There are four records involved and a specific order to do them in. Get the order wrong and you do not fail safely, you stop your own invoices being delivered. This page is the whole sequence. Each step links to a longer piece if you want the detail.

The sequence at a glance

Steps 0 to 5 are sequential. Step 6 runs alongside and is independent.

Step 0: find every sender first

This is the step that gets skipped, and it is the one that decides whether the rest goes smoothly or takes your email down.

Your domain almost certainly sends mail from more places than you think. Your mail provider is obvious. The rest are not: invoicing and accounting tools, the CRM, the helpdesk, the booking system, the website contact form, payroll, the e-commerce platform, the marketing tool somebody in sales signed up for two years ago and still uses.

Every one of those is a system sending as you. If you enforce DMARC before you know they exist, DMARC does exactly what you told it to and refuses them. Your invoices stop arriving, and the failure is silent from your side.

Write the list down before you touch DNS. Ask finance what sends statements. Ask sales what sends quotes. The list is always longer than the first draft.

Step 1: SPF, who is allowed to send

SPF is one DNS record listing the servers permitted to send for your domain.

Two things break SPF in practice. The first is the ten-lookup limit: SPF allows ten DNS lookups, each include: uses at least one, and going over invalidates the entire record silently. Nothing warns you. The second is having more than one SPF record, which is also invalid, and which happens naturally when two people add one a year apart.

Full detail: SPF, DKIM and DMARC explained.

Step 2: DKIM, proving the message is genuine

DKIM signs each message with a private key. Receivers check the signature against a public key in your DNS. If the message was altered in transit the signature fails.

Turn it on at every sender from step 0, not just your main provider. DKIM matters more than people expect because it survives forwarding, and SPF often does not. A domain relying on SPF alone fails DMARC every time a recipient forwards a message to another address.

Full detail: SPF, DKIM and DMARC explained.

Step 3: publish DMARC at p=none

DMARC ties the first two together and adds the instruction: what should a receiver do with mail that fails.

Start at p=none. It protects nothing. That is the point. It asks receivers to send you reports about mail claiming to be from you, without acting on any of it, so you can see your own sending before you start refusing things.

Include a reporting address. A DMARC record with no rua= tag collects nothing, and a surprising number of domains sit at p=none for years with no reporting configured, which is all of the cost and none of the benefit.

Step 4: read the reports before you enforce

Two to four weeks at p=none, and you are looking for one thing: legitimate senders that are failing.

Every sender in the reports is either something you recognise and must fix before enforcing, or something you do not recognise, which is either forgery or a system nobody told you about. Both are worth knowing.

This is the step people rush. Enforcement is not risky if you have read the reports. It is very risky if you have not.

Step 5: quarantine, then reject

p=quarantine sends failing mail to spam. p=reject refuses it outright.

Go through quarantine first, and use the pct= tag to ramp gradually if the estate is large. Watch the reports at each stage. Only p=reject actually stops impersonation; quarantine is a staging post, not a destination.

Full detail, including the tags and the ramp: DMARC policy: none, quarantine or reject.

Step 6: the other half of the door

Email authentication protects your name in mail. Two more records protect the rest of your identity, and both are independent of the sequence above.

CAA names which certificate authorities may issue certificates for your domain. Without it any publicly trusted CA in the world may issue for you, and you find out afterwards. One line in DNS. See the CAA record explained.

DNSSEC signs your DNS answers so they cannot be forged in transit. It has a reputation for difficulty that is really a reputation for one specific mistake: doing the steps in the wrong order takes the domain offline. Done in the right order it is uneventful. See what is DNSSEC.

If you run DNS on Cloudflare, both are close to a switch, with caveats: Cloudflare WAF, DNSSEC and CAA.

What actually breaks, and when

Almost every failure in this work comes from the same three causes.

Enforcing before the inventory is complete. You refuse your own invoicing tool. The fix is step 0, done properly, not done fast.

The SPF ten-lookup limit. Adding one more vendor tips the record over the limit and invalidates all of it, including the senders that worked yesterday. Nothing tells you.

DNSSEC in the wrong order. Publishing the DS record at the registry before the zone is signed and serving correctly is what takes a domain offline. The order is the whole job.

How long this takes

For a small business with one mail provider and a handful of tools, four to six weeks, and almost all of it is the waiting at step 4.

For a larger estate with multiple domains and a dozen senders, two to three months. The extra time is inventory and chasing owners, not DNS work. The DNS changes themselves take minutes.

Anyone offering same-day DMARC enforcement is either skipping the reporting period or has not told you they are going to.

How to know you are done

• Every sender you found in step 0 passes SPF or DKIM, with alignment
• DMARC is at p=reject, not quarantine, not none
• Reports are still arriving and somebody still reads them
• CAA names your CAs, DNSSEC is signed and validating
• Somebody owns this. The records were correct the day they were set; the question is who notices when sales signs up for a new tool next year

That last one is the one that decays. Everything here is correct on the day it is configured and slowly stops being correct afterwards.

Sources and further reading

• RFC 7208, SPF, with the ten-lookup limit at section 4.6.4
• RFC 6376, DKIM
• RFC 7489, DMARC
• RFC 8659, CAA, and RFC 4033, DNSSEC
• Google’s Email sender guidelines. Since February 2024 bulk senders to personal Gmail accounts have needed SPF, DKIM and DMARC at p=none or stronger, with alignment
• FBI IC3 2025 Internet Crime Report

Where to start today

Find out where your domain actually stands before you plan any of this. The free domain security checker grades DMARC, SPF, DKIM, DNSSEC, CAA, MX and MTA-STS in one scan, in about twenty seconds. It runs in your browser, no signup and no email address, and if your domain comes back clean we will tell you so.

If you would rather not carry the risk of the move to enforcement yourself, that is exactly what our DNS and email security engagement is: the inventory, the records, the reporting period and the staged move to p=reject, at a fixed fee quoted after a review, staged so nothing goes dark.

Book a security review, email hello@wpfoss.com, call +254 709 384 200, or WhatsApp +254 118 271 160.