DMARC for Small Business: Stop Attackers From Spoofing Your Domain

DMARC stops attackers from sending email that looks like it came from your exact domain. You set it up by publishing three DNS records (SPF, DKIM, and a DMARC policy), then moving that policy from monitoring (p=none) to enforcement (p=reject) once you've confirmed your real mail is passing. For a small business, the whole thing is free to configure and usually takes a few weeks of careful watching, not months. Here's how it actually works and how I roll it out for clients.

What DMARC actually does (and what it doesn't)

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. The technical spec is RFC 7489, published by the Internet Engineering Task Force in 2015. Strip away the acronym and it does one thing: it tells the world's mail servers what to do with an email that claims to be from your domain but can't prove it. Reject it? Quarantine it to spam? Or just let it through and tell you about it?

What it stops is exact-domain spoofing. Without DMARC, anyone on the internet can put your-name@yourcompany.com in the From field and send invoices, wire requests, or fake password resets to your customers and staff. The receiving server has no instruction telling it that's not allowed, so a lot of those messages land in inboxes. With DMARC at enforcement, that forged mail gets rejected before anyone sees it.

What DMARC does not stop is lookalike domains. If an attacker registers yourc0mpany.com (zero instead of an O) or yourcompany-billing.com, DMARC on your real domain is irrelevant. Those are different domains, and your policy has no say over them. I'll come back to that, because it matters and a lot of vendors quietly skip over it.

The three records, in plain English

DMARC doesn't work alone. It sits on top of two older standards, and you need all three pulling in the same direction.

SPF, the Sender Policy Framework, is a published list of which servers are allowed to send mail for your domain. It's a TXT record in your DNS that names your mail provider, your CRM, your invoicing tool, whatever sends on your behalf. A receiving server checks whether the message came from one of those approved sources.

DKIM, DomainKeys Identified Mail, adds a cryptographic signature to every message you send. The receiving server fetches your public key from DNS and verifies the signature. If it checks out, the message wasn't tampered with in transit and it genuinely came from a system holding your private key.

DMARC is the policy layer that ties them together. It checks that SPF or DKIM passed and that the domain they passed for matches the visible From address, a step called alignment. Then it applies the action you chose and emails you reports on everything it saw. Alignment is the part attackers can't fake, which is why DMARC catches spoofing that SPF or DKIM alone would miss.

Why exact-domain spoofing is the SMB's blind spot

Most small businesses I assess have SPF, sometimes DKIM, and no DMARC. That combination feels like protection and isn't. SPF and DKIM authenticate the message, but nothing forces the visible From address to match what got authenticated. An attacker can pass SPF for their own throwaway domain while the From line still reads accounts@yourcompany.com. DMARC's alignment requirement is what closes that gap.

The financial damage from this is not theoretical. The FBI's Internet Crime Complaint Center reports that business email compromise has cost victims tens of billions of dollars in cumulative losses, and spoofed or impersonated sender addresses are a recurring ingredient. In trucking and freight, where I do most of my work, a spoofed broker email asking a carrier to update remittance details can reroute an entire load's payment. DMARC won't fix every angle of that, but it removes the easiest one: pretending to be you from your own address.

p=none vs p=reject: don't get stuck in monitoring

DMARC has three policy settings, and choosing the right one is where most rollouts succeed or stall.

p=none is monitoring mode. It changes nothing about message delivery. It just collects reports so you can see who's sending mail as your domain, both your legitimate services and the forgers. This is where you start, and it's correct to start here. The mistake is staying here. A domain sitting on p=none forever has DMARC reporting and zero spoofing protection. The forged mail still gets delivered.

p=quarantine tells receiving servers to drop failing mail into spam or junk. It's a useful intermediate step.

p=reject is enforcement. Mail that fails authentication and alignment gets refused outright, never reaching the inbox or the spam folder. This is the only setting that actually stops an attacker from spoofing your exact domain. The goal of any serious DMARC project is to reach p=reject, safely, without blocking a single piece of your own legitimate mail along the way.

How I roll DMARC out without breaking real mail

The whole risk in DMARC is collateral damage. Turn on enforcement before your real mail is authenticating cleanly, and you can block your own invoices or marketing. So the rollout is deliberate, and it follows the same sequence CISA recommends in its email authentication guidance.

First, publish SPF and DKIM correctly for every system that sends as your domain. This is the inventory step, and it's where most surprises hide. Companies forget their payroll platform, their support ticketing tool, their old marketing system that still fires the occasional email. Each one needs to be in SPF and signing with DKIM.

Second, publish a DMARC record at p=none with a reporting address. Let it run for two to four weeks. The aggregate reports that come back show every source sending mail as you, which legitimate ones are aligning, and where the forged traffic is coming from. Real businesses are almost always surprised by what's on that list.

Third, fix the gaps. Add the missing senders to SPF, get the unsigned ones signing with DKIM, and watch the reports until your legitimate mail is authenticating at close to one hundred percent. Then move to p=quarantine, watch again, and finally to p=reject. Done this way, enforcement is anticlimactic, because by the time you flip the switch, the only mail failing is mail you don't want sent anyway.

Cover the lookalike-domain gap too

DMARC at p=reject protects your exact domain. It does nothing about the cousin domains an attacker can register in five minutes. Closing that gap takes a different control: watch for domains that resemble yours being registered, and watch certificate transparency logs for new certs on confusingly similar names. The FTC's small business guidance on phishing is a reasonable primer for the human side of this, since lookalike attacks ultimately depend on a person not noticing the swapped character.

For our managed clients, especially in freight, I monitor lookalike registrations against the top fifty shipper and carrier contacts they actually trade with, because that short list is where impersonation does real financial harm. DMARC and lookalike monitoring are two halves of the same defense. Do one without the other and you've covered half the attack surface.

What this costs and who should own it

The DNS records cost nothing. Most mailbox providers handle SPF and DKIM with a few clicks. The real cost is the reading and the judgment: interpreting DMARC reports, which arrive as dense XML, and deciding when each source is safe to enforce against. That's the part that stalls do-it-yourself projects. The records go up, the reports pile up unread, the domain never leaves p=none, and a year later there's still no protection.

If you have someone who'll own the reporting loop through to p=reject, you can absolutely do this in-house. If you don't, that's the piece worth handing to a managed provider, because the value isn't in publishing records, it's in finishing the journey to enforcement. If you'd rather work from a written sequence, we keep a step-by-step in the EFROS DMARC rollout guide that mirrors exactly how my team does it for clients.

The bottom line

DMARC is one of the highest-leverage, lowest-cost security controls a small business can put in place. It directly shuts down attackers who forge your exact domain, which is one of the most common openings for business email compromise. The catch is that the protection only kicks in at p=reject, and getting there safely means doing the unglamorous work of inventorying your senders and reading your reports. Start at p=none today, but treat enforcement as the actual goal, not the optional final chapter. If you're past spoofing and worried about the people side, our walkthrough on defending against business email compromise covers the workflow controls that catch what authentication can't.