Your email domain is probably being spoofed right now. Not maybe. Probably.
If you haven't verified your DMARC configuration recently — or ever — there's a reasonable chance someone is sending emails that look exactly like they came from your domain. To your clients. To your vendors. To anyone they want to defraud.
It costs nothing to check. Drop your domain into MXToolbox right now and look at what it returns.
What Your DMARC Result Actually Means
No protection whatsoever
Anyone can send email from your domain. No restrictions, no monitoring, no visibility. This is the worst possible state.
Monitoring only — nothing blocked
You'll receive reports of who's sending from your domain, but spoofed mail still reaches recipients unimpeded. This is a starting point, not a solution.
Partial protection — spoofed mail goes to spam
Failing messages are sent to junk folders rather than blocked outright. Better than nothing, but spoofed emails still get through — just with lower visibility.
Full enforcement — spoofed mail is blocked
Mail that fails authentication is rejected outright. This is the only configuration that actually protects your domain from spoofing.
Most small businesses in Connecticut and New York are at p=none or have no record at all. They're visible in monitoring dashboards — sometimes their own, more often attackers' — and don't know it.
What a Spoofed Email Looks Like
This is what business email compromise looks like from the recipient's side. Everything about it appears legitimate:
Thanks,
Eugene Moore
Moore Technology Consulting
(646) 791-2137
The recipient sees a legitimate sender name, a real domain, and a signature that matches what they'd expect. They have no way to know the email didn't come from you. This is business email compromise — and it cost U.S. businesses $2.9 billion last year according to the FBI's Internet Crime Report.
Three Things That Close the Door
Proper email authentication requires three records working together. Most businesses have one. Very few have all three configured correctly at enforcement level.
Sender Policy Framework
A DNS record that tells receiving servers which IP addresses are authorized to send email on behalf of your domain. If a message comes from an unauthorized IP, SPF fails. Setting this up incorrectly — too permissive, or with a missing ~all vs. -all suffix — leaves gaps that attackers exploit.
DomainKeys Identified Mail
Cryptographically signs your outgoing email so receiving servers can verify it wasn't tampered with in transit. Even if an attacker intercepts and modifies a legitimate email, DKIM validation will fail. Microsoft 365 and Google Workspace both support DKIM natively — it just needs to be enabled and the DNS records published.
Domain-based Message Authentication — at p=reject
Ties SPF and DKIM together with a policy that tells receiving servers what to do when either check fails. At p=reject, mail that doesn't pass authentication is blocked outright — not delivered, not quarantined, blocked. It also sends you aggregate reports so you can see every source sending mail as your domain.
The Implementation Sequence That Matters
The reason most businesses stay at p=none indefinitely is that jumping straight to p=reject without validating all legitimate sending sources will block your own mail. The correct sequence is:
- Publish a DMARC record at p=none with reporting enabled
- Review the aggregate reports for 2–4 weeks — identify every source sending as your domain (M365, marketing tools, billing systems, CRM)
- Ensure SPF covers all legitimate senders; enable DKIM on each
- Move to p=quarantine and monitor for a week
- Move to p=reject — now you're fully protected
The whole process takes a few hours of technical work and 3–4 weeks of observation before you can safely enforce. We configure this as standard for every client we onboard — it's not optional.
Free Domain Check
DM us "AUDIT" on LinkedIn and we'll check your domain's SPF, DKIM, and DMARC configuration — and tell you exactly what's exposed and what it would take to close it. No cost, no obligation.