DMARC, SPF, and DKIM: The Three Records That Stop Someone Spoofing Your Domain

SPF, DKIM, and DMARC are three DNS records that let a small business prove which email really comes from its domain, and ask every receiving server to reject the forgeries instead of delivering them.

Victims reported $3,046,598,558 in business email compromise losses in 2025, across 24,768 complaints to the FBI’s Internet Crime Complaint Center. Only investment fraud cost more. Not all of that started with a forged sender address. Some of it came from a real mailbox that had been taken over, and some from a lookalike domain one letter off from the real one.

These three records close one specific door, and they sit inside the cybersecurity baseline VJNetworks puts in place for the businesses we support. The door where a stranger sends mail claiming to come from your exact domain. It is also the cheapest one to close. We walked through how the scam itself plays out in Business Email Compromise 101. This is the technical companion.

What Each Record Actually Does

All three live in DNS, the same public directory that tells the internet where your website and your mail server are. Publishing them is free. Each answers a different question.

SPF is a guest list. You publish the servers allowed to send mail for your domain, and receiving servers check the sending server against it. DKIM is a tamper-evident seal. Your mail system signs every outgoing message with a private key, and anyone can check the signature against the public key you publish. DMARC is the rule that ties the other two to the name people actually read. The From line.

Owners miss that part. Microsoft’s documentation puts the test plainly. A message passes DMARC if one or both of the SPF or DKIM checks pass for a domain that aligns with the From address, and fails if both fail.

Why SPF Alone Never Stopped the Fake Invoice

Every email carries two sender addresses. One is the envelope sender that mail servers use to route bounces. The other is the From line that appears in Outlook. SPF checks only the first.

So a forger registers any throwaway domain, publishes a perfectly valid SPF record for it, and uses that domain as the envelope sender. SPF passes. For the forger’s domain. Meanwhile the From line your bookkeeper sees says your CEO’s name at your company’s domain, and nothing in SPF objects. Nothing in DKIM objects either, because the forger simply signs with their own domain or does not sign at all.

DMARC closes that gap. It asks whether the domain that passed SPF, or the domain that signed with DKIM, is the same domain printed in the From line. If neither matches, the message fails, and your DMARC policy tells the receiving server what to do about it. Without DMARC, the receiver has to guess. Guessing is how the invoice gets paid.

The Microsoft 365 Gap Most Offices Never Hear About

Start with Microsoft 365. Setting up a custom domain in Microsoft 365 already required an SPF record. For a domain that sends only through Microsoft 365, Microsoft’s recommended record is v=spf1 include:spf.protection.outlook.com -all, and Microsoft recommends the hard-fail ending -all rather than the softer ~all, because DMARC can then act on a message that fails SPF even when that message carries no DKIM signature at all.

DKIM is the gap. Microsoft’s current documentation says it outright. For custom domains, “no DKIM signing occurs for outbound mail” until someone configures it. Turning it on means publishing two CNAME records, selector1._domainkey and selector2._domainkey, wherever your DNS is hosted, then enabling signing for the domain in the Microsoft Defender portal. The work itself is short. It is also easy to go years without it, because nothing visibly breaks. Mail still flows.

Google Workspace works differently. Same goal. An administrator generates a DKIM key in the Admin console, publishes it as a TXT record, and clicks Start authentication. Google recommends a 2048-bit key wherever the DNS host supports one.

Then come the other senders. The newsletter platform. The payroll service that emails pay stubs. The e-signature tool, the accounting software that sends invoices, the website contact form, and the copier that scans to email. Each one either needs a place in your SPF record or needs to sign with DKIM using your domain. SPF also has a ceiling. RFC 7208 limits an SPF check to 10 DNS lookups, and a record that needs more returns a permanent error. You also get exactly one SPF record per domain. Two of them count as an error too, which happens more often than it should when someone adds a new service by pasting a second record instead of editing the first.

