SPF, DKIM, and DMARC: How to Stop Scammers From Faking Your Email

Here is an uncomfortable little experiment you can run in about thirty seconds. Open your email, start a new message, and picture how much of the "From" line you actually control. The display name? You typed that. Now imagine a piece of software where the sender gets to type the whole thing, including the address, and nothing checks whether they are telling the truth.

That software is email. All of it. Every provider.

When email was designed back in the early 1980s, the internet was a small, trusting neighborhood of universities and research labs. Nobody thought to build in a way to verify who a message really came from, because why would you lie to your colleagues? That original sin never got fixed at the core. So to this day, sending an email claiming to be from ceo@yourcompany.com is roughly as hard as writing "The CEO" on the return corner of an envelope. Anyone can do it. This is called spoofing, and it is the foundation of a huge chunk of the scams aimed at small businesses.

The good news, and there is genuinely good news here, is that we bolted three fixes onto email over the years. They are called SPF, DKIM, and DMARC. Set them up correctly and you slam the door on people pretending to be your business. Let me walk you through exactly how they work and how to turn them on.

Why this matters more than you think

Spoofing is not a theoretical problem. In its 2024 Internet Crime Report, the FBI's Internet Crime Complaint Center logged 193,407 phishing and spoofing complaints, the single most-reported crime category by volume. And the money involved is staggering: business email compromise, the scam where a criminal impersonates a trusted party to trick someone into wiring money or changing payment details, caused $2.77 billion in losses across 21,442 reported incidents in 2024 alone, according to the FBI's figures. The FBI has separately flagged BEC as a $55 billion problem over the last decade. Total cybercrime losses hit a record $16.6 billion, up 33% from the year before.

A lot of that starts with a forged "From" address. A scammer emails your accounts-payable person "from" you, asking them to pay a new invoice. Or emails your customers "from" your domain, sending them to a fake login page. Because the message looks like it came from your real address, your normal advice ("check the sender") fails completely. This is social engineering with a perfect disguise.

Here is the part most articles skip: the fix does not live in your email software. It lives in DNS. DNS (Domain Name System) is the internet's address book. It is the service that quietly turns a name you can remember, like managednerds.tech, into the numeric address computers actually use to find each other. It also stores little text notes about your domain, and those text notes are exactly where SPF, DKIM, and DMARC live. If you want the deeper story on why the address book itself is a security battleground, we wrote a whole piece on DNS security. For today, just hold onto this: these three records are notes you publish in your domain's address-book entry, and receiving mail servers read them to decide whether an email claiming to be from you is legit.

Let's dig in.

SPF: the guest list at the door

SPF stands for Sender Policy Framework. Think of it as a guest list you post at the front door.

An SPF record is a single line of text you publish in DNS that lists every mail server allowed to send email on behalf of your domain. Your email host (say, Google Workspace or Microsoft 365), your newsletter tool, your invoicing software, your CRM: each one uses specific servers to send mail, and SPF names them.

When a receiving server gets a message claiming to be from you, it looks up your SPF record and asks a simple question: "Did this actually come from one of the servers on the list?" If yes, the message passes SPF. If it came from some random server in a basement that is not on your list, it fails.

A real SPF record looks like this, published as a TXT record on your domain:

yourdomain.com   TXT   "v=spf1 include:_spf.google.com include:sendgrid.net -all"

In plain English: "Valid mail for this domain comes from Google's servers and SendGrid's servers. Anything else (-all), reject." The guest list is short and explicit, which is the whole point.

SPF's weakness: it checks a behind-the-scenes address called the "envelope sender," not the "From" address your reader actually sees. It also breaks when email gets forwarded, because the forwarding server is not on your list. SPF alone is helpful but leaky. That is why we have two more layers.

DKIM: the tamper-proof wax seal

DKIM stands for DomainKeys Identified Mail. If SPF is the guest list, DKIM is a tamper-proof wax seal on the envelope.

Here is the idea. Your mail server holds a secret private key. Every time it sends a message, it uses that key to generate a unique cryptographic signature and stamps it onto the message headers. You publish the matching public key in DNS. When a receiving server gets the message, it uses your published public key to check the seal.

That check proves two things at once: the message really was signed by your domain, and it has not been altered in transit. If a scammer tampers with even a comma, the seal breaks and DKIM fails. And because the scammer does not have your private key, they cannot forge a valid seal in the first place. It is genuinely clever: a wax seal you cannot fake and cannot re-close once broken.

The public key lives at a "selector" address in DNS and looks like this (the key itself is a long string, trimmed here):

selector1._domainkey.yourdomain.com   TXT   "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQ...longkey...QAB"

The good news is you almost never type this by hand. Your email provider generates the key pair for you and gives you the DNS record to paste in. Your job is to turn it on and publish the record.

DKIM's weakness on its own: a receiving server can verify the seal is valid, but nothing tells it what to do when the seal is missing or broken. That decision needs a policy. Enter the third piece.

DMARC: the head of security who makes the call

DMARC stands for Domain-based Message Authentication, Reporting and Conformance, which is a mouthful that basically means "the rulebook that ties SPF and DKIM together." Picture the head of security standing behind the door. The guest list and the wax seal do the checking; DMARC decides what happens to anyone who fails, and files a report about it.

DMARC does three jobs.

First, it enforces alignment. This is the concept that makes the whole system actually stop spoofing, so stay with me. A message can technically pass SPF or DKIM while the address your reader sees still belongs to someone else, because SPF and DKIM check those behind-the-scenes domains, not the visible "From." Alignment closes that gap: DMARC requires that the domain which passed SPF or DKIM matches the domain in the visible "From" address. No match, no pass. That single rule is what prevents a scammer from borrowing a legitimate-but-unrelated domain to sneak past the checks.

