Article Summary: Email spoofing is when a scammer sends a message that appears to come from your domain, often to trick your clients or staff into paying a fake invoice or changing banking details. Three DNS records (SPF, DKIM, and DMARC) prove that a message really came from you and tell receiving mail servers to reject the ones that didn’t. The catch is that DMARC only protects you once it’s set to “quarantine” or “reject,” and a lot of businesses leave it on “none,” which monitors but does not block.
Right now, with no special tools, someone could send an email that looks like it came from your company.
The From line would show your domain, your logo could be pasted into the message, and it could ask one of your clients to pay an invoice or update banking details. This is called email spoofing, and it is one of the most common ways fraud against your clients and suppliers begins.
There are three settings you can add to your domain that make this much harder to pull off.
They’re called SPF, DKIM, and DMARC.
Most businesses have one or two of them set up and the third missing.
That’s usually all it takes to let a spoofed email through. This post explains what each one does, the setting most businesses get wrong, and how to check your own domain.
Why scammers can send email in your company’s name
Email was built in a more trusting time.
The system that delivers mail does not, on its own, check that the sender is who they claim to be. The From address on an email is about as trustworthy as the return address handwritten on an envelope. Anyone can write anything there, and the mail still gets delivered.
Spoofing takes advantage of that.
A scammer puts your domain in the From field, sends the message, and unless your domain is set up to prevent it, the receiving mail server has no reason to question it. The message lands in your client’s inbox looking like it came from you. The UK’s National Cyber Security Centre publishes anti-spoofing guidance for exactly this reason.
The three records that stop email spoofing
Three DNS records work together to prove an email really came from your domain. You add them once, at your domain registrar or DNS host, and receiving mail servers check them on every message you send.
SPF (Sender Policy Framework)<
SPF is a list of the mail servers allowed to send email for your domain, published as a DNS record. When a receiving server gets a message claiming to be from you, it checks whether the sending server is on that list. If a server that isn’t on the list tries to send as your domain, SPF flags it.
DKIM (DomainKeys Identified Mail)
DKIM adds a tamper-proof signature to every message you send. Your mail server signs outgoing email with a private key, and the matching public key sits in your DNS. The receiving server checks the signature to confirm two things: the message really came from your domain, and nobody altered it along the way.
DMARC (Domain-based Message Authentication, Reporting and Conformance)
DMARC ties the other two together and tells receiving servers what to do when a message fails the check. It also confirms that the domain in the visible From address matches the domain SPF and DKIM verified, which is the part that stops someone forging your exact address.
And it sends you reports showing who is sending email using your domain, including the senders who shouldn’t be.
The DMARC setting most businesses get wrong
DMARC has three policy settings, and choosing the wrong one is a common mistake.
- p=none tells receiving servers to do nothing when a message fails. It only monitors and sends you reports. Your domain can still be spoofed.
- p=quarantine tells them to send failing messages to the junk folder.
- p=reject tells them to block failing messages before they ever arrive.
A lot of businesses set up DMARC at p=none, watch the reports come in, and never move past it. At p=none, you get reports but your domain still isn’t protected.
Real protection only starts at quarantine or reject.
Microsoft’s own guidance is to work toward p=reject once you’ve confirmed your legitimate mail passes.
What SPF, DKIM, and DMARC don’t stop
These records stop someone from forging your exact domain.
There are two things they don’t catch, though, and both are worth knowing about.
- Lookalike domains. A scammer can register a domain that resembles yours, like yourcompany-invoices.com, or yourcompany.co instead of .com, and send from that. Your records protect your real domain, not a different one the attacker owns.
- Display-name spoofing. The name shown in the From line can read “Your Company Accounts” while the real address behind it is a random Gmail account. DMARC checks the domain, not the display name.
For those, you still need the habits that catch any phishing attempt: check the full email address rather than just the display name, and verify any request to change payment details by calling a known number, not one from the email.
Why this matters even if you don’t send bulk email
The first reason is protection.
These records stop scammers from impersonating your domain to your clients, your suppliers, and your own staff.
The second is deliverability.
The major mailbox providers now require these records from anyone sending in volume.
Since February 2024, Google and Yahoo have required bulk senders, meaning those sending more than 5,000 messages a day, to use SPF, DKIM, and DMARC.
Microsoft began applying similar requirements to Outlook.com and Hotmail in 2025, routing non-compliant high-volume mail to junk and then rejecting it.
Even below those thresholds, a domain with proper authentication is more likely to reach the inbox than the spam folder.
How to check and fix your domain
You can get a rough sense of where you stand without any technical work.
Several free DMARC and SPF checkers let you type in your domain and see which records exist. That tells you whether the records are present, though not whether they’re configured correctly.
Fixing them properly is a job for whoever manages your IT or your domain.
The records live in your DNS, and a mistake can send your own legitimate email to spam, so the rollout is done in stages:
- Publish SPF and DKIM so all of your real mail sources are covered.
- Add DMARC at p=none and read the reports to confirm your legitimate mail passes.
- Move DMARC to p=quarantine, then to p=reject, once the reports look clean.
Microsoft recommends this same gradual path, starting at none and working toward reject, so you protect the domain without blocking your own mail on the way.
Frequently Asked Questions
What is email spoofing?
Email spoofing is when someone sends a message with your domain in the From address to make it look like it came from your company. It’s used to trick your clients, suppliers, or staff into paying fake invoices, changing banking details, or handing over information.
What are SPF, DKIM, and DMARC in simple terms?
SPF is a list of servers allowed to send email for your domain. DKIM is a signature that proves a message came from you and wasn’t altered. DMARC ties the two together, tells receiving servers to reject messages that fail, and reports who is sending email as your domain.
Does DMARC stop all email impersonation?
No. DMARC stops someone forging your exact domain. It does not stop lookalike domains (like yourcompany-invoices.com) or display-name spoofing, where the sender’s name says your company but the address behind it is different. Those still need staff awareness and payment-verification habits.
Will setting up DMARC block my own emails?
Not if you roll it out gradually. Starting at p=none lets you watch the reports and confirm your legitimate mail passes before you move to quarantine and then reject. Skipping straight to reject without checking first is what causes problems.
Do I need these records if I don’t send many emails?
Yes. They protect your domain from being spoofed regardless of how much email you send, and they help your messages reach the inbox. Google, Yahoo, and Microsoft now expect proper authentication, and mail without it is more likely to be filtered.
—
This Article has been Republished with Permission from The Technology Press.
