Right now, with no tools and no access to anything of yours, someone could send an email that appears to come from your company. Your domain in the From line. Your logo pasted into the body. A polite note to a client asking them to update the bank details on file before the next payment. That is email spoofing, and it is one of the most common ways fraud against your own customers begins.

Nothing has to be breached for it to work. Your passwords are fine, your systems are fine, and your client still pays a stranger. Three DNS records exist to stop email spoofing: SPF, DKIM, and DMARC. Most businesses have two of them in place with the third either missing or configured in a way that does nothing at all.

Email spoofing works because nothing checks the From line

Email was designed in a more trusting era. The protocol that moves mail between servers never verifies that a sender is who they claim to be. The From address is about as reliable as the return address handwritten on an envelope. Anyone can write anything there, and the postal system delivers it regardless.

Email spoofing is simply someone exercising that gap. A scammer writes your domain into the From field and sends. Unless your domain publishes instructions telling receiving mail servers how to verify you, the receiving server has no reason to doubt it, and the message lands in your client’s inbox looking exactly like your mail. The UK’s National Cyber Security Center maintains anti-spoofing guidance for precisely this reason.

The one setting that decides whether you are actually protected

This is the part worth reading twice, because it is where most businesses that believe they are protected against email spoofing are not.

DMARC has three policy settings, and only two of them stop anything:

• p=none tells receiving servers to take no action when a message fails the check. It monitors and sends you reports. Your domain can still be spoofed freely.
• p=quarantine tells them to divert failing messages to the junk folder.
• p=reject tells them to refuse failing messages before they are ever delivered.

An enormous number of businesses set DMARC up at p=none, watch a few weeks of reports arrive, and then never move. The record exists, a checker reports it as present, and the business assumes the job is finished. It is not. At p=none you have monitoring and nothing else, and email spoofing against your domain still succeeds exactly as it did before. Microsoft’s own DMARC guidance is explicit that you should work toward p=reject once you have confirmed your legitimate mail passes.

If you check one thing after reading this, check whether your DMARC policy says none. That single word is the difference between a domain that is monitored and a domain that is defended.

What each of the three records actually proves

They are often described as a bundle, which obscures that each one answers a different question.

SPF answers: is this server allowed to send for us?

SPF is a published list of the mail servers permitted to send email using your domain. A receiving server checks the sending server against that list. If something not on the list tries to send as you, SPF flags it, which is the first place email spoofing gets caught. The common failure here is an incomplete list. A business publishes SPF covering Microsoft 365, then forgets the invoicing platform, the CRM, and the marketing tool that also send in its name.

DKIM answers: was this message altered in transit?

DKIM attaches a cryptographic signature to every message you send. Your mail server signs with a private key; the matching public key sits in your DNS. The receiving server verifies the signature and learns two things: the message genuinely originated from your domain, and nobody modified it on the way. Email spoofing cannot produce that signature.

DMARC answers: what should we do when the first two fail?

DMARC binds SPF and DKIM together and issues the instruction. It also confirms that the domain a human sees in the From line matches the domain that SPF and DKIM verified, which is the specific check that defeats email spoofing of your exact address. It returns reports naming every sender using your domain, including the ones that should not be.

Where email spoofing still gets through

SPF, DKIM, and DMARC protect one thing: your exact domain. Two forms of email spoofing route around them entirely.

• Lookalike domains. An attacker registers something adjacent, like yourcompany-invoices.com or your name on .co instead of .com, and sends from it legitimately. Your records govern your domain. They have no authority over a domain someone else owns.
• Display-name spoofing. The name shown in the From line reads “Your Company Accounts” while the actual address behind it is an unrelated Gmail account. DMARC evaluates the domain, not the friendly name, and on a phone the friendly name is often all anyone sees.

Both are defeated by process rather than DNS: read the full address rather than the display name, and verify any request to change payment details by calling a number you already had, never one supplied in the message. We went through the specific controls that stop this at the accounts-payable desk in our guide to protecting your AP team from invoice fraud, and the same verification habit now has to cover voice-cloned calls from the boss as well.

Checking your own domain without touching DNS

You can get a useful read on your exposure to email spoofing in about five minutes, without editing anything.

