Definition
DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS-published policy that builds on SPF and DKIM. It does two things. First, it tells receiving servers what to do with messages claiming to be from your domain that fail authentication: ignore, quarantine, or reject. Second, it asks receivers to send back aggregate reports so you can see who is sending mail using your domain and whether the authentication checks are passing.
How DMARC actually works
A DMARC record sits at _dmarc.{your-domain} as a TXT record. Something like v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100. The components in plain English: p= is the policy (none, quarantine, or reject). rua= is where aggregate reports should be sent. pct= is the percentage of failing mail the policy applies to (useful for gradual rollout).
When a receiving server gets a message claiming to be from your domain, it runs SPF and DKIM checks first. Then it asks a different question: does the result align with the visible From header the user sees? Alignment is the crucial concept. SPF can pass for some intermediate domain, but if it does not align with your visible From, DMARC treats it as a failure. Same for DKIM. You need at least one of the two to align for DMARC to consider the message authenticated.
If both fail alignment, the receiving server looks at your policy and acts. p=none means "do nothing, just report this to me." p=quarantine means "send to spam." p=reject means "drop the message entirely, do not deliver."
The DMARC rollout path that actually works
Most teams who get DMARC wrong make the same mistake: they go straight to p=reject without verifying their authentication is clean first. Then half their legitimate marketing or transactional mail starts getting rejected because some forgotten subprocessor's SPF was misconfigured. The fix is a phased rollout.
Phase one: publish p=none with reporting addresses. This does nothing policy-wise. It just asks receivers to send you reports. Run this for two to four weeks, parse the reports (services like Postmark DMARC Digests, Dmarcian, EasyDMARC handle parsing for free at low volume), and identify every legitimate sender using your domain. If something is failing alignment, fix it before moving on.
Phase two: move to p=quarantine with pct=10. Now 10% of failing mail goes to spam. Watch reports for another two weeks. If your legitimate volume is unaffected, raise pct to 25, then 50, then 100. Each step gives you a chance to catch a misconfiguration before it affects all your mail.
Phase three: move to p=reject at pct=100. This is the goal state. Failing mail is dropped entirely. Phishers cannot impersonate your domain successfully. You stay here permanently with reporting on. Typical end-to-end timeline: 2-4 months for a careful rollout.
Why DMARC matters in 2026
Three things changed the DMARC landscape between 2023 and 2026. First, Gmail and Yahoo's 2024 enforcement now requires bulk senders (over 5,000 messages/day) to publish at least p=none. The minimum bar is no longer "no DMARC at all." Second, the Mail Privacy Protection era means engagement signals are noisier, so authentication-based reputation matters more than it used to. Third, BIMI (Brand Indicators for Message Identification — showing your logo in the inbox) requires p=quarantine or p=reject, so domains chasing BIMI badges have to complete the DMARC journey first.
The practical implication: p=none is now the floor, not the ceiling. If your domain still has no DMARC record at all, you are sending a deliverability-reducing signal to every major inbox provider. The work to get to p=none is one DNS record. The work to get to p=reject is a few months of phased rollout but pays back continuously in reputation and impersonation protection.
Common DMARC mistakes
Going to p=reject on day one. Already covered. Don't.
Forgetting the reporting address. Without rua=, you have no visibility into who is sending using your domain or whether things are passing. The reports are not optional — they are the diagnostic loop.
Not understanding alignment. Teams set up SPF and DKIM correctly, then DMARC fails because the envelope From is on a different subdomain from the visible From. The fix is usually setting up DKIM signing with the visible-From domain's key, not the envelope domain's. Alignment is subtle and worth reading the RFC paragraphs on.
Treating DMARC reports as garbage. The reports are dense XML, often ignored. They contain the actual answer to "who is impersonating us" and "which legitimate senders are failing alignment". Use a parsing service so you actually read them.
Related reading
- SPF — DMARC sits on top of SPF. Need to understand it first.
- DKIM — same. DMARC checks alignment of SPF or DKIM with the visible From.
- Email Deliverability — broader context where DMARC sits as the policy layer.
- Run a free deliverability check — verifies your DMARC alongside SPF and DKIM.