SPF, DKIM, and DMARC for Small Business: Stop Spoofing and Land in the Inbox

Two complaints land in my inbox more than almost any others from Central Coast business owners. The first is "our invoices keep going to clients' spam folders, and we look unprofessional." The second is "someone sent our customer a fake email pretending to be us, and they almost paid it." They sound like different problems. They have the same root cause and, largely, the same fix: email authentication, the set of three DNS records known as SPF, DKIM, and DMARC.

This is one of those unglamorous controls that quietly decides whether your business looks trustworthy to the rest of the internet and whether a criminal can wear your domain like a mask. It is also one of the most commonly half-finished. Plenty of businesses have one or two of the records in place and assume they are covered, when the one record that actually stops spoofing is missing or switched off. Here is what each piece does, why the big email providers suddenly started demanding all three, and how to turn them on without accidentally blocking your own mail.

The problem: email was built to trust the sender

Email's original design has a flaw that has aged badly: the "From" address is just text the sender types. Nothing about the basic protocol stops a stranger from putting your address in the From line and sending mail that, to the recipient, looks exactly like it came from you. That is not a hack; it is how the system was built in a more trusting era.

SPF, DKIM, and DMARC are the patches the industry bolted on to fix it. Together they let a receiving mail server answer a simple question, "is this message really from the domain it claims?", and act on the answer. Without them, your domain is an open costume anyone can wear. With them set up correctly, an impersonator's mail gets rejected before it reaches your client or your bookkeeper.

The three records, in plain English

You do not need to read DNS syntax to make good decisions here. You do need to understand what each record is for.

• SPF (Sender Policy Framework) — the guest list. A record in your DNS that lists the mail servers allowed to send email on your behalf: your Microsoft 365 or Google Workspace, plus any other service that sends as you. A receiving server checks the sending server against this list. If it is not on the list, that is a red flag.
• DKIM (DomainKeys Identified Mail) — the tamper-proof seal. Your mail server adds an invisible cryptographic signature to every message you send. The receiver checks that signature against a public key published in your DNS. A valid signature proves the message genuinely came from your domain and was not altered in transit. A missing or broken one is another red flag.
• DMARC (Domain-based Message Authentication, Reporting and Conformance) — the policy and the enforcement. This is the one that ties it together and the one businesses most often skip. DMARC tells receiving servers what to do when a message claiming to be from your domain fails both SPF and DKIM: do nothing, send it to spam, or reject it outright. It also sends you regular reports showing every system sending mail under your name, including the impersonators.

The mental model: SPF and DKIM are the two proofs of identity. DMARC is the bouncer who decides what happens to anyone whose proof does not check out, and who keeps the logbook. You can have SPF and DKIM perfectly configured and still be wide open to spoofing if DMARC is missing or set to take no action, which is exactly the state we find most often.

Why this stopped being optional in 2024 and 2025

For years, email authentication was a best practice that most small businesses ignored without obvious consequences. That changed when the largest mailbox providers ran out of patience with the flood of spam and fraud.

• February 2024: Google and Yahoo began requiring bulk senders — broadly, those sending more than 5,000 messages a day to their users — to authenticate with SPF, DKIM, and DMARC, offer one-click unsubscribe, and keep spam complaints below a set threshold. Mail that did not comply started getting rejected or buried.
• May 2025: Microsoft followed suit for high-volume senders to Outlook.com, Hotmail, and Live.com addresses, requiring the same SPF, DKIM, and DMARC baseline.

The thresholds are aimed at high-volume senders, so a small office is not going to trip them on day one. But the direction of travel is unmistakable, and it does not stop at the headline number. Spam filters increasingly treat authentication as a trust signal for everyone: a properly authenticated domain lands in the inbox, and an unauthenticated one is more likely to be filtered, delayed, or quietly dropped, regardless of volume. If your quotes and invoices keep ending up in spam, weak or missing authentication is one of the first things to check. This is the deliverability half of the payoff, and it is the half owners feel immediately.

The security half: this is how invoice and wire fraud start

Deliverability is the reason owners call. Security is the reason this matters more than they realize. Business email compromise — the FBI's costliest category of cybercrime year after year — very often begins with a spoofed email that shows a real, trusted domain in the From line.

The script is familiar on the Central Coast: a property management office gets an email that appears to come from a vendor's exact address, with new banking details "for this month's payment." A law firm's bookkeeper gets a message that looks like it is from the managing partner, asking to push a wire before end of day. A grower's accounts-payable clerk receives an invoice that perfectly mimics a regular supplier. When the From address is genuinely forged to show the real domain, even careful people get fooled, because the one thing they were taught to check looks correct.

A DMARC policy set to reject is what breaks that specific attack. When a criminal forges your exact domain, the receiving server checks your DMARC policy, sees that the forged mail fails authentication, and throws it away before your client ever sees it. That is protection you extend to everyone you do business with, not just to your own inbox. It pairs directly with the human-side defenses in our impersonation and help-desk fraud post and the broader controls in how ransomware gets in.

