What Is DMARC? SPF, DKIM, and DMARC Explained for Small Firms

What is DMARC?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a text record you publish in your domain’s DNS. It tells receiving mail servers what to do when a message claims to be from your domain but fails authentication, and where to send reports about it. It’s defined in RFC 7489, published in March 2015.

The point is simple. Anyone can type your domain into the From line of an email. Without DMARC, the receiving server has no instruction from you about what to do when that message doesn’t check out. With DMARC at enforcement, a forged email from yourfirm.com gets sent to spam or bounced before your client ever sees it.

How do SPF, DKIM, and DMARC work together?

SPF and DKIM are the two checks. DMARC is the rulebook that reads both results and decides. As dmarc.org puts it, DMARC “builds upon both” of them. You need all three, and they each do a different job.

• SPF (Sender Policy Framework) is a DNS list of the servers allowed to send mail for your domain. Microsoft 365, Google Workspace, your billing system, your closing software. If a message comes from a server not on the list, SPF fails.
• DKIM (DomainKeys Identified Mail) is a digital signature. The sending server signs each message with a private key, and you publish the matching public key in DNS. If the signature checks out, the message wasn’t altered and really came through a system that holds your key.
• DMARC adds the part SPF and DKIM skip: does the domain that passed actually match the domain in the From line the reader sees? RFC 7489 calls this “identifier alignment.” A message passes DMARC if at least one of SPF or DKIM passes and lines up with the From domain.

That alignment check matters. Without it, a scammer can pass SPF on their own throwaway domain while showing your name in the From line. DMARC closes that gap.

What's the difference between p=none, p=quarantine, and p=reject?

The p= tag is your policy, and it’s the whole ballgame. Per RFC 7489:

• p=none: “no specific action.” Failing mail is delivered as usual. You just get reports.
• p=quarantine: failing mail should be “treated as suspicious.” In practice, it goes to spam or junk.
• p=reject: receivers should “reject email that fails the DMARC mechanism check.” It never reaches the inbox.

There’s also a pct= tag that applies the policy to a percentage of failing mail, so you can step up gradually. And the rua= tag tells receivers where to send aggregate reports. Those reports are how you find out that your payroll provider, your e-signature tool, or a scammer in another country is sending mail as you.

p=none is a starting point for collecting data. It protects nobody. A spoofed email from a p=none domain lands right in the inbox.

Why do most small firms get stuck at p=none?

They’re afraid of blocking their own mail, and that fear is reasonable. A small law firm or title company sends as its domain from more places than anyone remembers: the mailbox platform, the website contact form, accounting software sending invoices, the closing or practice management platform, a marketing tool, a scanner that emails PDFs. If any of those isn’t covered by SPF or signed with DKIM, moving to p=reject bounces real client mail.

So somebody publishes p=none to check a box, points the reports at an inbox nobody reads, and never comes back. The record exists. The protection doesn’t.

Getting to enforcement is inventory work, not magic:

1. Publish p=none with a rua= address someone (or some tool) actually reads.
2. Use the reports to list every service sending as your domain.
3. Fix each one: add it to SPF, turn on DKIM signing, or move it to a subdomain.
4. Move to p=quarantine, watch for legitimate failures, then move to p=reject.

The federal government did exactly this. CISA’s Binding Operational Directive 18-01, issued October 16, 2017, gave agencies 90 days to publish at least p=none with a report address, and one year to get to “reject.” If federal agencies can be told to reach reject in a year, a 20-person firm can get there too.

What are the Google and Yahoo sender requirements?

Since February 1, 2024, Google’s sender guidelines require every sender to Gmail personal accounts to set up SPF or DKIM. Bulk senders, those sending more than 5,000 a day to Gmail accounts, need SPF and DKIM both, a DMARC record (p=none is allowed), From-domain alignment, and one-click unsubscribe on marketing mail. Google’s FAQ says that “starting November 2025,” non-compliant mail sees “temporary and permanent rejections,” and that bulk sender status, once assigned, doesn’t expire.

Yahoo’s requirements match closely: SPF or DKIM for everyone, and for bulk senders both SPF and DKIM plus “a valid DMARC policy with at least p=none” that passes.

Most professional firms aren’t bulk senders. But if you send newsletters or client announcements from your main domain, you might be. And notice what both companies set as the minimum: p=none. That gets your mail delivered. It doesn’t protect your clients from someone forging you.

What doesn't DMARC stop?

DMARC protects your exact domain and nothing else. RFC 7489 says so plainly: it “does not address the use of visually similar domain names (‘cousin domains’).” If a scammer registers yourfirm-title.com or swaps an l for a 1, that domain can pass its own SPF, DKIM, and DMARC perfectly. Your record has nothing to say about it.

DMARC also can’t help when the email really is from you. In our BEC wire fraud incident report, the attacker logged into a title closer’s actual inbox and sent wire instructions from it. Every authentication check passed, because it was the real account on the real servers. What stopped the loss was a phone call to the other side of the deal, and what closed the hole was enforcing the second sign-in step across the whole tenant.

The same goes for the reverse problem. Sometimes legitimate mail gets flagged and nobody knows which layer made the call. We sorted out one of those in Front sending a bank’s wire confirmations to spam, where the classification happened in Gmail underneath the app. And unexpected verification codes in your inbox, like the ones in our OTP spam triage, are someone typing your address into a form. DMARC has nothing to do with those either.

So DMARC is one layer. For a firm that moves money or privileged documents by email, it sits next to enforced MFA, mailbox rule monitoring, and a verification call before any wire change.

Key takeaways

What this looks like when we do it

When we take on a firm, we read the DNS before we touch anything else: what SPF says, whether DKIM is actually signing, and what the DMARC policy is (or whether there is one). Then we use the reports to build the list of every service sending as the domain, fix each one, and move the policy toward reject. That’s part of the email hardening we do under Microsoft 365 and Google Workspace administration, not a separate project.

For title companies, DMARC, SPF, and DKIM are part of the baseline, along with tenant-wide MFA and monitoring for the mailbox rules attackers leave behind. DMARC keeps a stranger from forging your domain. The rest keeps a stranger from using your real one.

Not sure what your domain’s DMARC record says right now? Book a call and we’ll look at it with you.