Microsoft’s answer for services you do not control is a subdomain. Put marketing mail on something like marketing.yourdomain.com, give it its own SPF and DKIM, and a newsletter that draws spam complaints or a vendor that changes its sending servers stays walled off from the reputation of the domain your staff use for invoices and client mail. Our Microsoft 365 management covers this kind of tenant housekeeping.

Rolling Out DMARC Without Blocking Your Own Mail

A DMARC record has three policy settings, and they do very different things.

Here is the uncomfortable part. A domain sitting at p=none has a DMARC record and no DMARC protection. Forged mail still gets delivered. The record is doing reconnaissance, which is useful, but it is not a lock. Microsoft’s own guidance for Outlook senders is to move gradually, none to quarantine to reject, precisely because jumping straight to reject blocks your own forgotten senders along with the forgers.

The sequence looks like this.

1. Publish DMARC at p=none with an rua address, so receiving servers send daily aggregate reports.
2. Read the reports. Every source that sends as your domain shows up by IP address, pass or fail.
3. Fix each legitimate sender that fails, by adding it to SPF or turning on DKIM signing with your domain.
4. Move to p=quarantine. Keep reading.
5. Move to p=reject when nothing legitimate is failing.

The reports arrive as compressed XML files, one per receiving provider per day, and because they are not written for people, they belong in a dedicated mailbox that someone checks on a schedule rather than in anyone’s personal inbox. Expect gaps, too. Microsoft notes that not every receiver sends reports, and that coverage typically lands between 70% and 90% of your total mail volume.

One housekeeping note for anyone reading the standards. In May 2026 the IETF published RFC 9989, which replaces the original 2015 DMARC specification and moves it onto the standards track. For a small business the visible changes are small. The old pct tag is retired in favor of a t tag for testing, and a new np tag sets policy for subdomains that do not exist.

Parked Domains Need Records Too

If you took the advice in our BEC post and registered a few misspellings of your own domain, those domains need email records even though nobody sends mail from them. Otherwise they invite forgery. Microsoft’s guidance for a parked domain is two records and a deliberate absence. An SPF record of v=spf1 -all, which says no server is authorized. A DMARC record of v=DMARC1; p=reject;. And no DKIM record at all, because a missing public key means a forged signature cannot validate. The same DMARC record belongs on the .onmicrosoft.com domain every Microsoft 365 tenant carries, if you never send from it.

Why the Big Mailbox Providers Stopped Asking Nicely

For years this was optional. Not anymore. Since February 1, 2024, Google requires everyone sending to Gmail accounts to set up SPF or DKIM, and anyone sending roughly 5,000 or more messages a day to Gmail must have SPF, DKIM, and DMARC, with the From domain aligned. Microsoft applied the same three requirements to senders of more than 5,000 messages a day to Outlook.com, Hotmail, and Live addresses starting May 5, 2025.

A twelve-person office rarely sends 5,000 messages a day. The baseline rule applies anyway. And the federal government settled the question for its own agencies years ago. CISA’s Binding Operational Directive 18-01, issued in October 2017, required every federal agency to reach a DMARC policy of reject within one year.

What These Records Will Not Do

DMARC protects your exact domain. That is all it protects, and it is worth being precise about the rest.

A lookalike domain, one character off from yours, can publish its own perfectly valid SPF, DKIM, and DMARC and pass every check. A message from a free email account that simply puts your owner’s name in the display name passes too, because the domain belongs to the free provider. And if a real mailbox in your company is compromised, the attacker’s mail comes from your domain, signed by your own system, and passes everything. Multi-factor authentication, phishing filters, and a payment-verification habit are the defenses there. DNS records are not. Forwarding can also break SPF along the way, which is one more reason to have DKIM signing in place, since a DKIM signature usually survives forwarding when the message body is left unchanged.

Where we come in. SPF, DKIM, and DMARC are part of the email security baseline VJNetworks puts in place, alongside phishing filters and awareness training. If you want us to run the whole thing, managed IT starts at $995 a month, someone from my team responds within 15 minutes during business hours, and we have kept a 97% client retention rate over 20 years in the Tri-State area.

Questions We Get About Email Authentication