The honest limits: what DMARC does not stop

Good advice includes the boundaries. DMARC at reject is powerful against one attack and useless against several others, and pretending otherwise sets you up for a nasty surprise.

• Lookalike domains. DMARC protects your domain. It does nothing about a criminal registering ghosxt-billing.com or ghoxst.com and sending from that. Those need lookalike-domain monitoring and trained eyes.
• Display-name spoofing. An email where the sender's name shows "Ulises Paiz" but the actual address is a throwaway Gmail account will sail right past DMARC, because the criminal never claimed your domain. This is why anti-phishing filtering and user awareness still matter.
• A genuinely compromised mailbox. If an attacker steals a real login and sends from the actual account, the mail is authentic by every measure. That is an identity problem, solved by multi-factor authentication and the controls in our identity hardening post and MFA fatigue post, not by DMARC.

Email authentication closes one specific, heavily abused door. It is necessary, not sufficient. It belongs in the stack alongside MFA, anti-phishing, backup, and training — the full set is in the 10 essentials.

"We're on Microsoft 365 / Google Workspace — aren't we covered?"

This is the most common and most dangerous assumption, because it is half true. Both platforms provide SPF and the ability to sign with DKIM. But there are two gaps that catch nearly everyone:

• DKIM for your own domain is often switched off. Out of the box, Microsoft 365 frequently signs with a generic Microsoft domain rather than yours until you explicitly enable DKIM for your custom domain. We audit tenants regularly and find this turned off more often than on. Turning it on is one of the nine items in our Microsoft 365 settings post.
• Nobody publishes your DMARC policy but you. Neither Microsoft nor Google creates the DMARC record that tells the world to reject forged mail. Without it, you have the two proofs available and no enforcement, which is like installing locks and leaving the door propped open.

There is also the part that lives entirely outside the platform: every other service that sends mail as your domain. The email marketing tool, the invoicing or accounting platform, the CRM, the appointment reminders, the e-signature service. Each one has to be authorized in your SPF and DKIM, or its mail will fail once you enforce. Finding all of them is the real work, and it is exactly what the monitoring phase below is for.

The safe rollout: monitor, fix, then enforce

The single way to get hurt here is to publish a DMARC record set to reject on day one and discover the next morning that the invoicing platform's mail is now bouncing. We never do that. The correct sequence is deliberate and mostly passive:

• 1. Inventory your senders. List everything that sends email as your domain — the email platform plus every third-party app. This is the foundation; you cannot authorize what you have not found.
• 2. Get SPF and DKIM right. Publish an accurate SPF record covering every legitimate sender, and enable DKIM signing for your own domain on the mail platform.
• 3. Publish DMARC in monitor mode first. A DMARC policy of p=none changes nothing about delivery but starts sending you reports on every system using your domain. This is the listening period, and it is where the forgotten senders surface.
• 4. Read the reports and close the gaps. Over a few weeks, confirm from the reports that all your real mail passes and authorize anything that was missed. This is the step most do-it-yourself attempts skip, and skipping it is what breaks mail later.
• 5. Tighten to quarantine, then reject. Once the reports show your legitimate mail is clean, step the policy up to p=quarantine (forged mail goes to spam) and finally p=reject (forged mail is refused). Now, and only now, are you actually protected.

Done in that order, enforcement blocks the spoofers and never touches your own email. The reason to use a managed process rather than a one-time DNS edit is that senders change — you add a new tool, a vendor changes platforms — and the DMARC reports are what keep the policy honest over time. We run this as part of managed IT, with the reports monitored rather than ignored.

The bonus payoff: your logo in the inbox

Once you reach an enforcing DMARC policy, an optional follow-on becomes available: BIMI (Brand Indicators for Message Identification), the standard that lets your verified logo appear next to your messages in supporting inboxes. It is a small thing, but it is a visible trust marker that only authenticated senders can earn, and customers notice it. It is not the reason to do this work, but it is a pleasant reward for finishing it, and you cannot get there without enforcement first.

How to check where you stand right now

You can get a rough read in a few minutes without any tools beyond a search engine, though a proper audit is more reliable:

• Do you have a DMARC record at all? Many small businesses have none. Plenty of the rest have one stuck at p=none, monitoring forever and protecting nothing.
• Is DKIM signing your own domain? Check whether DKIM is enabled for your custom domain in Microsoft 365 or Google Workspace, not just a default provider signature.
• Does your SPF cover every real sender? If your marketing or invoicing tool is missing from it, its mail is already at risk the moment you enforce.
• Is anyone actually reading the DMARC reports? An enforcing policy with nobody watching the reports drifts out of date the first time you add a new sending service.

