Before You Enforce DMARC, Find Everything That Sends as Your Business
The invoice goes out on a Tuesday from the accounting platform, signed with your own domain, and lands exactly where it should. On a Wednesday, the same domain, one new DNS record later, starts rejecting the invoices. There was no attacker in the room. The change was made by the business, to itself.
Your domain sends from more places than you think
The visible From address is the most overused resource in a small business. The staff mailbox sends it. The invoicing tool sends it. The newsletter, the ecommerce platform's order emails, the CRM's notifications, and the website contact form all send it too, each from a different company's servers, each with its own authentication, all wearing the same name. When a receiver checks that name, it is not checking one sender. It is checking a fleet.
DMARC is the record that tells receivers what to do when the fleet misbehaves, and "enforce" is the setting that tells them to reject it. So enforcement is a decision about every sender in the fleet at once, including the ones nobody remembers. The big receivers, Gmail among them, now require senders to authenticate at volume, which is why the pressure to enforce has arrived. The requirement is reasonable. The danger is the inventory: most businesses do not know the full list of the fleet before they switch the setting that judges all of it.
One From address. Six senders. Only one of them is the mailbox.
Alignment in thirty seconds
Three checks run on every authenticated message, and DMARC cares about the third, which is the one that surprises people.
SPF passes when the sending server is on a list the domain published. DKIM passes when the domain's private key signs the message and the receiver verifies it. Both are about who physically sent the mail. Alignment is the extra step: the domain that authenticated, in either check, has to match the domain the human sees in the From field, under the matching rules the policy sets. A message can pass SPF and DKIM and still fail DMARC, because it authenticated as a different domain than the one it signed. That is the gap between "it passed" and "it is aligned," and it is where a well-meaning record breaks a well-behaved invoice.
This post will not hand you a DNS record to paste. A DMARC record is a policy about your specific fleet, and the current standard, RFC 9989, published in May 2026 and superseding RFC 7489, along with the aggregate reporting standard, RFC 9990, defines the mechanics. What the record should say is answered by the inventory, not by a template.
The sender inventory
One sheet, one row per sending tool, and the columns are the questions the fleet cannot answer by guessing.
| Tool | Who owns it | Visible From | Authenticates as | Test message, last week |
|---|---|---|---|---|
| Staff mailbox | ||||
| Invoicing | ||||
| Newsletter | ||||
| Ecommerce order emails | ||||
| CRM notifications | ||||
| Website contact form | ||||
| The integration nobody remembers |
The last row is the one that saves the rollout. Every business has at least one: the booking plugin, the old review-request service, the abandoned marketing tool that still has a webhook. The inventory is built by sending one real, labeled test message from each tool to a mailbox you control and reading the headers, which is where the authenticated domains live. The column that matters most is the second-to-last: a tool that authenticates as something other than the From domain is the tool enforcement will break, and it is invisible until you look.
What the reports can, and cannot, tell you
Once a policy is in place, even in observe-only mode, the big receivers mail back aggregate reports: who sent as your domain, from where, and whether the checks passed. They are genuinely useful and genuinely incomplete, and the difference is the part to design around.
Reports show what participating receivers saw. A sender that only emails a small circle of customers at providers who do not report will produce zero reports, which reads as "no problem" and means "no evidence." The reports are a fire alarm for the loud fires. They cannot prove the inventory is complete, and forwarding and intermediaries complicate the picture further, because a message that passed your checks can be forwarded by an intermediary in a way that changes how the final receiver sees the alignment. Treat a week of clean reports as "we saw no problems among the receivers who talk," not as a certificate of completeness. The inventory, built by testing each tool, is the certificate. The reports are the watch you keep on afterward.
Clean reports mean the loud senders behaved. They do not mean the list is finished.
A rollout with exits
Enforcement is a stage, not a switch, and each stage has a review owner and an off-ramp.
Stage one is observe only: the policy is published with a setting that reports but does not reject, for long enough that every sender in the fleet gets a chance to show up. The named review owner reads the reports on a set cadence. Stage two is fixing: each flagged sender is corrected with its own provider's current documentation, DKIM where the tool supports it, SPF lists trimmed to the senders that exist, and the inventory updated as tools are added or retired. Stage three is enforcement, introduced gradually rather than all at once, so that the one missed sender breaks a fraction of mail on a Tuesday instead of all of it on a Monday. Stage four is monitoring after enforcement, because the fleet keeps changing: a new invoicing tool is a new sender, and the inventory is a living document or it is a photograph.
Two things this plan does not promise. Enforcement will not stop all phishing: lookalike domains and social engineering do not live in your DNS, and no record fixes a customer who trusts a text. And enforcement does not guarantee inbox placement: it removes one failure mode, the unauthenticated one, and the rest of deliverability is still the long game covered in why business email goes to spam.
The DMARC story gets told as a security upgrade, and it is, but the version that breaks businesses is an operations story. A policy that judges a fleet no one has inventoried will always out-execute the people who run it. Find the senders, watch the reports, fix what shows up, and only then raise the setting, gradually, with a named owner and an off-ramp. The phishers get less room. The invoices keep landing. Both of those are true only in that order.
DMARC questions
Does a passing SPF record satisfy DMARC?
Only if it is aligned. SPF passing means the server is on the list; DMARC asks the further question of whether the authenticated domain matches the visible From domain. A message can pass SPF, fail alignment, and be rejected under enforcement, which is why the test is the From field, not the checkbox.
What do the aggregate reports tell me?
What the receivers who participate actually saw: the sender, the source, and the check results. That is real evidence about the loud senders and no evidence at all about the quiet ones. Use the reports to find problems, and the inventory to know you have found them all.
Can a website contact form be affected?
Yes, it is a sender like any other, and it is the one most often left off the inventory because it is not a "mail product." If the form sends from your domain through some service, that service is a row in the table and a thing enforcement will judge.
Does enforcement block lookalike domains?
No. DMARC protects your domain: mail claiming to be from it, authenticated or not. It says nothing about a different domain that is merely similar, which is a registration and search problem, not a DNS one. Enforcement closes one door and the phishers work on the others, so it earns its keep as a layer, not a wall.
More from the blog
- Why Your Business Email Goes to Spam, the wider diagnosis this is one part of
- Your New Website Is Live. Why Did Your Business Email Stop?, the other moment the records betray you
- You Moved the Mailboxes. Did You Move the Business?, because a migration is a new fleet too
All posts are on the blog. For the step by step versions, see the domain and hosting guides.
Planning to enforce?
Send us the domain and the tools you know about, and we will build the inventory with you: one test message per sender, the headers read, the gaps named. You will know, before the first policy goes live, exactly what it will judge.