• Look up your records. Several free DMARC and SPF checkers accept a domain name and show what is published. This tells you whether the records exist.
• Read the DMARC policy value. Find the p= value in the DMARC record. If it reads none, you are monitoring, not protecting.
• Count your senders. Write down every system that sends email in your name: Microsoft 365, your accounting or invoicing platform, your CRM, your marketing tool, any booking or form system. This list is what SPF has to cover, and it is where most incomplete configurations come from.
• Send yourself a test. Mail from each of those systems to a personal address on another provider and check whether it lands in the inbox or in spam.

Reading the position is straightforward. Fixing it is not a place to experiment, because DNS mistakes route your own legitimate mail to spam. That part belongs with whoever manages your domain or your email security.

The rollout order that avoids blocking your own mail

The reason so many domains are stranded at p=none is that moving off it feels risky, so email spoofing stays possible indefinitely. Done in order, the move is not risky at all.

• Publish SPF and DKIM covering every sending system you listed. Missing one here is what causes problems later.
• Add DMARC at p=none and read the reports. This stage exists to prove your legitimate mail passes. Two to four weeks is usually enough.
• Move to p=quarantine. Failing mail, including email spoofing attempts, goes to junk rather than vanishing, so any sender you missed shows up as a complaint instead of a silent loss.
• Move to p=reject once quarantine has been quiet. This is the setting that actually ends email spoofing of your domain.

The staged path is Microsoft’s own recommendation, and it is the difference between a controlled rollout and a morning spent explaining why nobody received the invoices. If you or your IT provider are doing this yourselves, our step-by-step DMARC, DKIM and SPF setup guide covers each stage in detail, including the sender inventory and the platform-specific quirks that trip people up partway through.

When it is your name on the fake invoice

Most coverage of email spoofing stops at prevention. The harder question is what you do on the day a customer calls to ask about an invoice you never sent.

Treat it as an incident even though nothing of yours was breached, because from your customer’s side the distinction is invisible. Call them directly rather than replying to the thread, since the thread may already be under someone else’s control. Establish whether any payment left, and if it did, tell them to contact their bank immediately, because recovery odds fall sharply after the first day. Then warn your other customers before a second one pays, and give whoever handles your IT the original message with full headers so the sending path can be traced and your own records checked.

For businesses around League City and Webster that invoice on net terms, such as contractors, engineering firms, and accounting practices, this is the scenario worth rehearsing, because the loss lands on a customer relationship rather than on your network. Email spoofing does reputational damage in proportion to how long it takes you to notice, and the businesses that handle it well are the ones who decided in advance who makes the call.

Why this matters even if you barely send email

Blocking email spoofing is the first reason. Deliverability is the second, and it now has deadlines attached. Since February 2024, Google and Yahoo have required bulk senders, meaning those sending more than 5,000 messages a day, to publish SPF, DKIM, and DMARC. Microsoft began applying comparable requirements to Outlook.com and Hotmail in 2025, first routing non-compliant high-volume mail to junk and then rejecting it outright.

Most small businesses sit well under those thresholds. It still matters, because the same authentication signals feed the filtering decisions applied to everyone. A domain with proper records reaches the inbox more reliably than one without, whatever the volume, and it is not advertising itself as an easy target for email spoofing.

Frequently Asked Questions

How do I know if someone is spoofing my domain right now? DMARC reports are the only reliable answer, which is the one genuinely useful thing p=none provides. They list every sender using your domain, so unfamiliar sending sources show up there before a customer calls you.

We use Microsoft 365. Doesn’t that handle this already? Partly. Microsoft 365 signs your outbound mail and filters inbound, but the DMARC policy on your domain is yours to set and defaults to nothing. A tenant can be perfectly configured while the domain remains wide open to email spoofing.

A client received a fake invoice from “us.” Were we hacked? Usually not, because email spoofing needs no access at all. Forging your domain in the From line requires no access to your systems whatsoever. Check anyway, since a compromised mailbox produces very similar symptoms, but the common cause is spoofing, not a breach.

How long does it take to reach p=reject safely? Four to eight weeks for most small businesses. The time is spent reading DMARC reports and confirming every legitimate sender passes. Rushing straight to reject is what causes a company to block its own invoices.

Does any of this stop someone registering a domain that looks like ours? No. That is a different problem needing a different answer: monitoring for lookalike registrations, and training staff to read the full address rather than the display name.

Email spoofing is unusual among security problems in that the fix is finite. Three records, a staged rollout, and a policy value that says reject rather than none. If you are not certain where your domain currently stands, see how a cyber shield approach covers domain authentication alongside the rest and where your current setup leaves a gap.

Featured Image Credit: Unsplash