If any of those answers is "I'm not sure," that uncertainty is the finding. This is precisely the kind of quiet gap a cybersecurity assessment is built to surface.

Where this fits

• The cybersecurity service page, for email authentication as one layer of a real defense.
• The Microsoft 365 settings post, which includes DKIM and anti-phishing among the nine settings to enable first.
• The impersonation and help-desk fraud post and how ransomware gets in, for the attacks authentication helps blunt.
• The identity hardening and MFA fatigue posts, for the account-takeover problem DMARC does not solve.
• The 10 essentials, for where this sits in the full priority order.
• The managed IT page, for keeping the policy and the reports current over time.

We set up and monitor email authentication for small businesses across Salinas, Monterey, Santa Cruz, Watsonville, and San Jose, and the rest of the Central Coast.

FAQs about SPF, DKIM, and DMARC

What is the difference between SPF, DKIM, and DMARC?

They are three layers that work together. SPF (Sender Policy Framework) is a list, published in your domain's DNS, of the mail servers allowed to send email for you; a receiving server checks whether the message came from one of them. DKIM (DomainKeys Identified Mail) adds a tamper-evident cryptographic signature to every outgoing message, which the receiver verifies against a public key in your DNS, proving the message really came from your domain and was not altered in transit. DMARC (Domain-based Message Authentication, Reporting and Conformance) ties the two together: it tells receiving servers what to do when a message claiming to be from your domain fails both checks, whether to allow it, send it to spam, or reject it outright, and it sends you reports about who is using your domain. SPF and DKIM prove legitimate mail is legitimate; DMARC is the policy and the enforcement that turns those proofs into protection against spoofing.

We're a small business, not a bulk sender. Do we still need email authentication?

Yes, and the reason is security, not volume. The new Google, Yahoo, and Microsoft rules that grabbed headlines apply to high-volume senders, but every business with a domain has the same exposure to spoofing regardless of how much mail it sends. Without DMARC set to enforce, a criminal can send an email that shows your exact domain in the From line, your real address, to your bookkeeper, your client, or your vendor, asking them to change wire instructions or pay a fake invoice. DMARC at an enforcing policy is what stops that. It is also increasingly a baseline that cyber-insurance applications and larger clients ask about. A five-person office needs this as much as a national retailer, just for a different reason.

Will turning on DMARC block our own legitimate email?

It can if you flip it to enforce on day one without preparation, which is exactly why we never do that. The safe rollout starts DMARC in monitor-only mode, which changes nothing about how your mail is delivered but begins collecting reports on every system sending under your domain. Most businesses are surprised to find legitimate senders they forgot about: an email marketing tool, the accounting or invoicing platform, a scheduling app, a CRM. You authorize each of those with SPF and DKIM, confirm from the reports that all your real mail now passes, and only then tighten the policy to quarantine and finally to reject. Done in that order, enforcement blocks the spoofers and never touches your own email.

Does DMARC stop all phishing and email spoofing?

No, and any vendor who says it does is overselling. DMARC at reject stops exact-domain spoofing, where the attacker forges your real domain. It does not stop lookalike domains, an address like ghosxt-billing.com or ghoxst.com that a human eye skips over, and it does not stop display-name spoofing, where the From shows your name but the actual address is a free Gmail account. It also does nothing about a genuinely compromised mailbox, where the criminal logs into a real account and sends from it. DMARC closes one specific and heavily abused door; phishing-resistant logins, multi-factor authentication, anti-phishing filtering, lookalike-domain monitoring, and trained staff close the others. It is a necessary layer, not the whole wall.

We use Microsoft 365 or Google Workspace. Isn't email authentication already handled?

Partly, and the gap is the dangerous part. Both platforms give you SPF and DKIM, though DKIM signing for your own domain often has to be switched on deliberately rather than working by default, and many tenants we audit have it turned off. Neither platform publishes a DMARC record for you, and DMARC is the layer that actually stops spoofing. So a typical out-of-the-box tenant has the proofs available but no enforcement policy telling the world to reject forged mail. You also have to account for every other service that sends as your domain, which lives outside the platform. The provider gives you the building blocks; turning them into protection is a configuration step that someone has to own.

How long does it take to set up SPF, DKIM, and DMARC?

The initial DNS records, SPF, DKIM, and DMARC in monitor mode, are usually a same-day job once we have access to your domain's DNS and a list of the services that send mail for you. The part that takes time is the monitoring window before enforcement: we typically watch the DMARC reports for a few weeks to make sure every legitimate sender is accounted for and passing, then step the policy from monitor to quarantine to reject. Rushing straight to reject is what breaks mail, so the deliberate pace is the point. For most small businesses the whole journey to a safe, enforcing policy is a few weeks of mostly-passive monitoring, not a few weeks of work.

Prefer to talk first? Email sales@ghosxt.com or call (831) 204-0501.