Why Someone Might Be Sending Email as You & How to Stop It

A few months ago, a small accounting firm I know had a client call in, furious, asking why they’d been sent an invoice demanding payment to a new bank account. The email had come from the firm’s actual domain. Same logo, same signature, same tone their real accountant used. Except nobody at the firm had sent it.

That’s the moment most business owners first hear the word “spoofing” — usually right after it’s already cost them a client’s trust, and sometimes their money. The frustrating part is that the fix for this has existed for over a decade. Most companies just never got around to turning it on.

This isn’t a scare piece. It’s a practical walkthrough of how email authentication actually works, why so many businesses skip it, and what it takes to close the gap — written for people who don’t want to become email security experts, they just want their domain to stop being a costume other people wear.

The Problem Nobody Explains Well

Email, as a protocol, was built in an era when the internet was mostly universities and research labs trading files. Nobody designed it to verify who was actually sending a message. The “From” field is essentially a label you write yourself — there’s nothing stopping a sender from typing in any address they like, including yours.

That gap is why phishing works. An attacker doesn’t need to hack your servers or steal your password. They just need to know your domain name, which is public information by definition, and they can send email that looks like it came from you. Your customers see your name, trust it, and click.

Three protocols exist specifically to close this gap: SPF, DKIM, and DMARC. Most companies have heard of at least one. Fewer have all three set up correctly, and fewer still understand how they work together.

SPF: The Guest List

SPF, or Sender Policy Framework, is essentially a guest list published in your domain’s DNS records. It tells the internet which mail servers are allowed to send email on your behalf. Your company’s mail server is on the list, your marketing platform might be on the list, but a stranger’s server in another country is not.

When an email arrives claiming to be from your domain, the receiving mail server checks that guest list. If the sending server isn’t on it, that’s a red flag. SPF alone catches a good chunk of spoofing, but it has a well-known blind spot: it doesn’t survive forwarding. If someone forwards your email through their own server, SPF often fails even for a completely legitimate message. That’s part of why SPF was never meant to work alone.

DKIM: The Wax Seal

DKIM, or DomainKeys Identified Mail, works differently. Instead of checking where a message came from, it checks whether the message itself has been tampered with. Your mail server attaches a digital signature to every outgoing email, generated using a private key only you control. The receiving server checks that signature against a public key published in your DNS.

Think of it like a wax seal on an old letter. If the seal is intact and matches the sender’s stamp, you know the letter wasn’t opened and altered in transit. If it’s broken or doesn’t match, something’s wrong. DKIM survives forwarding better than SPF because it’s tied to the message content, not the sending server’s IP address.

DMARC: The Rulebook That Ties It Together

Here’s where it gets interesting, and where most companies stop paying attention too early. SPF and DKIM are useful, but on their own they don’t actually tell receiving mail servers what to do when a message fails either check. Without instructions, most inboxes just shrug and deliver the email anyway, spam folder or not, leaving the decision entirely up to the receiving side’s judgment.

DMARC, or Domain-based Message Authentication, Reporting and Conformance, is the policy layer that fixes this. It tells receiving servers exactly what to do when a message claiming to be from your domain fails SPF or DKIM: quarantine it, reject it outright, or just monitor and report on it for now. It also creates a feedback loop — DMARC reports show you who is sending email using your domain, including the attackers you didn’t know about.

This is the part that turns email authentication from a checkbox into an actual defense. A domain with SPF and DKIM but no DMARC policy is like having security cameras with nobody watching the footage. The visibility exists, but nothing acts on it.

Why So Many Businesses Skip This

If DMARC is this important, why isn’t it universal? A few honest reasons come up again and again.

It looks technical from the outside. DNS records, cryptographic signatures, policy tags — the vocabulary alone scares off a lot of business owners and even some IT generalists who aren’t specifically focused on email infrastructure.

Nobody wants to break email by accident. This is the legitimate fear, and it’s not unfounded. A misconfigured DMARC record set to “reject” before you’ve verified every legitimate sending source (your CRM, your invoicing tool, your support platform) can silently block real customer emails. That’s a scarier outcome to a lot of people than doing nothing.

