Skip to main content
Cybersecurity

DMARC for Small Business: From Monitor to Reject

DMARC for Small Business: From Monitor to Reject

Here’s the short version: DMARC for small business is a DNS policy you tighten in public, not a checkbox you set to reject on day one. SPF and DKIM have to work first. Then p=none, then quarantine, then reject. Skip the ladder and you will block your own invoices.

Spoofed mail that uses your domain is a solved class of problem if you finish this work. Lookalike domains and stolen mailboxes are a different class. This page is the first class: how a 10 to 80 person firm in Microsoft 365 gets from “we think we have SPF” to a reject policy they can defend.

Microsoft documents the Microsoft 365 path in Set up DMARC and the broader email authentication overview. The protocol itself is RFC 7489. You do not need to read the RFC to roll this out. You do need to know what “alignment” means.

If you want a generator for the records, use our SPF and DMARC generator. It will not replace watching reports for two weeks.

What DMARC actually does

DMARC tells receiving servers two things:

  1. How to check that the visible From domain matches SPF and/or DKIM (alignment).
  2. What to do when that check fails: nothing special (none), treat as spam (quarantine), or refuse (reject).

dmarc.org is the plain-language overview. The useful sentence: DMARC does not encrypt mail and does not prove the human is who they claim. It proves the domain in From was authorized to send that message, as far as DNS can tell.

That is enough to kill a large pile of “invoice attached” messages that pretend to be you. It is why cyber-insurance applications and client security questionnaires ask whether DMARC is at enforcement, not whether you “have email security.”

CISA’s BOD 18-01 pushed federal agencies to this years ago. You are not a federal agency. The attackers using your domain as a costume do not care.

SPF and DKIM have to exist first

DMARC without SPF and DKIM is a policy about nothing.

SPF lists which servers may send for the domain. Microsoft’s SPF setup is the Microsoft 365 version. The failure mode is a 12-include record that exceeds the lookup limit, or a marketing tool that sends as you with no include at all.

DKIM signs the message so the receiving server can verify it was not altered and that the signing domain is yours. Microsoft’s DKIM setup is two CNAME records per domain. The failure mode is enabling DKIM in the admin center and never publishing the CNAMEs.

Alignment is the extra DMARC rule: the domain that passed SPF or DKIM has to match the From domain closely enough. A newsletter that passes SPF as send.vendor.com while From is yourfirm.com can fail DMARC even though SPF “worked.” That is the report you are looking for in week one.

Person working on a laptop in a bright office
Publish SPF and DKIM before you move DMARC off p=none

The policy ladder

PolicyWhat receivers do on failWhen to use it
p=noneDeliver anyway, send you reportsFirst two weeks, or until every real sender is identified
p=quarantineTreat as spamWhen reports show your real mail passing and junk failing
p=rejectRefuse the messageWhen you can name every sender and they align

pct= can roll quarantine or reject out at 10 percent, then 50, then 100. Small firms with one tenant often skip pct and just watch reports longer. Either is fine. What is not fine is p=none for three years.

rua= is the mailbox that receives aggregate XML reports. Use a mailbox you will actually look at, or a parser. Do not set rua to a shared inbox nobody opens.

ruf= forensic reports are optional and often noisy. Start without them.

How to read reports without drowning

Aggregate reports are XML. You will not read them as email. Use a parser, a Microsoft report if you have it, or a weekly export into a spreadsheet with three columns: source IP / service, pass or fail, volume.

You are hunting:

  • Microsoft 365 sending as you (should pass).
  • A billing platform, scanner, or marketing tool sending as you (must be added to SPF and/or DKIM, or stop using your From domain).
  • Random botnets (should fail; that is the point).
  • A second Microsoft tenant or an old host still sending (retire or include it on purpose).

If a real tool fails, fix the tool before you raise the policy. If a random network fails, that is DMARC working. Do not add random networks to SPF.

A passing week is not “zero fail volume.” Fail volume from random networks should stay. You are done with the inventory when every high-volume passing or failing source you recognize has a name and an owner. Mystery volume that is clearly not you can wait for reject.

Keep a one-page sender list next to the DNS records: Microsoft 365, billing, marketing, scanner. When someone buys a new tool that sends as the firm, the list is how you notice before reports explode. DMARC is a living record, not a 2019 TXT you never opened again.

Microsoft 365 specifics

For a default Microsoft 365 domain you still publish DMARC on the domain customers see, which is often a custom domain, not onmicrosoft.com. Set DKIM for that custom domain. Keep SPF to Microsoft plus the few includes you can name.

