DMARC in 2026: how it fights phishing—and where it stops

A practical guide to domain alignment, reporting, safe enforcement, and the phishing attacks DMARC cannot solve on its own.

A phishing message can put your company’s domain in the visible From address even when the attacker has never touched your mail system. To a recipient scanning a crowded inbox, that familiar domain can be enough to make a fake password reset, invoice, or executive request feel legitimate.

DMARC gives the owner of that domain a way to connect the visible identity to authenticated infrastructure, receive reports about its use, and express a handling preference when the two do not align. Properly deployed, it makes direct impersonation of your exact domain materially harder. It is not, however, a universal phishing filter.

DMARC decision diagram comparing aligned legitimate email with an unauthorized phishing message using the same visible From domain — FIG.DMARC compares the visible From domain with an authenticated SPF or DKIM identity. Alignment produces a pass; no aligned identity produces a failure that the receiver evaluates with the domain policy and its own signals.

The protocol changed in 2026

In May 2026, the IETF published DMARC as a Standards Track protocol in RFC 9989. The new document obsoletes RFC 7489 and RFC 9091. Aggregate reporting now lives in RFC 9990, while per-message failure reporting lives in RFC 9991. This is more than a paperwork change: the standard updates policy discovery, organizational-domain evaluation, testing, and rollout guidance.

RFC 9989 uses a DNS tree walk for policy discovery and relaxed alignment instead of the older Public Suffix List model.
The old pct tag was removed because receivers applied percentage-based enforcement inconsistently.
A t=y tag now signals that a policy is in test mode.
The np tag can define a policy for non-existent subdomains.
Aggregate and failure-report formats and handling are now specified separately.
The standard explicitly warns that general-purpose domains with human users should not casually publish p=reject because indirect mail and mailing lists can break.

How DMARC decides whether a message passes

DMARC starts with the domain in the RFC 5322 From header—the address a person normally sees in an email client. The receiver then looks for an authenticated SPF identity or DKIM signing identity that aligns with that author domain. One aligned pass is enough for the message to pass DMARC.

Visible From       [email protected]       → Author Domain: example.com
SPF identity       [email protected]   → MAIL FROM / Return-Path
DKIM identity      d=send.example.com         → Signing domain

DMARC passes when:
  SPF passes AND its domain aligns with example.com
  OR
  DKIM passes AND d= aligns with example.com

Alignment is the part many deployments miss. An email provider can pass SPF using its own bounce domain and pass DKIM using its own signing domain while DMARC still fails for your visible From domain. Ask providers to support a custom Return-Path, DKIM signing with your domain, or both.

SPF alignment and DKIM alignment solve different paths

01 / Aligned SPFThe Return-Path domain belongs to the same organizational domain as From

Useful for direct delivery, but forwarding commonly changes the connecting system and can break SPF.

02 / Aligned DKIMA valid DKIM signature uses a d= domain aligned with From

Often survives forwarding, provided an intermediary does not alter signed headers or body content.

03 / Best resilienceConfigure both SPF and DKIM, and align both where possible

Google requires both mechanisms for bulk senders even though only one aligned pass is needed for DMARC.

Relaxed alignment is the default. Under the current standard, the receiver determines whether the authenticated identity and author domain share the same organizational domain. Strict alignment requires an exact domain match. Strict mode can be useful for tightly controlled streams, but it can also break legitimate subdomain arrangements without adding value proportionate to the operational risk.

The phishing DMARC can stop

DMARC is strongest against exact-domain spoofing. If an attacker connects from unauthorized infrastructure and uses [email protected] in the visible From header, neither SPF nor DKIM should produce an aligned authenticated identity. The message fails DMARC, and a receiver can use the published policy when deciding whether to quarantine or reject it.

Fake password resets using your exact From domain
Invoice fraud that directly spoofs an employee or billing address
Executive impersonation sent as [email protected]
Unauthorized campaigns using a protected brand subdomain
Mail from non-existent subdomains when an np policy is published