It doesn’t feel urgent until it is. Nobody budgets time for DMARC the same week they budget time for a new website or a product launch. It sits in the “someday” pile until a spoofing incident, a failed deliverability audit, or a client complaint forces the issue.

The good news is that the technical barrier is much lower than it used to be, and the “breaking email” fear is manageable if you approach the rollout the right way.

A Realistic Rollout, Not a Big Bang

The mistake most companies make, when they finally do get around to DMARC, is trying to jump straight to full enforcement. Don’t. There’s a sequence that professionals in this space follow for a reason.

Step one: start in monitor mode. Set your DMARC policy to “none” first. This does nothing to block or quarantine mail, but it turns on reporting. For a few weeks, you’ll receive aggregate reports showing every server sending email that claims to be from your domain — your real mail server, your marketing platform, your invoicing software, and, if you’re unlucky, an attacker or two.

Step two: fix what the reports surface. This is usually where people discover services they forgot were sending email on their behalf, like an old newsletter tool or a CRM integration that was set up years ago and never documented. Add each legitimate source to your SPF record, make sure it’s DKIM-signed properly, and keep monitoring.

Step three: move to quarantine. Once your reports show that only legitimate senders are passing authentication, shift your policy from “none” to “quarantine.” Failing messages now get routed to spam instead of the inbox, giving you a safety net if something was missed.

Step four: move to reject. After a stretch of clean quarantine reports, you can move to full enforcement. Messages that fail authentication get rejected outright, before they ever reach the recipient’s mailbox. This is the endpoint most security-conscious businesses are aiming for, and it’s the setting that actually stops spoofed email from doing damage.

Skipping straight to reject without this staged approach is how legitimate email gets silently dropped, and how companies end up rolling DMARC back entirely out of frustration.

Building the Record Itself

The trickiest part for most people isn’t understanding the concept, it’s getting the syntax right. A DMARC record lives in your DNS as a TXT record, and it needs specific tags in a specific format: your policy setting, the percentage of mail it applies to, where aggregate and forensic reports should be sent, and a handful of optional alignment settings. One misplaced semicolon or a malformed email address in the reporting tag, and the whole record can silently fail to work as intended.

This is where a purpose-built DMARC Record Generator earns its keep. Instead of hand-writing the TXT record from a syntax reference and hoping you didn’t typo a tag, a generator walks you through each setting, plain-language explanations included, and outputs a record that’s actually valid DNS syntax the first time. For anyone rolling this out without a dedicated email security team on staff, that’s the difference between an afternoon project and a week of trial and error.

Reading the Reports Without Losing Your Mind

DMARC’s aggregate reports arrive as XML files, which is a polite way of saying they’re unreadable to a normal human. Raw, they look like a wall of angle brackets and IP addresses. This is genuinely the part that turns people off DMARC even after they’ve set the record up correctly.

You don’t need to parse XML by hand. Most DMARC platforms, including the free and paid tools built around the protocol, translate these reports into a dashboard: which servers are sending on your behalf, what percentage are passing authentication, and where the failures are coming from geographically. That last part is often the most eye-opening. Seeing a spike in “failed” senders from a country your company has no business ties to is a very concrete way to understand why this matters.

What Changes Once It’s Actually On

Companies that get DMARC to full enforcement report two things consistently: fewer spoofed emails reaching their customers, and — somewhat unexpectedly — better deliverability for their own legitimate email. That second point surprises people. But major inbox providers like Google and Yahoo have increasingly tied deliverability to authentication status. Domains without a working DMARC policy are more likely to see their legitimate marketing and transactional email routed straight to spam, authentication problems or not. Setting up DMARC properly isn’t just defense against impersonation; it’s increasingly table stakes for your email actually landing in front of the people you’re sending it to.

The Bottom Line

None of this requires a security background to get right. It requires patience, a staged rollout, and tools that handle the syntax so you don’t have to memorize DNS tag formatting. Start in monitor mode, fix what the reports show you, move through quarantine, and land at reject once you’re confident. Somewhere in that first week, generate the record correctly instead of guessing at it, and the rest of the process gets a lot less stressful.

The accounting firm from the beginning of this piece eventually did roll out DMARC, after the fact, the way most companies do. It’s a more expensive way to learn the lesson than setting it up before you need it. Either way works. One just costs a lot less.