Connectors and scanners that “send as” users are the usual surprise. So are postage-stamp marketing tools bought by someone in the office who never told IT. The report will name them. The report is the inventory.

When you are ready to raise the policy, follow Microsoft’s DMARC article for the TXT record. Then send a test from Outlook, from any remaining third-party, and from a spoofed From (a friend with a Gmail) and confirm the spoof is quarantined or rejected.

Laptops and documents on a conference table
Watch DMARC reports for two weeks before you enforce reject

What DMARC will not stop

Write this next to the insurance questionnaire so nobody claims a miracle.

  • Lookalike domains. yourfirn.com is not your domain. DMARC on your domain does not cover it. Registration monitoring and user awareness still matter. See phishing and email security.
  • Stolen mailboxes. If an attacker signs in as you, SPF, DKIM, and DMARC all pass. That is why MFA and business email compromise controls sit next to DMARC, not behind it.
  • Vendors spoofing themselves. If the fake invoice is from a vendor’s domain, their DMARC is the question, not yours. Vendor risk is that conversation.
  • Internal forwarding quirks. Some forwarders break DKIM. Fix forwarding rather than weakening DMARC.

The wire-fraud close call is a reminder: authentication plus a phone call is the pair. DMARC alone does not move money back.

A 30-day rollout

Days 1 to 3: publish the floor

SPF for Microsoft 365 plus known includes. DKIM CNAMEs. DMARC at p=none with an rua address you own. Use the SPF and DMARC generator if you want a first draft, then verify in DNS.

Days 4 to 18: read reports twice a week

Name every passing sender. Fix or remove failing real senders. Ignore botnet volume except as proof the policy will have work to do.

Days 19 to 24: quarantine

Set p=quarantine. Tell the office to watch junk for a few days. Help desk should know this is coming. See managed help desk.

Days 25 to 30: reject, if the junk stays junk

Set p=reject. Send the same three tests. If a real campaign breaks, roll to quarantine, fix the sender, return to reject. Do not stay at none because one tool is messy. Fix the tool.

Common ways small firms stall

SPF lookup limit. Too many includes. Flatten or drop dead vendors.

Someone’s scanner. It sends as users and fails alignment. Give it a subdomain or a connector that aligns, or stop using it as a From identity.

Marketing bought last year. It still sends as the CEO. Add DKIM for that platform or stop.

Fear of reject. Quarantine is the rehearsal. Reject is the control. Insurance and client questionnaires are asking for the control.

Treating onmicrosoft.com as the public domain. Customers reply to the custom domain. Authenticate that one.

Multiple domains. The website domain, the mail domain, and a leftover domain from a merger all need a story. Authenticate what you send as. Publish a reject policy on domains you do not send as, so they cannot be used as costumes. That last step is cheap and often skipped.

Cybersecurity for a Microsoft 365 tenant without DMARC at enforcement is a program with a hole in the From line. If you want the records published and the reports watched as a project, contact Secure Techies. We work from Canoga Park. We will tell you which senders are real, which are costume, and when reject is safe.

Frequently Asked Questions

DMARC is a DNS policy that tells receiving mail servers what to do when a message claims to be from your domain but fails SPF or DKIM alignment. For a small business it is the control that turns spoofed invoices and fake executive mail into quarantine or reject, after you have SPF and DKIM working.
Yes. DMARC evaluates whether the visible From domain aligns with SPF and/or DKIM. If those records are missing or wrong, a DMARC reject policy will block legitimate mail from your own tools. Publish SPF and DKIM first, then DMARC at p=none, then tighten.
Start at p=none so you get reports without blocking. Move to p=quarantine when the report shows your real senders passing. Move to p=reject when marketing tools, scanners, and Microsoft 365 all align. Staying on none forever is a monitor that never becomes a control.
No. DMARC stops a class of direct-domain spoofing. It does not stop lookalike domains, stolen mailboxes, or a vendor whose domain is not yours. Pair it with MFA, filtering, and a call-back habit for money language.
A careful small-business rollout is usually two to four weeks of reporting, then quarantine, then reject. The calendar depends on how many third-party senders you have (billing, marketing, scanners). Firms with one Microsoft 365 tenant and no extra senders can move faster.
Share

Related Articles

Keep reading — more guides you might find useful.

Talk to a real IT expert — free

No sales pressure, no jargon. Just a straight assessment of where your IT and security stand, and what to do next.