The phishing DMARC does not stop

A strong policy cannot judge whether an email is honest. DMARC validates authorized use of a domain identity. It does not inspect the intent of the sender, establish that the person behind an account is trustworthy, or prove that a linked website is safe.

01 / Lookalike domain[email protected]

The attacker owns and authenticates a different domain that merely resembles yours.

02 / Display-name attack“Example Support” <[email protected]>

The visible name imitates your brand, but your protected domain is not used.

03 / Compromised accountA real employee or vendor mailbox sends the phish

The message can authenticate correctly because the attacker is using authorized infrastructure.

04 / Legitimate platform abuseAn attacker signs up for a trusted email service

The attacker's own domain may pass DMARC while the content remains malicious.

DMARC therefore belongs beside multifactor authentication, credential and API-key protection, account monitoring, employee education, inbound filtering, domain monitoring, and a fast abuse-response process. It is a high-value control, not a complete anti-phishing program.

Start with a complete sender inventory

The greatest deployment risk is not the DNS syntax. It is an authorized system nobody remembered. Marketing, support, finance, recruiting, product notifications, ticketing systems, survey tools, CRM automations, payment platforms, and individual business units can all send with your From domain.

List every visible From domain and subdomain used by people or systems.
Map each source to an owner, provider, stream, DKIM d= domain, Return-Path, and sending IPs.
Identify systems that forward, relay, modify, or resend messages.
Separate controlled application mail from general-purpose employee mail.
Confirm who can change DNS, provider authentication, and message identity.
Create an off-domain mailbox or service capable of receiving aggregate reports.

FROM DOMAIN          OWNER       DKIM d=             RETURN-PATH              STATUS
example.com          Workspace   example.com         example.com              aligned
news.example.com     Growth      news.example.com    bounce.news.example.com  aligned
billing.example.com  Finance     provider.example    provider.example         fails
support.example.com  Support     support.example.com ticket.vendor.example    DKIM aligned

Publish monitoring before enforcement

A monitoring policy requests reports without asking receivers to quarantine or reject failing mail. Keep the first record simple, use an address that can handle compressed XML reports, and verify the external reporting authorization required when reports go to another organizational domain.

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

The rua address receives aggregate reports: counts grouped by source, authentication result, alignment, and receiver disposition. These are operational datasets, not alert emails written for a person. Parse them with a DMARC reporting service or a controlled pipeline rather than letting XML attachments accumulate unread.

Read reports as evidence, not a pass-rate trophy

A high pass rate can hide a small but business-critical source. A low-volume payroll or password-reset system matters more than a large unauthorized scan. Classify report rows by ownership and intent before deciding what to fix or block.

01 / Known and alignedAuthorized source passing with your DKIM or Return-Path domain

Document it, keep the owner current, and monitor for changes.

02 / Known but unalignedAuthorized platform authenticating only with provider domains

Configure custom DKIM or Return-Path before enforcement.

03 / Unknown but plausibleCloud or vendor source that could belong to another team

Trace message samples and ownership; do not authorize it based on IP alone.

04 / UnauthorizedNo business owner, no approved provider, and failing alignment

Preserve evidence, investigate compromise, and let the future policy contain it.

Prefer aligned DKIM for durable protection

For every important stream, configure aligned DKIM even if SPF already aligns. SPF depends on the system making the final SMTP connection and is fragile under forwarding. DKIM attaches the authenticated domain to the message and normally survives a simple relay.

DKIM is not indestructible. Mailing lists, security gateways, and forwarders can modify a subject, footer, MIME structure, or body in a way that invalidates the signature. This is why enforcement decisions must account for indirect mail and why domains used by human mailboxes require more care than dedicated notification subdomains.

Design subdomains around risk and mail behavior