Second, it sets the policy. Your DMARC record tells receiving servers what to do with mail that fails these checks, using one of three settings:

• p=none (do nothing, just report). This is monitoring mode.
• p=quarantine (send failing mail to the spam or junk folder).
• p=reject (refuse failing mail outright, so it never reaches the inbox).

Third, it sends you reports. DMARC asks receiving servers to email you daily summaries of who is sending mail claiming to be from your domain, and whether it passed or failed. This is how you discover both your own legitimate senders and the impostors.

A starter DMARC record looks like this:

_dmarc.yourdomain.com   TXT   "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100"

Here p=none is the policy, and rua=mailto: is the address where you want the reports sent.

The policy progression: none, then quarantine, then reject

Here is the mistake people make: they set p=reject on day one, immediately break their own newsletter and invoicing tool because those were not properly authenticated yet, and panic. Do not do that.

DMARC is designed to be tightened in stages, like slowly turning up a dial:

1. Start at `p=none`. Nothing gets blocked. You just collect reports for a few weeks and learn exactly which servers send mail as you. Almost everyone is surprised to find a legitimate service or two they forgot about.
2. Fix your senders, making sure every legitimate tool passes SPF or DKIM with alignment. Then move to p=quarantine, optionally on a percentage of mail first (that is what pct= controls). Failing mail now goes to spam instead of the inbox.
3. Graduate to `p=reject` once your reports are clean. Now impostors are refused at the door, full stop. This is the goal. Only p=reject (and p=quarantine) actually protect you; p=none is a security camera with the doors still unlocked.

That last point is not just an opinion. Of the roughly 937,931 domains that publish a valid DMARC record, only about 9% are actually protected at an enforcement policy, according to DMARC adoption research. More than half sit at p=none, doing nothing but watching. Publishing the record is the easy part that most people stop at. Reaching enforcement is what counts, and it is where you want to be.

Reading a DMARC report without a headache

Raw DMARC reports arrive as XML attachments, which look like machine soup and are miserable to read by hand. Do not try. Sign up for a free or low-cost DMARC reporting dashboard (Valimail, Dmarcian, Postmark, and others offer them) and point your rua= address at their service. They turn the soup into a simple picture: here are the servers sending as you, here is which ones pass, and here is the suspicious traffic failing your checks.

What you are looking for is straightforward. Legitimate senders you recognize should be passing. Anything failing that you do not recognize is either a service you forgot to authenticate (fix it) or someone spoofing you (which enforcement will now block). When the failing column is nothing but junk you do not care about, you are ready to move the dial toward p=reject.

A quick word on BIMI

Once you reach DMARC enforcement, you unlock a bonus called BIMI (Brand Indicators for Message Identification). BIMI lets your company logo appear next to your emails in supporting inboxes like Gmail, and with the right certificate, a verified checkmark too. In 2024 Gmail expanded BIMI support to include Common Mark Certificates, which opened it up to smaller brands without a registered trademark. It is published as one more DNS record and requires DMARC at quarantine or reject first. Think of it as the reward for doing the security work: your real mail gets a visible badge of authenticity, making the fakes look even more obviously wrong.

This is no longer optional: the Google and Yahoo rules

If you needed a deadline to take this seriously, the two biggest mailbox providers gave you one. In February 2024, Google and Yahoo rolled out new requirements for bulk senders, defined as anyone sending more than 5,000 messages a day to their users. Those senders now must:

• Authenticate mail with both SPF and DKIM.
• Publish a DMARC record (at minimum p=none) with alignment.
• Keep spam complaints below a 0.3% threshold.
• Offer one-click unsubscribe on marketing mail.

You can read the specifics in Google's official sender guidelines, and Proofpoint has a clear breakdown of what each requirement means in practice. Even if you send nowhere near 5,000 a day, the direction is unmistakable: authenticated email increasingly lands in the inbox, and unauthenticated email increasingly lands in spam or gets rejected. Setting up these records is now table stakes for your legitimate mail actually being delivered, never mind the security benefit.

Your setup plan

Here is the concrete, do-this-order checklist. Most of it happens in your domain registrar or DNS host's control panel, and none of it requires touching code.

1. Inventory your senders. List every service that sends email as your domain: your email host, newsletter platform, invoicing or CRM tool, appointment software, e-commerce platform. You cannot authenticate what you have not accounted for.
2. Publish one SPF record. Create a single SPF TXT record that includes all those senders, ending in -all. One record only per domain; do not create several.
3. Turn on DKIM everywhere. In each sending service, enable DKIM signing and paste the DNS record it gives you. Each service gets its own selector, so multiple DKIM records is normal and fine.
4. Publish DMARC at `p=none`. Add the _dmarc TXT record with a monitoring policy and an rua= reporting address.
5. Connect a reporting dashboard. Point that rua= address at a DMARC reporting tool so the reports are readable.
6. Watch for a few weeks, then fix gaps. Make sure every legitimate sender passes with alignment. Chase down the surprises.
7. Tighten to `p=quarantine`, then `p=reject`. Move the dial once your reports are clean. This is the step that actually stops the spoofing.
8. Add BIMI (optional). Once you are at enforcement, publish a BIMI record to get your logo in the inbox.

If any of that feels like more than you want to own, especially the part where you tighten enforcement without breaking your own mail, this is exactly the kind of unglamorous, high-leverage work that small business cybersecurity is meant to handle for you.

You now understand the one gap that lets scammers wear your business's face, and the three records that close it. Set up SPF, DKIM, and DMARC, walk the policy from none to reject, and the "From: you" scams simply stop reaching the people who trust your name.