A contractor in Burlington called me last spring because one of his best clients had just paid an invoice he never sent. The email had his company name in the From line, his logo in the signature, his usual friendly sign-off, and updated banking details for the wire. The client paid eighteen thousand dollars into an account that belonged to someone in another country. Nobody had hacked the contractor's mailbox. His password was fine, his MFA was on, his laptop was clean. A stranger had simply sent an email that claimed to come from his domain, and every mail server along the way accepted the claim without asking for proof.
That is the part most business owners never hear until it happens to them. Email was built in an era when everyone on the network was assumed to be honest, so the protocol lets any server put any address in the From field. There is nothing in the basic design that checks whether the sender is allowed to use that name. Your domain, the thing your clients trust when they see it in their inbox, can be worn by anyone who wants to, unless you have gone out of your way to make that impossible.
Three records that decide who gets to speak for you
Fixing this comes down to three small text records that live in your domain's DNS settings, the same place your website and email routing are configured. None of them cost anything. Together they let receiving mail servers verify that a message really came from you before they trust the name on it.
The first is SPF, which stands for Sender Policy Framework. Think of it as a published guest list of the mail servers allowed to send on your behalf. When you use Microsoft 365, that list includes Microsoft's servers. When you send newsletters through a tool like Mailchimp, its servers go on the list too. A receiving server checks the incoming message against your published list, and if it arrived from a server that is not on it, that is a signal something is wrong.
The second is DKIM, or DomainKeys Identified Mail. This one adds a tamper-proof seal. Your mail platform signs every outgoing message with a private cryptographic key, and it publishes the matching public key in your DNS. The receiving server checks the signature and confirms two things at once, that the message really came from your domain and that nobody altered it in transit. A forged email from an attacker's server cannot produce a valid signature, because they do not hold your private key.
The third, and the one that actually pulls the trigger, is DMARC. On its own, SPF and DKIM tell a receiving server how to check a message, but they do not say what to do when the check fails. DMARC is where you give the instruction. It ties the two checks to the visible From address your clients actually see, and it lets you state a policy: if a message claiming to be from my domain fails these checks, quarantine it or reject it outright. It also sends you regular reports showing who is sending mail under your name, which is often the first time a founder sees just how much forged mail is already going out.
Why "we set that up years ago" usually means nothing
Almost every business I look at has an SPF record, because their web host or their IT person added one when email was first configured. Fewer have DKIM switched on. Almost none have a DMARC policy that does anything.
The trap is that a DMARC record can exist and still be completely passive. When you first publish one, the standard practice is to set the policy to a value called p=none, which means "check the mail, send me the reports, but deliver everything anyway even when it fails." That is a sensible starting point for a week or two while you confirm your legitimate mail is passing. The problem is that thousands of firms publish p=none, see that email still flows, and never come back to finish the job. Their domain looks protected on paper and is wide open in practice. Moving the policy to p=quarantine, so failing mail lands in spam, and then to p=reject, so it is refused at the door, is the step that actually protects your clients. Skipping it is like installing a lock and leaving it unlatched.
The deadline already passed and most people missed it
This stopped being optional in early 2024. Google and Yahoo began requiring anyone sending more than five thousand messages a day to have SPF, DKIM, and a DMARC record in place, or their mail would be throttled or bounced. Microsoft followed with its own enforcement for high-volume senders into Outlook and Hotmail in May 2025. The thresholds are aimed at bulk senders, so a ten-person firm sending normal business email will not get blocked tomorrow for missing them. The direction of travel is clear, though. Mailbox providers are steadily raising the bar on what counts as trustworthy mail, and domains without proper authentication are drifting toward the spam folder and, eventually, the reject pile.
There is a quieter cost that shows up long before any provider blocks you. When your domain is easy to forge, your invoices and quotes are the ones that get used in fraud, and your clients are the ones who lose money believing they were dealing with you. The reputational damage of a client paying a fake invoice in your name is hard to undo, even when the fault was never really yours. This sits right alongside the inbound side of the same problem, the fraudulent payment requests we covered in invoice fraud starts in your inbox. One protects your staff from being tricked. The other protects your clients from being tricked in your name.
What to actually do this month
Start by finding out where you stand, because you cannot see any of this from inside your own inbox. A free DMARC or domain checker will show you in seconds whether you have SPF, DKIM, and DMARC configured, and what your current policy is set to. If DMARC is missing or sitting at p=none, you have found real, fixable exposure.
From there the work is methodical rather than hard. Confirm that every service that legitimately sends mail for you, your Microsoft 365 or Google Workspace tenant, your marketing tool, your invoicing software, is accounted for in SPF and signing with DKIM. Publish a DMARC record starting at p=none, read the reports for a couple of weeks to make sure nothing legitimate is failing, then tighten the policy to quarantine and finally to reject. Rushing straight to reject without watching the reports first is the one way to break your own mail, which is why the staged approach exists.
The whole thing is a few DNS records and a bit of patience, and it closes off one of the cheapest attacks going: pretending to be a business too busy to prove otherwise. If you want a second set of eyes on what your domain is currently telling the world, or help walking the policy up to full enforcement without knocking out your own invoices, reach out and we will take a look at what is published under your name.