DMARC connects SPF or DKIM authentication to the domain customers see in the From address. It helps organizations identify legitimate sending sources, correct alignment problems, establish an enforcement policy and gain reporting visibility across their email environment. This work comes before BIMI because participating mailbox providers expect aligned authentication and an enforcement-level DMARC policy. Organizations should inventory every sending domain and third-party platform, resolve authentication gaps and assign ongoing ownership before progressing to a VMC or CMC deployment.
DMARC gets described in two very different ways: a defensive control against spoofing, and “the thing you need before BIMI.” Both are true, but neither on its own explains what DMARC actually does. This guide covers the mechanics in business-readable terms — what DMARC evaluates, why p=none isn’t enforcement, what its reports can and can’t tell you, and why authentication work has to come before a logo certificate.
DMARC—Domain-based Message Authentication, Reporting and Conformance—is an email authentication policy and reporting protocol. It allows receiving systems to determine whether a passing SPF or DKIM result aligns with the domain visible in the From field, then consider the domain owner’s published policy when handling messages that fail alignment. It also provides reporting visibility into observed sending activity.
Why DMARC Exists
SPF and DKIM results are not automatically connected to the domain a recipient sees in the From field. A third-party sender may use a different envelope domain for SPF or a different signing domain for DKIM, so a message can pass authentication without aligning to the visible brand domain. DMARC addresses this gap by evaluating alignment, publishing the domain owner’s handling policy and providing reporting visibility into observed sending activity.
The Four Questions in a DMARC Evaluation
DMARC’s evaluation reduces to four questions, answered in sequence for every message:
The evaluation sequence
- Did SPF pass?
- Did DKIM pass?
- Did at least one passing result align with the visible From domain?
- What policy and reporting instructions has the domain owner published?
DMARC passes when at least one aligned authentication path passes — not both, and not by default.
| Decision | Question | Why it matters | What it confirms |
|---|---|---|---|
| 1. SPF result | Did SPF pass for the envelope domain? | Checks whether the sending server is authorized by the envelope domain | Provides one possible authentication path |
| 2. DKIM result | Did DKIM pass for the signing domain? | Verifies the signature and protected message portions | Provides one possible authentication path |
| 3. Alignment | Did a passing result align with the visible From domain? | Connects authentication to the domain the recipient sees | Determines whether SPF or DKIM can satisfy DMARC |
| 4. Policy and reporting | What policy and reporting instructions were published? | Communicates the domain owner’s requested handling | Provides enforcement direction and reporting visibility |
How SPF, DKIM and DMARC Fit Together
| Component | Main role | Identifier involved | How it contributes to DMARC |
|---|---|---|---|
| SPF | Authorizes sending infrastructure | Envelope domain | Can provide an aligned authentication path |
| DKIM | Signs selected message content and headers | Signing domain | Can provide an aligned authentication path |
| DMARC | Evaluates alignment and publishes policy | Visible From domain | Connects authentication to the recipient-visible identity |
SPF and DKIM each produce an independent authentication result — SPF for the envelope domain, DKIM for the signing domain. DMARC evaluates whether at least one of those passing results aligns with the visible From domain; it doesn’t require both to pass or align, only one. Based on that outcome, participating receiving systems apply the domain owner’s published policy and, where configured, send back reports describing what they observed. DMARC is the alignment and policy layer sitting on top of SPF and DKIM, not a replacement for either.
What Does DMARC Alignment Mean?
Alignment connects an authentication result to the domain a recipient actually sees. Take a message with a visible From address of billing@example.com, sent through a third-party platform using an SPF envelope domain of mailer.example.com, but DKIM-signed with example.com. SPF alone doesn’t align here, but the DKIM result does, because the signing domain matches the visible From domain — exactly, under strict alignment, or as a valid subdomain relationship, under relaxed alignment. DMARC passes because at least one aligned path passed, even though SPF didn’t align on its own. Exact alignment-mode configuration is covered in the DMARC readiness knowledge base rather than here.
The Three Policy Stages
The published policy tells receiving systems how the domain owner wants failing mail handled; final treatment remains subject to receiver policy.
| Policy | Main purpose | What it asks receivers to do | Typical use |
|---|---|---|---|
p=none | Monitoring | Collect and report, without requesting quarantine or rejection | Discovery and remediation |
p=quarantine | Enforcement with suspicious handling requested | Treat failing mail as suspicious | Controlled enforcement progression |
p=reject | Strongest published enforcement request | Reject failing messages | Final enforcement state where appropriate |
No. p=none is a monitoring policy. BIMI guidance requires DMARC enforcement—normally p=quarantine or p=reject—with full policy application on the organizational domain and relevant subdomains. Before moving to enforcement, organizations should identify legitimate senders and resolve authentication or alignment failures.
What DMARC Reports Show
Aggregate reports help organizations map sending services, compare SPF and DKIM outcomes, identify alignment failures, review message volume and distinguish expected sources from activity requiring investigation. They become most useful when combined with an accurate sender inventory and clear business ownership.
| Reporting insight | Action it supports |
|---|---|
| Observed source IPs and sending services | Match traffic to approved platforms |
| SPF and DKIM outcomes | Identify configuration failures |
| Alignment patterns | Correct domain relationships |
| Message volumes | Prioritize high-impact sources |
| Requested and applied disposition | Review enforcement behavior |
For organizations that want interpretation rather than parsing raw XML themselves, expert DMARC implementation and enforcement support can help translate reports into a decision.
Where DMARC Provides the Most Value
| DMARC capability | Practical value |
|---|---|
| SPF or DKIM alignment with the visible From domain | Connects authentication to the identity recipients see |
| Enforcement policy | Requests stronger handling of unauthenticated mail |
| Aggregate reporting | Reveals observed senders and authentication patterns |
| Domain-level protection | Reduces unauthorized direct use of the protected From domain |
Other impersonation methods, including lookalike domains and compromised accounts, require additional security and monitoring controls.
Why DMARC Comes Before BIMI
BIMI depends on a properly authenticated and governed email environment. Before pursuing a VMC or CMC, organizations should identify all sending sources, align SPF or DKIM with the visible From domain and move DMARC to an enforcement-level policy. The logo, certificate and BIMI DNS record are then added to that established foundation.
| Layer | Target state |
|---|---|
| Sending sources | Documented and assigned to owners |
| SPF and DKIM | Passing and aligned where appropriate |
| DMARC | Enforcement-level policy |
| Logo | BIMI-compatible SVG prepared |
| Certificate route | VMC or CMC eligibility confirmed |
| BIMI deployment | DNS and hosted assets prepared |
BIMI depends on a mailbox provider being able to trust that authenticated mail actually comes from the domain it claims to. That trust comes from DMARC operating at an enforcement level — not simply present, and not still in monitoring mode. A logo, and where required a VMC or CMC certificate, sits on top of that authenticated foundation; neither replaces it, and neither can compensate for a domain that hasn’t reached enforcement. Providers can also change requirements, and a certificate doesn’t by itself guarantee display.
A Real Deployment Lesson: Root and Subdomain Sending
Authentication readiness usually looks simpler on paper than it is in practice. In one documented case, a regulated-industry sender had a VMC issued and a BIMI record published on its root domain, but also sent marketing and transactional mail from a subdomain — and assumed the root record would cover it. It didn’t: mailbox providers evaluate the BIMI record for the exact domain in the From address, so the subdomain needed its own record and its own confirmed DMARC enforcement before the logo displayed there too. See the full root and subdomain sender configuration scenario — a reminder that domain inventory has to reflect every sending identity in actual use, not just the primary one.
A related pattern shows up after go-live rather than before it: a domain with an issued certificate and a published BIMI record where the logo still didn’t display, traced to a DNS selector and hosting misconfiguration rather than anything wrong with the certificate itself. See the DNS selector and hosting correction scenario for how that gets diagnosed.
A professional DMARC service may be useful when the organization has several domains, subdomains or third-party senders; cannot confidently interpret aggregate reports; needs to move from monitoring to enforcement without disrupting legitimate mail; or wants DMARC readiness coordinated with BIMI, VMC or CMC. The service should help identify and align authorized senders, interpret reporting data and manage policy progression — not simply publish a generic DNS record.
Readiness Checklist Before Progressing
What to have mapped before moving toward enforcement
- Domains, subdomains and visible From identities
- Marketing, transactional, support and billing platforms
- SPF, DKIM and alignment status for each sender
- DMARC reporting coverage and enforcement policy
- Organizational and subdomain-policy requirements
- Owners for DNS, reporting, enforcement and BIMI progression
This is a readiness map, not a full technical audit — review your sender inventory and enforcement readiness with a specialist if any of it is unclear.
Common DMARC Readiness Gaps
Patterns worth avoiding
- Incomplete sender inventory
- SPF or DKIM passing without alignment
- Overlooked subdomains
- Enforcement before legitimate senders are prepared
- Reports collected without interpretation or ownership
- Certificate planning before DMARC readiness
Not sure where your domain stands?
Start with a quick record check before deciding what to fix first.
