# What Is DMARC? SPF, DKIM, and DMARC Explained for Small Firms URL: https://limehawk.io/reports/what-is-dmarc Published: 2026-10-02 Author: Corey Watson, Managing Member Topic: Guides Read time: 6 min DMARC is a DNS record that tells receiving mail servers what to do with mail that fails SPF and DKIM checks for your domain, and sends you reports on it. > **TL;DR** DMARC is a DNS record that tells the rest of the internet what to do with email that claims to be from your domain but can't prove it. SPF and DKIM are the two checks. DMARC is the policy on top: p=none (watch only), p=quarantine (send it to spam), or p=reject (refuse it). It also sends you reports on who's mailing as you. Google and Yahoo require bulk senders to publish at least p=none. Most small firms publish p=none and stop there, which means a forged email from their domain still gets delivered. DMARC also won't stop a look-alike domain or a criminal sending from your real, compromised inbox. That's the BEC case, and it takes other controls. - Gmail bulk-sender line: 5,000 a day ## 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](https://www.rfc-editor.org/rfc/rfc7489.html), 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](https://dmarc.org/overview/) 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](https://www.rfc-editor.org/rfc/rfc7489.html): - **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](https://www.cisa.gov/news-events/directives/bod-18-01-enhance-email-and-web-security), 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](https://support.google.com/a/answer/81126) 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](https://support.google.com/a/answer/14229414) 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](https://senders.yahooinc.com/best-practices/) 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](/reports/bec-wire-fraud-incident-response), 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](/reports/front-app-gmail-spam-sender-whitelist), where the classification happened in Gmail underneath the app. And unexpected verification codes in your inbox, like the ones in [our OTP spam triage](/reports/email-address-enumeration-otp-spam), 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 - SPF and DKIM are the two checks. DMARC is the policy that says what to do when both fail, plus the reports that show who's sending as you. - p=none only watches. A forged email from your domain still lands. The protection starts at p=quarantine and is complete at p=reject. - Google and Yahoo require bulk senders to publish DMARC at p=none or stronger. That's the floor, not the goal. - DMARC doesn't stop look-alike domains or a criminal sending from your real, compromised inbox. Enforced MFA and a phone call before any wire change cover those. - Getting from p=none to p=reject is mostly inventory work: find every service that sends as you, fix its SPF or DKIM, then tighten. ## 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](/services/cloud-solutions), not a separate project. For [title companies](/industries/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.