← Back to Blog

Stopping Someone From Sending Email as Your Business

A customer calls about an invoice. They paid it last week, to the updated bank details in the email. You have no record of the invoice, no record of the email, and no updated bank details.

Nobody broke into your systems. Nobody guessed a password. Someone typed your company name and your email address into the From line of a message they sent from their own server, and it arrived looking close enough to real.

This is the part of email security that has nothing to do with training your staff. Your team never saw that message; your customer did. Fixing it happens once, in your domain settings, and it protects everyone who receives mail claiming to be from you.

The From Line Is a Claim, Not a Fact

Email was designed in an era when everyone on the network was trusted, and that assumption is still in the protocol. The From address on a message is simply text the sender writes. There is no built-in check that the sender has any connection to the domain they typed.

So the question a receiving mail server has to answer is: should I believe this? The three records below are how you give it an answer. Without them, the receiving server is guessing, and its guess is usually generous, because rejecting legitimate mail annoys its users more than delivering a fake one does.

The Three Records

All three live in your domain’s DNS, the same place your website and mail routing are configured, usually at your domain registrar or wherever your DNS is hosted. None of them are products you buy.

RecordWhat it answersWhat it does not do
SPFWhich servers are allowed to send mail for this domain?Doesn’t protect the visible From address a person actually reads
DKIMWas this message altered in transit, and does it carry a valid signature from the domain?Doesn’t tell the receiver what to do if the check fails
DMARCIf SPF and DKIM fail, what should the receiver do, and who should be told?Doesn’t stop mail from lookalike domains you don’t own

SPF (Sender Policy Framework) is a list of the servers permitted to send on your behalf: Microsoft 365 or Google Workspace, your email marketing platform, your accounting software, your CRM, the scanner in the hallway that emails PDFs.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each outgoing message. The receiver checks the signature against a public key published in your DNS. If the message was tampered with, the signature breaks.

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the one that closes the loop. SPF and DKIM produce results; DMARC is your instruction for what to do with those results, and it’s also the only one that sends you reports about who is sending mail as your domain.

That reporting is the part small businesses tend to underestimate. Before you enforce anything, DMARC will tell you, from actual receiving servers, every system sending mail under your name, including the ones nobody remembered.

Why This Is Worth Doing Even If Nobody Has Spoofed You

Two reasons, and the second one is usually what gets it scheduled.

Your real mail gets delivered. Authentication is now a significant factor in whether legitimate messages reach the inbox. Google and Yahoo began requiring SPF, DKIM, and DMARC for bulk senders in February 2024, and Microsoft announced similar requirements for high-volume senders to Outlook.com accounts in 2025. Each of the three has added authentication requirements rather than relaxed them. If your quotes and invoices are landing in customers’ junk folders, unauthenticated mail is one of the first things to check.

Your customers are increasingly asking. Vendor security questionnaires now routinely include email authentication, and it’s a fast question to fail. It’s also one of the cheaper items on those forms to actually fix. See our guide to what insurers and customers are asking small businesses to prove.

Rolling It Out Without Breaking Your Mail

The order matters. The businesses that break their own mail doing this are the ones that skip straight to enforcement.

1. Inventory everything that sends as you

Before touching DNS, list every system that sends email with your domain in the From address. Start with the obvious: your mail platform, your marketing tool, your accounting or invoicing software. Then find the quiet ones: the CRM that emails quotes, the scheduling tool that sends reminders, the website contact form, the multifunction printer, the shipping platform.

This list is the whole job. SPF and DKIM are trivial to configure once you know what belongs on them.

2. Publish one SPF record

One. This is the most common mistake in the whole process: a domain with two SPF records is invalid, and mail servers treat it as a permanent error rather than picking one. Every sending service goes into a single record.

SPF also has a limit of ten DNS lookups per evaluation, and each service you include typically consumes one or more. Businesses using several marketing and sales platforms hit that ceiling and quietly break SPF for everything.

3. Turn on DKIM everywhere

Enable DKIM signing in your mail platform, then in every third-party sender that supports it. Most now do, and most walk you through it: they give you records to publish, you publish them, you click verify.

4. Start DMARC at monitoring only

Publish a DMARC record with a policy of p=none and a reporting address. This changes nothing about how your mail is handled; it just asks receiving servers to send you reports.

Then read them for a few weeks. You are looking for legitimate senders that are failing, which is nearly always something from step 1 that nobody knew about. Fix those before enforcing anything.

5. Move to quarantine, then reject

Once your legitimate mail is authenticating cleanly, move to p=quarantine, where failing messages go to junk rather than the inbox. Watch for a few more weeks, then move to p=reject, where failing messages are refused outright.

p=reject is where spoofing actually stops. A domain sitting at p=none forever is a domain that gets monitored but never defended, and it’s an easy place to stall. Put a date on the next step when you publish the first record.

What It Doesn’t Cover

Being clear about the limits matters, because this is a control people over-trust once it’s in place.

Lookalike domains. DMARC protects the domain you own. It does nothing about quantech-it.com or quantechit.co, a domain the attacker registered and can authenticate perfectly well, because they own it. Worth checking periodically whether close variants of your domain have been registered, and worth registering the most obvious ones yourself.

Display name spoofing. A message from a personal Gmail account with the display name set to your owner’s name passes every check, because it isn’t claiming to be your domain. On a phone, most people only see the display name. This is a training problem, and it’s covered in our post on phishing awareness training that changes behavior.

A genuinely compromised account. If an attacker is logged into a real mailbox, their messages are authentically yours. That’s what multi-factor authentication (MFA) and Microsoft 365 hardening are for.

Email authentication answers one narrow question well: is this server allowed to send as this domain? It’s worth having a clear answer to that question, and worth knowing what remains after you do.

Where to Start

If you have no idea whether any of this is configured, that’s the normal starting position. You can look up your own domain’s SPF and DMARC records in a few seconds with any public DNS lookup tool. Finding no DMARC record is an ordinary, unsurprising place to begin; it just means the work hasn’t been done yet.

The work itself is a few hours of configuration and a few weeks of watching reports. What makes it drag is the inventory step, and specifically the systems nobody remembers until the report shows them failing.

If you’d like to know where your email authentication stands, and what else in your setup would show up on a customer’s security questionnaire, our free Technology & Growth Review is a 60-minute session covering cybersecurity, technology, and AI readiness. You leave with a written action plan you can execute with or without us.