Separate domains let you apply policy according to how mail behaves. A dedicated receipts subdomain controlled by one API is different from the root domain used by employees who join mailing lists. Publishing explicit records on active author domains also reduces ambiguity while old and new DMARC implementations coexist.

_dmarc.notify.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]; adkim=r; aspf=r"

At the organizational domain, p applies to the domain and normally becomes the fallback for subdomains. The sp tag can set the policy for existing subdomains, while the new np tag can set a policy for subdomains that do not exist. Do not publish an aggressive inherited policy until you have mapped every real subdomain that sends mail.

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; sp=quarantine; np=reject; rua=mailto:[email protected]"

Move enforcement according to the domain's job

For a controlled, non-user sending subdomain, move from p=none to p=quarantine after reports show that every legitimate source has aligned DKIM or SPF. Observe receiver results, support tickets, and indirect paths before considering p=reject. Make one policy change at a time and keep an explicit rollback record ready.

For a general-purpose domain used by people, the new standard recommends much more caution. RFC 9989 says such domains should not publish p=reject when users might post to internet mailing lists. It advises at least a month at p=none, followed by an equally long period at p=quarantine, with report comparison before any stricter choice.

Use p=none while discovering and repairing authorized sources.
Use p=quarantine first on tightly controlled domains and subdomains.
Evaluate p=reject per domain, not as a universal maturity badge.
Do not use the removed pct tag for percentage-based rollout.
Understand that older receivers may not implement the new t=y test signal immediately.
Keep report collection running after enforcement; infrastructure never stops changing.

Forwarding and mailing lists need a separate test plan

Forwarding often breaks SPF because the forwarder's IP is not authorized by the original domain. DKIM can preserve a DMARC pass, but content changes can break the signature. Mailing lists may rewrite the From header or otherwise adapt messages to avoid policy failures, and receivers can use local knowledge or Authenticated Received Chain information when evaluating indirect mail.

Test the actual routes your users rely on: customer forwarding, support-ticket replies, group aliases, security gateways, CRM ingestion, and public mailing lists. A clean direct-send test does not prove those paths are safe.

Gmail and Yahoo require DMARC from bulk senders

Gmail requires senders exceeding 5,000 messages per day to personal Gmail accounts to configure SPF, DKIM, and DMARC. The minimum DMARC policy can be p=none, and direct mail must align the visible From domain with either the SPF or DKIM organizational domain. Google says only one aligned mechanism is required for DMARC today but recommends aligning both and notes that both may eventually become required.

Yahoo's sender requirements likewise call for a valid DMARC policy of at least p=none and require DMARC to pass. These requirements make monitoring-mode DMARC part of basic sending eligibility, but compliance is not the same as phishing protection. A p=none record reports failures without asking receivers for an enforcement disposition.

A DMARC incident workflow

Confirm the exact visible From, DKIM d=, Return-Path, source IP, and Authentication-Results.
Determine whether the message failed DMARC, passed through an authorized system, or used a lookalike domain.
If an authorized account or API key sent it, treat the event as credential compromise and revoke access.
If the exact domain was spoofed, verify policy discovery and whether the receiver applied local handling.
Search aggregate reports for the source and the earliest appearance of the pattern.
Preserve headers and URLs, notify affected providers, and block malicious destinations through appropriate channels.
Update sender inventory, access controls, and monitoring rules after containment.

The operating model that keeps DMARC useful

Review aggregate reports every week and alert on new sources, falling alignment, unexpected subdomains, or abrupt volume changes. Review provider ownership and DNS access monthly. Re-run the sender inventory before adding a platform, changing a Return-Path, migrating support tools, acquiring a company, or changing a domain used by employees.

The strongest DMARC program makes a narrow, honest promise: authorized systems can prove their relationship to the domain people see, and unauthorized direct use becomes easier for receivers to identify and contain. Combine that promise with secure accounts, protected credentials, domain monitoring, and informed recipients to address the wider phishing problem.