A client of yours opens their inbox tomorrow morning and sees an email from you. The display name is right. The signature is right. It references a project you actually have together. It asks them to update the payment account for an upcoming invoice. They do it. The money goes to an attacker in another country.
The email didn’t come from your account. Your account wasn’t hacked. Nobody guessed your password. Someone, somewhere, sent an email that claimed to be from your domain — and the receiving mail server had no way to confirm whether that claim was true or false. So it delivered the message.
This is what email authentication exists to prevent. The three protocols at the center of it — SPF, DKIM, and DMARC — are not optional security hygiene. They’re the controls that determine whether your business domain can be used as a weapon against your own clients. If they’re missing or misconfigured, your domain is a liability you don’t know you’re carrying.
How email spoofing actually works
The original design of email, going back to the 1980s, treats the “From” address the way a paper envelope treats the return address in the upper-left corner. Anyone can write anything there. The post office still delivers the letter. Email works the same way: the server sending a message tells the receiving server what address it’s claiming to send from, and the receiving server, on its own, has no way to verify that claim.
An attacker who wants to send email “from” your domain doesn’t need to break into your mail server. They don’t need your password. They set up their own server (or rent one), they configure it to send mail claiming the From address is you@yourcompany.com, and they hit send. Unless something on the receiving end checks whether that sending server is actually authorized to send for your domain, the message lands in the inbox looking, for all practical purposes, exactly like a message you sent.
This is the problem SPF, DKIM, and DMARC exist to solve. Each one answers a different question about whether a given email is legitimately from the domain it claims to be from.
SPF: which servers are allowed to send mail for your domain
SPF (Sender Policy Framework) is a published list — attached to your domain — of which mail servers are authorized to send email on your behalf. When a receiving server gets a message claiming to be from yourcompany.com, it can look up the SPF list for yourcompany.com and check whether the server that just delivered the message is on it. If it is, the SPF check passes. If it isn’t, the SPF check fails, and the receiving server now has a signal that something’s off.
In practical terms: if your business sends email through Microsoft 365, your SPF list says “Microsoft 365’s mail servers are authorized.” If your marketing platform sends newsletters on your behalf, its servers go on the list too. An attacker sending from a random server in Eastern Europe is not on the list — and SPF catches that.
What SPF doesn’t catch: a forwarded message. When a recipient forwards your email to someone else, the forwarding server isn’t on your SPF list — it’s not supposed to be. So SPF alone produces false negatives on legitimate forwarded mail, and it does nothing to verify that the body of the message wasn’t tampered with after it left the authorized server. SPF answers one question well — was this sent from an approved server — and leaves the rest open.
DKIM: proof the message wasn’t forged or altered
DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every outgoing message. The signature is generated using a private key that only your sending infrastructure has. A matching public key is published with your domain. When a receiving server gets the message, it uses the public key to verify the signature. If the signature checks out, the receiving server knows two things: the message was signed by something that legitimately holds your domain’s private key, and the message hasn’t been altered in transit since it was signed.
This closes a gap SPF leaves open. SPF says “this server was allowed to send.” DKIM says “this message was actually produced by your domain’s signing infrastructure, and nobody changed it on the way.” An attacker who forges a message claiming to be from your domain can’t produce a valid DKIM signature because they don’t have your private key.
What DKIM doesn’t do on its own: it doesn’t tell the receiving server what to do when the signature is missing or invalid. A message with no DKIM signature at all can still arrive, and without further policy, the receiving server has to guess whether the absence is suspicious or just normal. DKIM proves authenticity when it’s present. It can’t force the question of what to do when it’s not.
DMARC: the policy that ties it together
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the layer that turns SPF and DKIM from optional checks into enforced policy. A DMARC record published with your domain tells receiving mail servers two things: how to handle messages claiming to be from your domain that fail SPF and DKIM, and where to send reports about which messages passed and which failed.
Without DMARC, SPF and DKIM are advisory. A receiving server can check them, but it has no instructions from you about what to do when they fail. With DMARC, you publish a policy — and compliant receiving servers (which is most of the major ones, including Gmail, Outlook, Yahoo) follow it.
DMARC also closes a subtle gap: the “From” address a user sees and the technical sender address SPF checks against can be different. An attacker can pass SPF using a domain they actually control while displaying a forged From address that looks like yours. DMARC requires that the visible From domain align with the authenticated domain, which shuts that trick down.
What the DMARC policy levels actually mean
DMARC has three policy settings, and the difference between them is the difference between watching the problem and stopping it.
p=none means “monitor only.” The receiving server checks SPF and DKIM, notes whether they passed or failed, sends you a report — and delivers the message anyway. This is the policy organizations start with to see what’s happening on their domain without breaking legitimate mail. It generates visibility. It blocks nothing. A domain with a DMARC record set to p=none is, for spoofing purposes, in the same position as a domain with no DMARC at all.
p=quarantine means “if a message fails authentication, treat it as suspicious.” In practice, this usually means the message goes to the recipient’s spam or junk folder rather than the inbox. Some messages still reach the recipient — they just have to dig for them. This catches most spoofing but leaves some exposure: a determined recipient who checks their spam folder can still be tricked.
p=reject means “if a message fails authentication, refuse to deliver it.” The receiving server bounces the message. The recipient never sees it. This is the policy that actually stops spoofing of your domain.
“We have DMARC” tells you almost nothing on its own. A domain at p=none has DMARC and is wide open. A domain at p=reject has DMARC and is protected. The policy level is the entire story.
What goes wrong without proper authentication
The risk most owners think of first is the spoofed phishing email — a fake message in your name reaching a client and convincing them to wire money, change account details, or hand over credentials. That risk is real, and the consequences are direct: a client who loses money to a phishing email that appears to come from your domain may hold you responsible, regardless of how much of the blame technically belongs to them.
The less visible damage is to your domain reputation. Every major email provider — Google, Microsoft, Yahoo — scores domains based on observed behavior. A domain that’s regularly used in spam or phishing campaigns gets flagged, and over time, legitimate mail from that domain starts landing in spam folders or getting rejected outright. You don’t get a notification. You just notice that clients stop receiving your invoices, your proposals don’t get answered, and your scheduling confirmations vanish.
There’s also a deliverability cliff that arrived in 2024. Gmail and Yahoo now require bulk senders to authenticate their mail with SPF and DKIM and publish a DMARC record in order to deliver reliably to their users. The threshold is 5,000 messages per day to their users, which sounds high until you realize a small business sending newsletters, appointment reminders, and routine client correspondence can cross it without trying. Domains that don’t meet the requirements get throttled or rejected.
And then there’s the regulatory and insurance angle. Cyber insurance underwriters increasingly ask about email authentication as part of their risk assessment. A domain with no DMARC enforcement is a data point that affects coverage and premiums. For businesses under HIPAA, financial regulations, or state privacy laws, sending client communications from an unauthenticated domain can be characterized as a failure of reasonable safeguards if an incident occurs.
“I assumed Microsoft 365 handled this”
A common — and reasonable — assumption is that signing up for Microsoft 365 or Google Workspace means email authentication is taken care of. Partially true. Both platforms set up SPF and DKIM for your domain during the onboarding process if you follow the standard configuration steps. Both will sign your outgoing mail.
Neither one publishes a DMARC record for you. DMARC is something you have to deliberately set up, and the platforms don’t do it by default because an aggressive DMARC policy applied without first understanding what mail is being sent in your name can break legitimate messages — from your CRM, your accounting software, your scheduling platform, your newsletter tool, your appointment reminder system, your e-signature tool, your help desk software, any third party that sends on your behalf. The platforms leave that decision to you.
The result: a lot of small businesses have SPF, have DKIM, and have no DMARC at all — or have p=none that someone set up years ago and never moved past. The domain looks like it has authentication. It doesn’t have enforcement. This is exactly the kind of gap that proactive IT management is designed to catch before it becomes a problem.
How to check your own domain right now
You can find out where your domain stands in about two minutes without installing anything or logging into anything. MXToolbox’s DMARC lookup tool takes a domain name and returns what SPF, DKIM, and DMARC records exist for it. Dmarcian’s domain checker does the same thing with a slightly different presentation.
What you’re looking for: an SPF record exists and lists your actual mail providers. A DKIM record exists for the selectors your mail platform uses. A DMARC record exists and the policy is set to quarantine or reject — not none.
What you’ll commonly find on a small business domain that hasn’t had this work done:
- SPF exists but is outdated — it authorizes a previous mail provider you migrated away from years ago, or doesn’t include a marketing platform you’ve since added.
- DKIM exists for one platform but not for the others sending mail in your name.
- DMARC is missing entirely, or it exists at
p=noneand has been sitting there since the day it was created.
Any of these is a real gap. All three at once is the default state of a domain that’s never been audited.
Why this isn’t a do-it-yourself project past the lookup
Reading a DMARC report is straightforward. Moving a domain from p=none to p=reject without breaking legitimate mail is not. The process requires inventorying every system that sends email in your name — Microsoft 365 or Google Workspace, your CRM, your accounting software, your newsletter platform, your appointment reminder system, your e-signature tool, your help desk software, any third party that sends on your behalf — and making sure each of those is properly authorized in SPF and signing with DKIM before you turn on enforcement.
Get this wrong and your invoices stop arriving. Your appointment reminders go to spam. Your tax organizer never reaches the client. The fix isn’t conceptually hard, but it requires the kind of careful, staged work that goes wrong when someone is doing it in spare moments between other tasks. Proper email security configuration is one of those things that benefits from having a dedicated team handle it end to end.
What to do with what you just learned
Run your domain through one of the lookup tools above. If you have SPF, DKIM, and DMARC at p=reject with reports going somewhere a human actually reads them, you’re in good shape and the rest of this is academic. If any of those pieces is missing — and for most small businesses, at least one is — you have a real exposure that’s silently waiting for the day someone decides to use your domain to phish your clients.
Email authentication is one of the things ForeverOn‘s free security assessment covers as a matter of course. Erik’s two-visit assessment process gathers data on the first visit and presents findings visually on the second — color-coded charts that show where the gaps are and which ones are urgent. Email authentication is usually one of them. So are backups stored where ransomware can’t reach them, endpoint protection that actually has a human watching the alerts, and the half-dozen other controls that quietly determine whether your business is exposed or protected.
If the MXToolbox results showed gaps, that’s a starting point — not a complete picture. Call (301) 739-7311 or book a free consultation. We answer the phone with a real person, we explain what we find in plain English, and we’ll tell you what needs attention without trying to sell you anything you don’t need. For businesses in Washington County, Frederick County, and the surrounding Maryland area, that conversation is the fastest way to find out what else is sitting in the same blind spot as your email authentication.