What Is DMARC Alignment: The Complete Guide to SPF and DKIM Alignment, Strict vs. Relaxed Modes, and Configuration

DMARC alignment is the mechanism that verifies the domain in the visible From header matches the domain authenticated by SPF (Sender Policy Framework) or DKIM (DomainKeys Identified Mail). Without alignment, even properly authenticated email can fail DMARC, leaving a domain open to domain spoofing regardless of how carefully authentication records are configured.

This guide covers the complete mechanics of SPF and DKIM alignment and the critical differences between strict and relaxed matching modes. It also explains how to configure the aspf and adkim tags in a DMARC record and lays out a systematic approach to diagnosing and resolving alignment failures across complex sending environments.

Google and Yahoo now require DMARC for bulk senders exceeding 5,000 messages per day, making alignment quality a practical email deliverability requirement rather than an optional security enhancement. Misaligned configurations increasingly result in quarantined or rejected email at major mailbox providers, and the 2024 bulk sender mandates have accelerated adoption timelines for organizations that had previously deferred DMARC enforcement.

Understanding DMARC alignment provides the technical foundation to configure enforcement policies that stop email spoofing, protect brand reputation, and improve inbox placement, without disrupting the legitimate email an organization depends on.

Organizations seeking to improve their email security are encouraged to explore an Adaptive Security self-guided tour.

What Is DMARC Alignment?

DMARC alignment is the mechanism that verifies the domain displayed in an email’s visible “From” header matches the domain authenticated by SPF or DKIM, as defined in RFC 9989. It serves as the critical bridge between raw authentication results and DMARC enforcement policy, ensuring that a message authenticated against one domain cannot impersonate another.

Without alignment, an attacker can configure SPF and DKIM for a domain they control while displaying a trusted brand in the From field and still produce a technically passing authentication result.

Alignment transforms DMARC from a passive reporting protocol into an active anti-spoofing control. SPF validates whether the sending IP is authorized by the domain in the Return-Path. DKIM verifies whether the cryptographic signature matches the signing domain. Neither protocol cares about the From header, the only domain the recipient actually sees.

DMARC alignment closes that gap by imposing a single rule: the domain the recipient trusts must be the same domain that passed authentication. When alignment fails, DMARC fails, regardless of how strong the SPF or DKIM result looked in isolation.

This distinction matters because email spoofing is not a theoretical edge case. The FBI's IC3 2025 annual report recorded $3.04 billion in business email compromise (BEC) losses alongside $215.8 million in phishing and spoofing losses.

Every one of those attacks exploited the gap between what authentication protocols verify and what recipients see. Alignment is the mechanism designed to close that gap at the protocol level, before a fraudulent message ever reaches an inbox.

The Definition: What Alignment Actually Means in RFC 9989

RFC 9989 defines DMARC alignment through “identifier alignment.” The specification designates the domain in the From header as the “RFC5322.From domain,” the central identity DMARC exists to protect.

During evaluation, DMARC compares this central identity against two other identifiers: the domain authenticated by SPF, drawn from the Return-Path, and the domain authenticated by DKIM, the d= value in the DKIM signature header. The email passes DMARC if at least one of those authenticated domains aligns with the From domain under the alignment mode selected by the domain owner.

The specification breaks alignment into two configurable modes: strict alignment and relaxed alignment. Strict alignment requires an exact, character-for-character domain match between the From header and the authenticated identifier.

Relaxed alignment requires only that both domains share the same organizational domain, the registered domain stripped of any subdomain prefixes. RFC 9989 defaults both aspf and adkim to relaxed mode, reflecting the reality that most organizations send mail from multiple subdomains and third-party platforms.

The durability of the design rests on OR logic: either SPF alignment or DKIM alignment is sufficient; both are not required. A message forwarded through a mailing list may break SPF alignment because the forwarding server's IP is absent from the original sender's SPF record.

If the DKIM signature survives the forward intact, DKIM alignment can still carry DMARC to a pass. This redundancy is deliberate: the authors of RFC 9989 understood that no single authentication path survives every real-world email topology.

SPF Alignment vs. DKIM Alignment: Two Paths to the Same Goal

SPF alignment and DKIM alignment travel different routes to the same destination. Understanding their mechanics is essential for diagnosing why legitimate email sometimes fails DMARC.

SPF alignment compares the domain in the Return-Path header, the invisible bounce address that receives non-delivery notifications, against the domain in the From header. SPF itself validates the sending server's IP address against the SPF record published by the Return-Path domain.

Alignment extends that check: even if SPF passes, DMARC requires the Return-Path domain to match the From domain according to the selected alignment mode. Email forwarding is the most common breaker of SPF alignment.

When a forwarding server relays a message, the Return-Path is often rewritten to the forwarder's domain, and the forwarder's IP is naturally absent from the original sender's SPF record. The SPF check may still pass against the new Return-Path, but alignment against the original From domain fails.

DKIM alignment compares the signing domain, the d= tag in the DKIM-Signature header, against the From domain. Unlike SPF, DKIM does not depend on IP addresses; the signature is bound to the message body and selected headers at the time of sending.

If the message content and signed headers remain intact during transit, DKIM will verify regardless of how many hops the message traverses. This makes DKIM alignment the more resilient path for forwarded messages, provided the forwarding server does not modify signed headers or the message body.

A DMARCguard study of 5.5 million domains published in February 2026 found that 48.5% of DMARC-enabled domains deploy both SPF and DKIM, while 43% rely on SPF alone, leaving those domains vulnerable to alignment failures triggered by forwarding or third-party sender misconfiguration.

Organizations should configure both paths even though DMARC requires only one to pass. SPF alone is fragile. DKIM alone works for most forwarding scenarios but can still fail if intermediate servers modify message content. Together they provide the redundancy that keeps legitimate email flowing while spoofed messages fail alignment.

The Organizational Domain Concept: How “Relaxed” Matching Works

Relaxed alignment is the default mode in DMARC for good reason: it maps to how organizations actually send email. The organizational domain is the registered domain stripped of all subdomain labels. For mail.example.com, the organizational domain is example.com. For newsletters.marketing.example.co.uk, it is example.co.uk.

The public suffix list, maintained by the Mozilla Foundation, determines where the organizational boundary sits for domains with multi-part suffixes.

Under relaxed alignment, any subdomain of the organizational domain matches. If the From header shows example.com and the DKIM signature carries d=marketing.example.com, relaxed alignment passes. The same From domain paired with a Return-Path of bounce.mail.example.com also passes relaxed SPF alignment.

This flexibility is critical for organizations using multiple email service providers: a CRM authenticating as crm.example.com, a marketing platform signing as email.example.com, and a transactional mail service using tx.example.com can all achieve alignment without forcing every tool onto the root domain.

Under strict alignment, none of those subdomains would match; strict mode requires example.com to equal example.com, exactly. The mode is powerful against domain spoofing targeting subdomains, where an attacker exploits a misconfigured organizational subdomain, but it demands that every legitimate sending source authenticates with precisely the same domain shown in the From header.

Organizations with distributed sending infrastructure will find strict alignment breaks deliverability unless they consolidate their email architecture.

Most organizations begin with relaxed alignment, monitor DMARC reports to confirm all legitimate sources align, and only consider strict alignment once the sending ecosystem is fully understood and controlled. The goal is not stricter alignment for its own sake; alignment should block spoofing while keeping legitimate mail operational.

Getting that configuration right determines whether a phishing simulation tests employee awareness against realistic spoofed messages or collapses at the first authentication hop.

Why DMARC Alignment Matters

DMARC alignment is the mechanism that makes email authentication actually mean something. It requires the domain authenticated by SPF or DKIM to match the domain visible in the From header that recipients see.

A 2026 DMARCguard study of 5.5 million domains found that only 12.8% enforce DMARC policies, meaning the vast majority of organizations have no reliable way to prevent someone from sending email that looks like it came from them.

Without alignment, an attacker can configure SPF to authorize its own sending infrastructure, pass the authentication check, and still display an organization's domain in the recipient's inbox, all while the technical logs show “SPF: pass.”

Stopping Domain Spoofing: Why Authentication Alone Is Not Enough

SPF and DKIM were designed to solve different problems, and neither was built to answer the question users actually care about: is this email genuinely from the organization in the From field?

SPF validates the envelope sender domain, the return path that most recipients never see, not the From address displayed in the inbox.

An attacker who controls malicious-sender.com can publish an SPF record authorizing its own mail server, send a message with malicious-sender.com in the envelope, and put company.com in the visible From header. SPF passes.

DKIM similarly authenticates the signing domain, which can be any domain the attacker controls. The recipient sees a trusted brand and opens the email.

Alignment closes this gap by demanding identity coherence. Under DMARC, a message passes only when the domain authenticated by SPF or DKIM is the same domain shown to the recipient, either matching exactly (strict alignment) or sharing the same organizational domain (relaxed alignment).

This single requirement transforms SPF and DKIM from independent checks that an impersonator can pass individually into a unified barrier that protects the one field humans actually look at.

The Deliverability Imperative: How Alignment Affects Inbox Placement

Alignment stopped being a theoretical best practice in February 2024 when Google and Yahoo began requiring DMARC authentication for any sender delivering 5,000 or more messages per day to their platforms. Microsoft followed in May 2025, extending the same requirement to Outlook, Hotmail, and Live consumer mailboxes.

The enforcement is not gentle. As of November 2025, Google issues permanent 550 rejection errors for non-compliant email, and Microsoft returns 550 5.7.515 codes. Messages are refused at the SMTP level, never reaching any folder. There are no temporary deferrals and no second attempts.

The consequences extend well beyond bulk marketing campaigns. Transactional emails, password resets, order confirmations, and account notifications are equally subject to these rules.

A misaligned DMARC record can silently prevent customers from receiving purchase receipts or login codes, creating support tickets that internal teams cannot diagnose from their own logs, because the rejection happened at the receiving server.

According to Google's email sender guidelines, even domains operating below the 5,000 message threshold benefit from authentication because aligned email consistently achieves higher inbox placement rates and gets routed to spam far less often.

The mailbox providers have made their position unambiguous: alignment is the baseline for inbox access, and organizations that treat it as optional are ceding email deliverability to competitors that got it right.

How DMARC Alignment Protects Brand and Recipients from Impersonation

Every unaligned domain is an open invitation for impersonation. When an organization lacks DMARC enforcement with alignment, an attacker can send phishing emails bearing that domain to customers, partners, and employees, and those messages will sail through authentication checks that receiving servers treat as definitive.

The recipient trusts the email because it appears to come from a company they do business with. They click, they enter credentials, they wire funds. This is not a hypothetical scenario. Recent email security statistics confirm the trend is accelerating rather than leveling off.

The damage compounds quickly. A single successful impersonation erodes trust across an entire customer base, triggers regulatory scrutiny if customer data is compromised, and forces security teams into a reactive posture that costs far more than proper authentication would have.

Alignment protects all three groups that depend on a domain's integrity. Customers see legitimate transactional and marketing emails without having to distinguish them from forgeries. Partners and vendors can act on invoices and contract communications without second-guessing origin.

Employees, who face phishing simulations and real attacks daily, are spared the impossible task of visually distinguishing a well-crafted spoof from a genuine internal message.

DMARC alignment shifts the burden of detection from the human eye to the email protocol itself, where it belongs. Getting there means moving from a monitoring posture to full enforcement before a domain becomes the next vector an attacker uses against the people who trust it.

How DMARC Alignment Works: The SPF and DKIM Check Process

DMARC alignment is the verification step that prevents email spoofers from authenticating with one domain while displaying a different, trusted domain in the recipient's inbox.

When a receiving mail server encounters an inbound message, it runs two independent authentication checks, SPF and DKIM, then evaluates whether the domains used in those checks match the domain visible in the From header. Only if at least one authentication method both passes its own check and achieves alignment does DMARC itself pass, triggering whatever policy the domain owner has published.

Alignment is the mechanism that catches those breaks before they undermine the entire framework. The flow is sequential but conceptually straightforward: SPF check, then SPF alignment evaluation; DKIM signature validation, then DKIM alignment evaluation.

A combined result determines whether DMARC passes or fails. A single alignment pass, from either SPF or DKIM, is sufficient. When neither aligns, DMARC fails and the published policy (none, quarantine, or reject) activates. The receiving server makes this determination in milliseconds, silently, for every message that arrives.

The SPF Alignment Check: Return-Path vs. Header From

SPF alignment verifies that the IP address sending the message is authorized by the domain's published SPF record. But the domain SPF checks is not the one recipients see.

SPF evaluates the Return-Path domain, also called the envelope From or MAIL FROM, which is the bounce address set by the sending infrastructure during the SMTP conversation. This domain is invisible to the end user unless they inspect the raw message headers.

The Return-Path gets populated by the sending mail server, not the message composer. When an organization uses a third-party email service, a marketing automation platform, a transactional email provider, or a CRM, that service often sets the Return-Path to its own domain to receive bounce notifications.

This creates the most common SPF alignment failure: the header From shows company.com while the Return-Path reads mailservice.com. SPF may authenticate the message perfectly. DMARC sees two different domains and alignment breaks.

DMARC offers two alignment modes for SPF, controlled by the aspf tag in the DMARC record. Strict alignment (aspf=s) requires an exact domain match between the Return-Path and the header From. If the From address is sender@company.com and the Return-Path is bounces@mail.company.com, strict mode fails.

The subdomain does not equal the organizational domain letter for letter. Relaxed alignment (aspf=r), which is the default, allows organizational domain matches. Under relaxed mode, company.com and mail.company.com share the same organizational domain and pass alignment. Only a completely different domain, otherdomain.com, would fail.

SPF macro expansions add a layer of dynamic behavior that can influence alignment outcomes, particularly for organizations with complex sending architectures. The %{d} macro expands to the current domain being evaluated, and %{o} expands to the organizational domain of the sender.

When used in SPF record mechanisms, these macros allow senders to construct dynamic authorization rules that adapt to the domain context. Misconfigured macro expansions are a common source of alignment failures that persist even after SPF records appear syntactically correct.

The DKIM Alignment Check: d= Domain vs. Header From

DKIM authentication works differently. Instead of checking the sending IP, it validates a cryptographic signature embedded in the message headers. Every DKIM signature contains a d= tag that identifies the domain that signed the message. That signing domain is the one DMARC compares against the header From domain during the alignment check.

The d= value is set by the sending infrastructure at the moment the message is signed. An organization using Google Workspace might see d=google.com or, if custom DKIM is configured, d=company.com.

A misconfigured transactional email provider might sign with its own domain, d=sendgrid.com, even when the header From displays the customer's brand. When this happens, DKIM passes its cryptographic validation but DMARC alignment fails because the signing domain does not match what recipients see.

DKIM alignment uses the same strict-versus-relaxed framework as SPF, controlled by the adkim tag. Strict DKIM alignment (adkim=s) demands an exact domain match: d=company.com aligns with a From header of company.com, but d=marketing.company.com does not.

Relaxed DKIM alignment (adkim=r), the default, treats subdomain matches as passing. Under relaxed mode, d=marketing.company.com aligns with a company.com From header because both share the same organizational domain. Only a wholly different domain, d=otherdomain.com, fails.

DKIM has a structural advantage over SPF in the alignment race. SPF breaks easily when email is forwarded, because the forwarding server's IP address is unlikely to appear in the original sender's SPF record. DKIM signatures, by contrast, survive forwarding as long as the message body and signed headers remain unmodified.

This is why DKIM carries most of the alignment burden in real-world deployments. The Cloudflare Radar Q1 2026 data confirms the pattern: DKIM achieved a 90.90% global pass rate, compared to SPF's 80.24%, with DKIM's fail rate at just 1.67% versus SPF's 14.54%. When DMARC passes, DKIM is typically the mechanism doing the work.

Combining Results: How DMARC Decides Pass or Fail

Once both authentication checks are complete, DMARC evaluates the combined result using simple OR logic: the message passes DMARC if SPF passes with alignment, or if DKIM passes with alignment, or if both do. The threshold is one.

A message that achieves DKIM alignment but fails SPF alignment nonetheless passes DMARC. The receiving server applies the domain's published policy as if everything checked out.

The decision matrix plays out in distinct scenarios. When both SPF and DKIM pass and align, DMARC passes with maximum confidence. This is the ideal state and the one every organization should target for its legitimate mail streams.

When only one aligns, a common pattern for forwarded mail where DKIM passes with alignment while SPF fails, DMARC still passes, though some receiving servers may weight the SPF failure in their spam scoring separately from the DMARC result.

When neither aligns, DMARC fails regardless of whether SPF or DKIM individually passed their own checks. An SPF pass on mailservice.com with a DKIM signature from sendgrid.net, paired with a From header of company.com, produces two authentication successes and zero alignments. DMARC correctly treats this as a failure.

The published DMARC policy then activates based on the combined result. A p=none policy means the message is delivered normally and a report is generated, monitoring only, no enforcement. A p=quarantine policy directs the receiving server to treat the message as suspicious, typically routing it to the spam folder. A p=reject policy instructs the server to refuse delivery outright.

The policy percentage (pct= tag) allows domain owners to apply enforcement gradually, quarantining or rejecting only a fraction of failing messages, a common strategy during DMARC enforcement deployment to avoid disrupting legitimate but misaligned mail streams before they are identified and fixed.

The path from message arrival to policy application runs cleanly: SPF check on the Return-Path, then SPF alignment against the header From; DKIM signature validation, then DKIM alignment of the d= domain against the header From; combined pass-if-either-aligns logic; and finally the policy action.

Every email traverses this exact sequence. The difference between a message landing in the inbox and one getting silently rejected turns on whether at least one of those two alignment checks succeeds. Organizations that stop at SPF and DKIM configuration without verifying alignment have solved only half the problem.

The authentication checks run, the reports arrive, and legitimate mail still disappears into spam folders because the domains never match.

Strict vs. Relaxed DMARC Alignment: A Complete Comparison

A DMARC policy is only as strong as its alignment configuration. DMARC alignment determines whether the domain recipients see in the From header matches the domain that passed SPF or DKIM authentication, and the mode chosen has direct consequences for both security posture and email deliverability.

Strict alignment demands an exact domain match between the From header and the authenticated domain. Relaxed alignment requires only that both domains share the same organizational domain, allowing subdomains to pass.

Strict alignment closes the door on subdomain spoofing entirely, making it the strongest possible DMARC posture and the default recommendation for financial institutions, government agencies, and any organization where a single impersonated email could trigger catastrophic financial or reputational damage.

Relaxed alignment acknowledges the reality that most organizations route email through multiple subdomains and third-party senders, trading a theoretical increase in subdomain-level risk for dramatically fewer false positives and delivery failures.

The right choice depends on the sending infrastructure, but a 2026 analysis by DMARC Report found that only 9% of domains with DMARC records reach enforcement, underscoring how many organizations are still wrestling with the alignment-and-deliverability trade-off before locking down.

Every DMARC record contains two alignment tags, aspf for SPF and adkim for DKIM, and each can be set independently. The default for both is relaxed because the DMARC specification was written with the understanding that most organizations would break their own mail flow before an attacker did if strict mode shipped as the factory setting.

Strict Alignment: Exact Domain Matching and When to Use It

Strict alignment means the domain in the From header must be character-for-character identical to the domain authenticated by SPF or DKIM. There is no subdomain leniency.

An email sent with a From header of example.com and a Return-Path of mail.example.com will fail SPF alignment under strict mode, even though mail.example.com is a legitimate subdomain owned by the same organization. A DKIM signature carrying d=newsletter.example.com alongside a From header of example.com will fail DKIM alignment in strict mode for the same reason.

This zero-tolerance approach eliminates the most common vector for subdomain spoofing. An attacker who gains control of an abandoned or unmonitored subdomain cannot use it to send email that passes strict DMARC alignment against the organizational domain.

In relaxed mode, that same attacker could configure SPF and DKIM on the compromised subdomain and have those messages pass DMARC because the organizational domain matches. Strict alignment removes that attack path entirely.

The downside is operational friction with legitimate senders. Any third-party email platform that sends on an organization's behalf using its own Return-Path domain will fail strict SPF alignment. SaaS platforms rarely configure their sending infrastructure to match the customer's exact From domain, and getting every vendor to comply is a months-long negotiation rather than a technical toggle.

Strict alignment works best in environments where the organization controls every sending source. Financial institutions, government agencies, and regulated enterprises that route all email through a single, internally managed mail infrastructure are the natural candidates.

These organizations also have the most to lose. For these entities, the inconvenience of vendor compliance is dwarfed by the cost of a single successful spoof.

Relaxed Alignment: Subdomain Flexibility and the Organizational Domain Concept

Relaxed alignment operates on the concept of the organizational domain, the registrable domain name stripped of all subdomain prefixes. The organizational domain of mail.example.com, newsletter.example.com, and support.example.com is always example.com.

Under relaxed alignment, any SPF Return-Path or DKIM signing domain that shares the same organizational domain as the From header passes the alignment check.

Consider a SaaS company that sends transactional emails with a From header of company.com while its email service provider uses a Return-Path of mail.company.com for bounce handling. Under relaxed SPF alignment (aspf=r), this passes because the organizational domain is identical.

Switch to strict alignment and it fails immediately, even though the email is legitimate and the configuration follows the provider's documented best practices.

The same logic applies to DKIM. A marketing platform might sign emails with d=marketing.company.com while the From header reads company.com. Relaxed DKIM alignment (adkim=r) passes this without issue.

This flexibility is not a security compromise. It is a practical acknowledgment that the modern enterprise email ecosystem spans dozens of subdomains managed by different teams and vendors, and requiring exact domain matching across all of them would break more legitimate mail than it would stop attacks.

The theoretical risk is that an attacker could compromise an unmonitored subdomain and send spoofed email that passes relaxed DMARC. Organizations mitigate this by publishing a separate DMARC record with p=reject on unused or parked subdomains, and by using DMARC reports to identify any subdomain that starts sending unexpectedly.

The risk is real but manageable, and for most organizations, the deliverability chaos of strict alignment is the more immediate and costly problem.

Mixing Modes: Setting aspf and adkim Independently

One of the most underutilized capabilities in DMARC configuration is that aspf and adkim are independent tags. Organizations are not choosing between one global strict mode and one global relaxed mode; each represents a separate decision, with its own set of trade-offs.

A common and pragmatic configuration is aspf=r; adkim=s: relaxed SPF alignment with strict DKIM alignment. SPF is the harder protocol to keep perfectly aligned because third-party senders almost always use their own Return-Path domains, and email forwarding routinely breaks SPF by changing the sending IP.

DKIM survives forwarding. The cryptographic signature travels with the message, and as long as the content is not modified, alignment holds. By running strict DKIM and relaxed SPF, organizations get strong identity protection through cryptographic signing without sacrificing the deliverability of legitimate email that routes through third-party infrastructure.

The inverse, aspf=s; adkim=r, is less common but valid. An organization with total control over its SPF-authorized sending IPs but a complex DKIM signing architecture involving multiple signing subdomains might prefer this configuration.

DMARC passes if either SPF or DKIM aligns, so an organization can afford to be strict on the protocol it controls tightly and relaxed on the one that spans multiple vendors and subdomains.

Transitioning from relaxed to strict on either tag requires careful auditing. Start with DMARC reports to identify every sending source that currently authenticates under relaxed mode and verify which ones would fail under strict.

Either reconfigure those sources for exact domain matching or accept that they must remain on relaxed alignment. A phased rollout, moving adkim to strict first, monitoring for a full reporting cycle, then evaluating aspf, prevents the all-too-common scenario where an administrator flips both tags to strict on a Friday afternoon and discovers on Monday that the CRM stopped delivering emails three days ago.

Alignment configuration is a foundational email authentication control. The spoofed emails that still reach an inbox, whether from compromised third-party domains or lookalike addresses, land in front of an employee who has to make a split-second trust decision.

Phishing simulations that replicate those exact scenarios determine whether that employee clicks or reports.

Common Causes of DMARC Alignment Failures

Most DMARC failures trace back to a single problem: a domain mismatch between what was authenticated and what recipients see in the visible From header. SPF and DKIM both return passing results, but DMARC still fails because the Return-Path domain or the DKIM signing domain does not match the domain in the From field.

An observational study of 1.1 billion messages across 118 domains found that 73% of forwarding-induced DMARC failures stemmed from SPF-only breakdowns, while 21% traced back to DKIM breakage caused by content modification in transit.

These are not authentication failures in the traditional sense. Both checks technically pass. The domains simply do not line up the way DMARC requires, and the downstream consequence is that legitimate email gets quarantined or rejected alongside actual spoofing attempts.

SPF Alignment Failures: Third-Party Return-Path Overwrites

SPF alignment breaks most frequently when a third-party sending service rewrites the Return-Path to its own domain. Email marketing platforms, CRMs, and support ticketing systems do this to handle bounce processing internally.

A transactional email sent from an organization's domain authenticates against SendGrid's SPF record without issue, but the Return-Path reads @sendgrid.net instead of @companydomain.com. DMARC sees the mismatch and fails alignment even though SPF itself passed.

This pattern repeats across nearly every SaaS platform that sends email on an organization's behalf. Zendesk rewrites the envelope to @zendesk.com. Salesforce does the same. HubSpot and Marketo offer custom envelope-from settings, but they require explicit configuration that most teams skip during initial setup.

The authentication passes cleanly because the sending IP is authorized by the third party's SPF record. The domain in the Return-Path is what sinks alignment.

SPF record flattening introduces a related and less visible cause. When DNS management tools collapse an SPF record with multiple includes into a static list of IP addresses, they can obscure the original envelope domain and strip the relationship between the sending service and the domain it represents.

CNAME flattening creates a similar side effect. When a DNS provider resolves CNAME chains at query time rather than preserving the chain, the Return-Path domain may resolve to an unexpected value that no longer matches the From header.

DKIM Alignment Failures: Mismatched Signing Domains and Forwarding Damage

DKIM alignment failure trips up nearly every organization using third-party email services. The DKIM signature's d= tag must match the organizational domain in the From header.

When an email service provider signs with its own domain, such as d=sendgrid.net rather than d=companydomain.com, DKIM verification succeeds but alignment fails. Mailchimp, HubSpot, Salesforce, and Zendesk all default to signing with their own domain unless custom DKIM is explicitly configured.

“The most misunderstood thing about DMARC is that SPF passing is not enough. The domains have to align,” said Brad Slavin, General Manager of DuoCircle. “We see this constantly: SPF passes, DKIM passes, but DMARC still fails because the Return-Path domain doesn't match the From header.”

Missing DKIM signatures on forwarded or relayed messages create a second failure path. If a message arrives with no DKIM signature and SPF alignment has already been broken by the forwarding hop, DMARC has no fallback mechanism.

DKIM signature breakage due to intermediate modifications is the third common vector. Mailing lists that prepend [List Name] to subject lines, append legal disclaimers or unsubscribe footers, or re-wrap MIME boundaries invalidate the original DKIM body hash.

The signature remains cryptographically intact, but the content it was computed against no longer matches. Receiving servers see dkim=fail (body hash did not verify) and DMARC falls through to failure if SPF alignment is also unavailable.

The Email Forwarding Problem: Why It Breaks Alignment and What to Do

Email forwarding is the single most disruptive DMARC alignment scenario because it attacks SPF and can compromise DKIM in sequence. When a message forwards from one mailbox to another, the forwarding server becomes the connecting IP. That IP is not authorized in the original sender's SPF record. SPF breaks immediately.

The header From and the original DKIM signature are preserved, so DKIM often survives a simple forward. But if the forwarding server or any downstream intermediary modifies the message body or headers, that DKIM signature breaks too and DMARC has nothing left to evaluate.

Multi-hop forwarding compounds the damage. A message that routes through a corporate alias to a personal Gmail account and then to a mailing list accumulates modification opportunities at each hop. SPF is almost certainly broken after the first forward unless SRS (Sender Rewriting Scheme) is applied at every hop.

DKIM may survive the first hop but break at the second when the mailing list adds a footer. By the final delivery, both authentication protocols fail alignment and the message is indistinguishable from a spoofed email.

The DMARCReport observational study found that domains deploying ARC (Authenticated Received Chain) at major forwarders reduced DMARC failures on forwarded mail by a median of 52% across Gmail delivery paths.

For organizations that cannot deploy ARC, the practical fallback is to ensure DKIM is configured on every sending source with relaxed canonicalization (c=relaxed/relaxed) so that at least one protocol survives the forwarding chain.

Parked and non-sending domains add a quieter but persistent failure source when they publish DMARC records without corresponding SPF and DKIM configurations. These domains generate continuous failure reports that create noise in aggregate data without providing any protective value.

The fix is unambiguous: either configure authentication for every domain that publishes a DMARC record, or remove the record from domains that never send mail. Without that discipline, alignment failures continue to erode deliverability and leave the door open to the domain spoofing DMARC was designed to stop.

How to Configure DMARC Alignment Using aspf and adkim Tags

Configuring DMARC alignment means setting the aspf tag for SPF alignment mode and the adkim tag for DKIM alignment mode, each accepting r for relaxed or s for strict.

A 2026 analysis of 5.5 million domains found only 30.4% have published a DMARC record at all, and the most common reason organizations stall at p=none is discovering third-party senders that cannot align.

The path forward is straightforward. Audit every service that sends email as the organization's domain and fix misalignments before tightening enforcement. Then progress through a phased deployment that starts at p=none with relaxed defaults and ends at p=reject with strict alignment, only after aggregate reports confirm zero legitimate mail breaks. These email security best practices apply across the full SPF, DKIM, and DMARC configuration lifecycle.

1. DMARC Record Syntax: The aspf and adkim Tags Explained

DMARC records live as DNS TXT records at _dmarc.companydomain.com. Within that record, two optional tags control how strictly SPF and DKIM authenticated domains must match the domain shown in the From header, the address recipients actually see.

The aspf tag governs SPF alignment. It compares the Return-Path domain (the envelope sender or bounce address) against the From domain. Set to aspf=r (relaxed), it accepts an organizational domain match, meaning bounce.example.com aligns with example.com.

Set to aspf=s (strict), it demands an exact match. If the tag is omitted entirely, relaxed mode applies automatically per RFC 9989 Section 4.7.

The adkim tag governs DKIM alignment. It compares the DKIM signing domain (the d= value in the DKIM signature header) against the From domain. adkim=r accepts organizational domain matches, so a signature from d=mail.example.com aligns with example.com. adkim=s requires the domains to be identical. Like aspf, it defaults to relaxed when absent.

These tags operate independently. Mixing modes, aspf=s; adkim=r, is valid and common. For DMARC to pass, only one of SPF or DKIM needs to achieve alignment; both are not required. In practice, most organizations rely on DKIM alignment because it survives email forwarding intact, while SPF alignment breaks anytime a forwarder changes the sending IP.

Here are the four concrete record patterns most organizations move through during deployment.

Basic monitoring record (defaults to relaxed):

v=DMARC1; p=none; rua=mailto:dmarc@example.com

Explicit relaxed alignment:

v=DMARC1; p=none; rua=mailto:dmarc@example.com; aspf=r; adkim=r

Mixed strict SPF with relaxed DKIM:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; aspf=s; adkim=r

Production enforcement with full strict alignment:

v=DMARC1; p=reject; rua=mailto:dmarc@example.com; aspf=s; adkim=s

2. Step-by-Step: From p=none Relaxed to p=reject Strict

Phase 1, Monitor at p=none with relaxed alignment. Publish a record with p=none and no explicit alignment tags; relaxed is the default. This tells receiving mail servers to take no action on DMARC failures but to send aggregate reports to the address specified in rua.

Let this run for at least two weeks. The goal is visibility rather than enforcement. Every sending source will appear in the reports, including services that were previously forgotten.

Phase 2, Inventory every sending service. Open the aggregate reports and compile a complete list of every IP and domain that sends mail claiming the organization's domain in the From header. Common discoveries: the marketing team's Mailchimp account, a forgotten SendGrid integration in staging, the HR platform sending offer letters, the CRM firing automated sequences.

For each service, verify whether it supports custom DKIM signing with the organization's domain and whether it offers a custom Return-Path, also called a custom MAIL FROM domain. Services that sign DKIM with their own domain, d=sendgrid.net instead of d=companydomain.com, will fail DKIM alignment under any mode, relaxed or strict.

Phase 3, Fix misalignments before tightening. Configure custom DKIM signing on every third-party service that supports it. For services that cannot sign with the organization's domain, isolate them on a subdomain, transactional.example.com or marketing.example.com, and publish a separate DMARC record for that subdomain so failures there never impact the root domain's reputation.

Subdomain isolation keeps third-party email from polluting the primary domain's authentication results.

Phase 4, Progressively tighten policy. Once reports show consistent alignment across all sources, move to p=quarantine with relaxed alignment for another two to four weeks. Monitor for deliverability complaints.

If clean, switch to p=reject with relaxed alignment. Only after p=reject has run without incident for several weeks should strict alignment be considered, and only if the sending infrastructure uses exact domain matches everywhere with zero subdomain variation.

3. ESP-Specific Alignment: Google Workspace, Microsoft 365, and Transactional Email Services

Google Workspace signs outgoing mail with DKIM using the default google._domainkey selector once DKIM is enabled in the Admin Console under Apps > Google Workspace > Gmail > Authenticate email. The signing domain is the organization's own domain, so DKIM alignment passes under relaxed mode automatically.

For strict alignment, the From header domain must exactly match the DKIM signing domain; a message sent from @subdomain.example.com while DKIM signs as example.com will fail strict alignment. Google Workspace does not offer a custom Return-Path, so SPF alignment depends entirely on the SPF record including Google's sending IPs and using relaxed mode or an exact match for strict.

Microsoft 365 uses two DKIM selectors per domain: selector1._domainkey and selector2._domainkey. DKIM signing must be explicitly enabled for each custom domain in the Exchange Admin Center under Protection > DKIM. Until enabled, Microsoft signs with the *.onmicrosoft.com domain, which will never align with a custom domain.

After enabling, DKIM alignment passes under relaxed mode. For strict alignment, the From domain and DKIM signing domain must match exactly. Microsoft 365 also supports a custom Return-Path via the Set-DkimSigningConfig PowerShell cmdlet for organizations that need SPF alignment.

SendGrid and Mailgun both default to signing DKIM with their own domains and using their own Return-Path. This means neither SPF nor DKIM alignment will pass out of the box, regardless of alignment mode.

The fix for both platforms is identical: configure domain authentication, which generates DKIM keys signed with the sending organization's domain (d=companydomain.com), and optionally set a custom Return-Path subdomain, like bounce.companydomain.com, for SPF alignment. SendGrid offers this through Sender Authentication in the Settings menu; Mailgun provides it under Domain Settings > Sending Domains.

Mailchimp authenticates transactional and marketing emails differently. For marketing campaigns, Mailchimp signs DKIM with its own mcsv.net domain by default. Alignment will fail against the sender’s domain unless authenticated domains are enabled

Enabling authenticated domains in Account Settings generates a DKIM record that signs with the organization's domain, resolving DKIM alignment. Mailchimp does not support custom Return-Path domains, so SPF alignment is not achievable; organizations should rely on DKIM alignment exclusively.

A final checkpoint: whenever a new sending service is added, alignment should be verified before the first campaign goes out. The fastest way to break DMARC enforcement is onboarding a tool that nobody told the security team about.

Monitoring and Testing DMARC Alignment

Monitoring DMARC alignment requires reading aggregate reports to catch systemic failures, inspecting forensic reports for per-message diagnostics, manually verifying email headers when reports raise red flags, and establishing a quarterly review cadence.

Automated tooling paired with periodic manual spot-checks catches what routine monitoring misses. Infrastructure changes, newly onboarded sending services, and DKIM key rotations break alignment silently long before anyone notices deliverability problems.

1. Reading DMARC Aggregate and Forensic Reports for Alignment Data

DMARC reports (RUA) arrive daily from receiving mail servers as compressed XML files. Each report summarizes every message that claimed to come from a domain over a 24-hour window: how many passed, how many failed, and precisely why.

Despite their diagnostic value, DMARCguard found in a 2026 scan of 5.5 million domains that only 53.5% of DMARC-enabled domains configure a rua= tag, leaving nearly half of adopters blind to their own authentication failures.

The key alignment-related fields live inside <auth_results> blocks within each <record> element. For SPF, look for <spf> with a result attribute and the domain child element. DMARC alignment requires that the SPF-authenticated domain matches the organizational domain in the visible From header, or at minimum shares the same organizational suffix in relaxed mode.

When <spf> shows result="pass" but DMARC still fails, the mismatch is nearly always in that domain comparison.

For DKIM, examine the <dkim> element: the result field indicates whether the signature verified, and the selector and domain fields reveal which signing key was used. DMARC passes when at least one of SPF or DKIM produces an aligned identifier. When both SPF and DKIM alignment fail at the same time, legitimate mail bounces or lands in spam.

At scale, raw XML parsing becomes untenable. Open-source tools like parsedmarc ingest RUA reports, extract alignment data into structured formats, and generate visualizations that highlight failure patterns across sending services.

Commercial DMARC analyzers from providers such as Valimail, EasyDMARC, or Dmarcian add alerting, historical trend analysis, and guided remediation workflows. The pattern to hunt for remains the same: a sending service with a high pass rate that suddenly tips into failure, signaling an uncoordinated DNS change.

Forensic reports (RUF) go a layer deeper. These per-message failure reports include the original headers or even the full message body, exposing the exact SPF and DKIM alignment results for individual failures.

RUF adoption is extremely low because many mailbox providers decline to send them due to privacy concerns. When available, a single forensic report showing dkim=pass with d=mail.sendservice.com against a From domain of companydomain.com shows instantly that DKIM alignment failed because the signing domain does not match.

2. Manual Verification: Inspecting Email Headers for Alignment

When reports flag a problem but the root cause remains unclear, manual header inspection resolves it. Opening any email sent from the domain, viewing the raw headers, and tracing the authentication chain surfaces the issue directly.

Start with the Return-Path header. This is the envelope sender that SPF authenticates. For SPF alignment to pass in relaxed mode, the organizational domain of this address must match the organizational domain in the From header.

If Return-Path shows bounce@mail.sendgrid.net but From shows noreply@companydomain.com, SPF alignment fails regardless of whether the SPF check itself returned a pass.

Next, find the Authentication-Results header inserted by the receiving server. Modern mail servers such as Gmail and Microsoft 365 explicitly report alignment outcomes: look for dmarc=pass or dmarc=fail alongside spf=pass or dkim=pass labels, each with the authenticated domain in parentheses.

A dmarc=fail (p=reject) line combined with spf=pass (mail.sendgrid.net) shows exactly what happened: SPF authenticated the sending IP but failed DMARC because the domain portion did not align with the organizational domain.

Finally, examine the DKIM-Signature header. The d= tag reveals which domain signed the message. For DKIM alignment to pass, this domain's organizational suffix must match the From header.

A message that DKIM passes with d=yourcompany-com.20250601.gappssmtp.com satisfies alignment in relaxed mode because the signing domain traces back to the organization's Google Workspace tenant. This requires both the sending domain and the signing domain to be correctly configured in DNS.

3. Tools and Cadence: How to Test and How Often to Review

Automated testing tools catch misconfigurations before they reach production. MXToolbox's DMARC lookup performs a live DNS query against the _dmarc record and flags syntax errors, invalid tags, and policy inconsistencies.

Mail-Tester generates a unique test address, receives the message, and returns a scored report covering SPF alignment, DKIM signature validity, and DMARC evaluation.

Google Postmaster Tools provides authenticated senders with aggregate spam rate and authentication pass/fail data across Gmail delivery, making it indispensable for domains sending significant volume to consumer inboxes. Dedicated send-test-email services like GlockApps and Litmus add multi-client rendering alongside authentication verification.

The quarterly review cadence is non-negotiable. Every three months, re-examine aggregate reports to confirm alignment holds across all authorized sending services. Newly onboarded marketing automation tools, CRMs, and transactional email providers often introduce misalignment the moment they go live because their SPF include directives or DKIM signing keys were configured in haste.

A migrated email gateway, a renamed subdomain, or a rotated DKIM key all break alignment silently. Each quarterly review should reconcile the list of known sending services against what appears in reports, then investigate any unknown sources.

For DevOps teams managing DNS programmatically, DMARC alignment validation belongs in the CI/CD pipeline. A validation step that queries the published DMARC record, confirms SPF and DKIM record syntax, and runs a test email through a verification service catches misconfigurations at deployment time.

Terraform and Pulumi providers for DNS make this practical: pin the expected DMARC policy in version control, validate it as part of the deployment workflow, and prevent any change that would break alignment from reaching production. The gap between what monitoring reveals and what enforcement blocks is where most DMARC deployments stall.

DMARC Alignment and Email Deliverability

When DMARC alignment fails, legitimate email from a domain lands in spam folders or gets rejected at the receiving server. Mailbox providers that associate a domain with persistent authentication failures attach reputation damage that can take months to repair.

Google and Yahoo began enforcing DMARC for all bulk senders exceeding 5,000 messages per day in February 2024, and Mailgun's State of Email Deliverability 2025 survey found an 11% increase in DMARC adoption year-over-year, with 54% of senders now implementing the protocol.

Organizations that stop at p=none, the minimum policy that satisfies the bulk sender rules without actually protecting anything, face a widening email deliverability gap as mailbox providers increasingly weight alignment quality in their inbox-placement algorithms.

How Mailbox Providers Use Alignment as a Trust Signal

Gmail, Yahoo, and Microsoft all use DMARC alignment as a weighted signal in their spam-filtering models, rather than merely as a binary pass/fail gate. When SPF or DKIM alignment fails, the receiving server cannot cryptographically confirm that the message originated from an authorized source for the domain.

The consequence is probabilistic. A single alignment failure on a low-volume sender might trigger a quiet demotion within the inbox sorting algorithm. The same failure on a domain already flagged for high spam complaint rates can push everything into the junk folder.

The February 2024 enforcement deadline marked a structural shift. Google's sender guidelines now require DMARC with at least p=none for any domain sending more than 5,000 messages per day to Gmail accounts. The platform also permanently classifies a domain as a bulk sender once it crosses that threshold even once.

Yahoo applies the same requirement to significant-volume senders. Domains that fail to meet these baselines face throttling, deferred delivery, or outright rejection. Domains with fully aligned, enforced policies benefit from a deliverability premium that compounds over time.

The deliverability difference between aligned and misaligned configurations sharpens considerably at enforcement-level policies. A domain publishing p=quarantine instructs receiving servers to place all unaligned messages in spam. At p=reject, unaligned messages are refused entirely, never reaching any folder, not even junk.

For organizations with complex sending infrastructures, including third-party marketing platforms, CRM systems, and transactional email services, every unauthenticated sender becomes a deliverability liability the moment the policy tightens.

The BIMI Connection: Alignment as a Prerequisite for Brand Logos

Brand Indicators for Message Identification (BIMI) converts DMARC alignment from a backend trust signal into a visible brand asset: a company logo displayed directly in supported inboxes alongside authenticated messages.

The prerequisite is non-negotiable. Domains running p=none cannot display a BIMI logo regardless of how well their SPF and DKIM records are configured. Gmail, Apple Mail, and Yahoo all enforce this requirement.

Beyond the logo, BIMI's certificate verification layer adds a second barrier. A Verified Mark Certificate (VMC) requires a registered trademark, while Gmail's Common Mark Certificate (CMC), introduced in early 2025, accepts proof that the logo has been publicly displayed on the domain for at least 12 months.

A domain must first prove it controls its email authentication before it can prove it controls its brand mark. For marketing and communications teams, alignment quality directly controls whether every transactional email, newsletter, and customer notification carries a visual trust indicator or arrives as an unbranded, indistinguishable line in the inbox.

Protecting Domain Reputation Across Sending and Non-Sending Domains

Parked domains, corporate holding pages, and domains reserved for future use are especially dangerous when left without DMARC alignment. Attackers actively scan for domains with no published DMARC record or with p=none policies, exploiting them to send spoofed email that appears to originate from the organization.

Even if the primary sending domain is properly configured, a forgotten subsidiary domain can be weaponized in a phishing campaign that damages the broader domain reputation.

Every domain an organization owns, sending or not, should publish a DMARC record with p=reject and a null SPF record (v=spf1 -all) to explicitly signal that no email should ever originate from it. This prevents spoofing abuse and stops mailbox providers from associating the brand with malicious traffic before a security team even detects the problem.

For active sending domains, moving from p=none to p=reject is the single highest-impact step an organization can take to lock in deliverability and shut down the most common impersonation vector attackers use against employees, customers, and partners.

Locking down every domain in the portfolio closes the authentication gap that makes phishing simulations and real-world spoofing campaigns so effective in the first place.

DMARC Alignment, Compliance, and Regulatory Requirements

DMARC alignment is no longer a best practice that security teams can defer. It is now an explicit compliance obligation across multiple jurisdictions and industry frameworks.

Regulators have shifted because domain spoofing is a primary delivery mechanism for the phishing attacks that precede nearly every major data breach. Only DMARC with properly aligned SPF and DKIM can block spoofed email at the protocol level before an employee ever sees it.

CISA's Binding Operational Directive 18-01 proved at national scale that mandated DMARC enforcement measurably reduces impersonation risk. Subsequent mandates in the UK, Australia, Canada, and the payments industry have adopted the same logic.

The nuance that compliance teams often miss is that publishing a DMARC record at p=none satisfies the letter of some requirements but fails the intent of every one of them. DMARC enforcement is what turns DMARC from a monitoring tool into a security control.

CISA BOD 18-01 and Government DMARC Mandates

The foundational government mandate is CISA Binding Operational Directive 18-01. Issued in October 2017, it required all federal civilian executive branch agencies to set a DMARC policy of p=reject for every second level domain within one year.

BOD 18-01 explicitly links enforcement to alignment: a domain can only reach p=reject safely when both SPF and DKIM are deployed, configured, and producing passing alignment results for all authorized senders.

In December 2024, CISA BOD 25-01 extended these authentication requirements into cloud service configurations for Microsoft 365 and Google Workspace, reinforcing the same enforcement logic. Federal contractors and private-sector partners exchanging email with .gov domains face the same authentication expectations. Federal mail systems enforce DMARC on inbound messages, and a misaligned domain means rejected mail.

The UK's Minimum Cyber Security Standard requires all central government departments to operate DMARC at p=quarantine or p=reject, with SPF and DKIM configured for every domain. The NCSC's Active Cyber Defence program blocked over 80 million spoofed emails from government domains in a single 30-day period. The Canadian Centre for Cyber Security's ITSP.40.065 provides detailed implementation guidance requiring DMARC enforcement and alignment for all government domains.

Each of these mandates shares the same architecture: publish DMARC, authenticate all legitimate senders, enforce alignment, and progress to p=reject.

PCI DSS v4.0 and Email Security Controls

PCI DSS v4.0.1 introduced Requirement 5.4.1. It mandates that organizations processing cardholder data implement anti phishing mechanisms to protect personnel, business partners, and customers.

While the requirement does not name DMARC explicitly, the PCI Security Standards Council's own Phishing Resource Guide identifies SPF, DKIM, and DMARC as the primary technical controls for email authentication and anti-spoofing.

These requirements became mandatory on March 31, 2025, transitioning from best practice to auditable obligation. For any organization that accepts credit cards, DMARC alignment is now a condition of PCI DSS compliance, and auditors can fail organizations that have not implemented it.

DMARC alignment also supports GDPR compliance indirectly but materially. Domain-spoofed phishing is a leading cause of data breaches that expose personal data. Under GDPR, supervisory authorities can levy penalties up to €20 million or 4% of global annual turnover.

A properly aligned DMARC policy at p=reject prevents attackers from using a domain as a launch point for phishing campaigns targeting customers, employees, and partners. It is a technical control that demonstrably lowers the probability of the data exposure event that GDPR exists to prevent.

How Alignment Evidence Supports Broader Compliance Audits

Neither SOC 2 nor ISO 27001 explicitly mandates DMARC. Both frameworks require auditable technical controls against email-borne threats, and auditors increasingly expect to see DMARC enforcement as evidence that those controls exist.

DMARC's built in reporting infrastructure produces exactly the kind of evidence auditors ask for. Time stamped aggregate reports demonstrate authentication results over time, document policy progression from p=none to p=quarantine to p=reject, and prove that SPF and DKIM alignment is continuously maintained rather than configured once and forgotten.

When an alignment failure surfaces during an audit, the auditor does not see a technical glitch; they see a control gap. Examples include a third party marketing platform's DKIM signature can break after a key rotation, or an SPF record can exceed the 10 DNS lookup limit and silently fail.

The difference between passing and failing often comes down to whether the organization can produce DMARC reports showing that alignment was monitored, exceptions were identified, and corrective action was taken within a defined window.

A domain parked at p=none with no reporting infrastructure provides none of this evidence. A domain at p=reject with archived aggregate reports and documented alignment monitoring satisfies SOC 2's CC6.x logical access controls, ISO 27001:2022's Control 8.8 technical vulnerability management requirements, and the broader expectation that email is treated as a protected information transfer channel.

For organizations subject to any of these mandates, the path forward is the same: publish a DMARC record, authenticate every legitimate sender with SPF and DKIM, monitor aggregate reports to confirm alignment, and progress enforcement to p=reject.

Phishing simulations that test employee response to domain-spoofed attacks become genuinely instructive only when DMARC has already blocked the spoofed messages that technology can stop. What remains are the threats that only trained human judgment can catch.

Advanced DMARC Alignment Scenarios

Getting DMARC to enforce correctly on a single domain with one or two sending services is a manageable project. The challenge intensifies when organizations contend with mailing list forwarding that breaks SPF, dozens of subdomains managed by different teams, and attackers who sidestep DMARC entirely by registering lookalike domains.

These scenarios define the difference between a DMARC alignment configuration that looks correct on paper and one that actually protects the organization in production.

ARC and Mailing Lists: Preserving Alignment Across Forwarding Hops

Email forwarding and mailing lists are the most common silent killers of DMARC alignment. When a message passes through an intermediary, a Google Group, a university alumni forwarder, a corporate mailing list, the original sending IP changes, which breaks SPF. If the intermediary modifies the message body or subject line, DKIM signatures also fail.

The result: a legitimate email that passed authentication at its origin now fails DMARC at the final receiver and gets quarantined or rejected.

The Authenticated Received Chain (ARC) protocol, defined in RFC 8617, addresses this by creating a verifiable chain of custody across forwarding hops. Each ARC-aware intermediary adds three headers to the message: an ARC-Authentication-Results header recording the SPF, DKIM, and DMARC results as evaluated at that hop; an ARC-Message-Signature that cryptographically signs the message state; and an ARC-Seal that covers all previous ARC headers, creating the chain.

The cv= (chain validation) tag in each ARC-Seal tells the next hop whether the preceding chain was intact: cv=none at the first hop, then cv=pass or cv=fail at each subsequent intermediary.

For the domain owner, the alignment implication is straightforward but consequential. When a message fails SPF at the final receiver but carries a valid ARC chain showing that authentication passed at the original entry point, the receiver may override the DMARC failure and deliver the message.

Domains that deployed ARC at major forwarders reduced DMARC failures on forwarded mail by a median of 52% across Gmail and 31% across Outlook, according to a 2025 DMARC Report analysis. This override is not guaranteed. It depends on whether the receiver trusts the ARC sealers in the chain.

Trusted sealer configuration differs across major mailbox providers. Gmail and Google Workspace allow administrators to designate trusted ARC sealers in the Admin Console under Gmail authentication settings, and Google automatically trusts ARC chains from well-known intermediaries.

Microsoft 365 validates incoming ARC chains and supports trusted sealer configuration via the Defender portal or PowerShell (Set-ArcConfig), which is critical if a third-party security gateway processes mail before delivery to Exchange Online.

Yahoo trusts ARC chains from recognized intermediaries automatically but provides less granular administrative control over the trusted sealer list. Organizations that route email through third-party gateways must verify that their gateway adds ARC headers and that the receiving mailbox provider's trusted sealer configuration includes that gateway, otherwise valid forwarded mail will silently fail DMARC.

Enterprise-Scale Alignment: Managing Subdomains and Hundreds of Senders

Large organizations rarely send email from a single domain. Marketing operates from a subdomain with an email service provider. HR uses a different subdomain for an applicant tracking system. Support runs through a helpdesk platform. Developers spin up transactional email from yet another subdomain.

Each third-party sender has a different level of SPF and DKIM alignment capability, and some legacy services cannot achieve strict alignment at all. These enterprise email security realities are exactly why alignment strategy has to scale with the sending footprint, not just the primary domain.

The first step toward enterprise-scale DMARC alignment is a complete inventory of every domain and subdomain that sends email, including those the security team does not know about. DMARC aggregate reports provide this visibility by surfacing every source observed sending mail on behalf of the organization's domains.

Each sending source must then be tagged by alignment capability: fully aligned (both SPF and DKIM pass), partially aligned (one mechanism passes), or incapable of alignment. This inventory becomes the basis for a phased enforcement roadmap.

Subdomain-level DMARC policies are the primary risk-isolation mechanism during this rollout. An organization can publish p=reject on the organizational domain while maintaining p=none on specific subdomains still being brought into alignment.

This is achieved by publishing a separate DMARC record at the subdomain level, for example, _dmarc.marketing.example.com with its own policy, which overrides the organizational domain's policy for that subdomain. The sp= (subdomain policy) tag in the organizational DMARC record can set a default policy for all subdomains, but explicit subdomain-level records take precedence and provide the fine-grained control enterprises need.

Parked and non-sending domains deserve a specific, non-negotiable approach: publish p=reject with an empty SPF record (v=spf1 -all) from day one. Attackers actively scan for registered-but-unused domains because they are trivial to spoof and rarely monitored.

A domain that never sends legitimate email should reject every message that claims to come from it, no monitoring phase, no gradual rollout. This eliminates an entire class of impersonation attacks before they can begin.

Beyond DMARC: Lookalike Domains and the Limits of Alignment

DMARC alignment at p=reject on the primary domain prevents exact-domain impersonation: an attacker cannot send mail that appears to come from @companydomain.com to a recipient whose mailbox provider checks DMARC. That is a meaningful defense, but it has a hard boundary.

DMARC does nothing to stop an attacker who registers @companyname.co (a different TLD) or a domain using an “rn” that looks like an “m,” and sends phishing mail from that domain. In 2024, over 30,000 lookalike domains were identified impersonating major global brands, and a third of those were confirmed as actively malicious.

Homoglyph and lookalike-domain attacks exploit the visual similarity between characters across scripts, a Cyrillic “а” replacing a Latin “a,” for instance, to create domains that pass casual inspection. These domains sit outside the organization's DMARC policy entirely.

The receiving mailbox provider sees a different domain with its own authentication posture, which may be perfectly valid. The email passes SPF, DKIM, and DMARC checks for the attacker's lookalike domain, and the recipient sees what appears to be a familiar sender.

Closing this gap requires defenses that operate beyond the DMARC protocol. Defensive domain registrations, purchasing common misspellings, alternative TLDs, and homoglyph variants of the primary domain, prevent attackers from registering those domains in the first place.

Brand monitoring services scan domain registrations for newly created lookalikes and alert security teams before they are weaponized. Some organizations deploy phishing simulations that specifically test whether employees can distinguish legitimate domains from lookalike variants under pressure.

The gap between what DMARC secures and what attackers exploit is not a protocol flaw; it is a design boundary that every security team must address with defensive layers DMARC was never intended to provide.

Where Email Authentication Meets the Human Layer

Infosecurity Magazine reported that EasyDMARC's 2025 analysis found the percentage of phishing emails accepted in the US fell from 68.8% in 2023 to just 14.2% in 2025, driven by widespread DMARC enforcement mandates.

DMARC alignment prevents domain-spoofed phishing from ever reaching employee inboxes by ensuring impersonation attempts fail authentication at the mail server level. Despite this dramatic reduction, DMARC cannot address threats originating from lookalike domains, compromised vendor accounts, or social engineering through channels like SMS, voice, and LinkedIn, which operate entirely outside the email authentication framework.

This is precisely where the human layer becomes the critical compensating control: when technical defenses shrink the phishing surface, security awareness training shifts from broad-stroke vigilance to precision detection of the specific threats that bypass authentication.

How DMARC Reduces the Phishing Surface Employees Face

When an organization deploys DMARC at enforcement level, p=quarantine or p=reject, receiving mail servers authenticate every inbound message claiming to originate from that domain. If SPF or DKIM alignment fails, the message is either quarantined or blocked outright, never reaching the employee.

The practical consequence is measurable: employees encounter fewer convincing phishing emails that appear to come from colleagues, executives, or internal systems because the attack vector itself is closed.

A DMARCguard analysis of 5.5 million domains in February 2026 found only 12.8% enforce DMARC policies that actively block spoofing, meaning the vast majority of organizations still leave this door open. For organizations that do enforce DMARC, domain impersonation becomes technically nonviable.

That matters because domain impersonation is the most psychologically potent form of email phishing. It exploits internal trust signals to bypass skepticism. This shifts the threat model: instead of employees needing to scrutinize every internal-looking email for signs of forgery, they encounter far fewer such messages and can direct their attention to the more nuanced threats DMARC was never designed to stop.

The residual phishing surface includes attacks from domains that look similar to the organization's own, a technique called typosquatting, as well as compromised third-party accounts from partners, vendors, and SaaS platforms whose emails pass authentication because they genuinely originate from legitimate infrastructure. These are the threats that demand trained human judgment.

Building Employee Understanding of Email Authentication Signals

Security awareness programs rarely teach employees what DMARC, SPF, and DKIM mean in practice. Yet understanding these signals builds a more sophisticated mental model of email trust.

When employees know their organization enforces DMARC, they can reason differently about internal email: a message appearing to come from their own domain that arrives in their inbox has passed authentication and is genuinely internal. Conversely, an email that claims to be internal but triggers anomalies warrants immediate scrutiny.

An unusual sender name paired with a familiar domain, an unexpected request that bypasses normal approval channels, or authentication headers that visibly signal a mismatch, all point to fraud.

This shifts employee behavior from a binary “trust or do not trust” heuristic to a contextual evaluation. An employee who understands that their organization's DMARC policy blocks unauthorized use of its domain becomes less likely to fall for a cyberattacker claiming to be the CEO from a Gmail address or a lookalike domain. They recognize that a message claiming to be internal but arriving from an unauthenticated source does not add up.

They recognize the discontinuity. The training objective is not to turn every employee into an email authentication analyst but to instill the recognition that authenticated internal email and unauthenticated external email carry fundamentally different trust properties.

Integrating Authentication Data into Security Awareness Programs

Organizations with mature DMARC enforcement gain access to aggregate authentication data: reports that reveal which external sources are sending email on their behalf, which messages are failing authentication, and where misconfigurations exist.

This data has a direct application in security awareness training. It provides real-world intelligence on the specific impersonation attempts, lookalike domains, and vendor-spoofing campaigns actively targeting the organization.

Rather than running generic phishing simulations based on hypothetical scenarios, security teams can build training modules that mirror the actual attack patterns appearing in DMARC aggregate reports. If authentication data shows a spike in lookalike-domain phishing impersonating the finance department, the next simulation round can replicate that exact tactic.

This creates a feedback loop where technical controls inform human readiness and human readiness closes gaps technical controls cannot cover. Employees trained on threats that have already targeted their organization develop recognition patterns grounded in real exposure rather than abstract risk.

That feedback loop turns email authentication from a standalone technical control into an intelligence feed that continuously sharpens employee judgment against the threats that slip past it. Security teams that want a structured starting point can look at running phishing simulations that mirror the exact tactics surfaced in DMARC reporting data.

Frequently Asked Questions About DMARC Alignment

Can an email pass SPF and DKIM but still fail DMARC alignment?

Yes, an email can pass both SPF authentication and DKIM signature verification yet still fail DMARC. DMARC requires domain alignment: the domain authenticated by SPF (the Return-Path) or DKIM (the d= signing domain) must match the domain in the visible From header, as specified in RFC 9989.

This is the most common source of DMARC diagnostic confusion. A frequent scenario: a third-party email platform sends with a brand's domain in the From header but authenticates SPF against its own Return-Path and signs DKIM with its own d= domain.

Both checks pass independently, but DMARC fails because neither authenticated domain matches. The fix requires configuring the sending service with a custom Return-Path and DKIM key aligned to the domain. Without alignment, DMARC cannot distinguish between legitimate email and a spoofed message that passes SPF and DKIM using an attacker-controlled domain.

What is the default DMARC alignment mode for aspf and adkim tags?

The default alignment mode for both the aspf (SPF alignment) and adkim (DKIM alignment) tags is relaxed (r). Per RFC 9989, when these tags are omitted from a DMARC DNS record, receiving mail servers apply relaxed alignment for both authentication paths.

In relaxed mode, the authenticated domain must share the same organizational domain as the header From domain, meaning subdomains are permitted to match their parent. For example, mail.example.com aligns with example.com under relaxed mode but would fail under strict because the domains are not an exact match.

This default exists because relaxed alignment accommodates the widest range of legitimate sending configurations, including third-party services that send from organizational subdomains. Most organizations operating without explicit aspf and adkim tags are effectively running relaxed alignment on both paths.

How does email forwarding affect DMARC alignment?

Email forwarding disrupts DMARC alignment primarily by breaking SPF. When a forwarding server relays a message, it rewrites the Return-Path to its own domain, either through the Sender Rewriting Scheme (SRS) or by substituting its own address. The Return-Path domain no longer matches the original sender's domain, so SPF alignment against the header From fails at the forwarding hop.

DKIM alignment may survive if the forwarding server does not modify the message body or signed headers, but many forwarders add footers or alter subject lines, invalidating the signature.

If both SPF and DKIM alignment break, the receiving provider applies the original domain's DMARC policy, potentially quarantining or rejecting the message. The Authenticated Received Chain (ARC) protocol preserves authentication results across forwarding hops, but ARC adoption remains inconsistent across major mailbox providers.

Does DMARC alignment affect email deliverability?

Yes, DMARC alignment directly affects email deliverability. Major mailbox providers including Gmail, Yahoo, and Microsoft use DMARC alignment as a trust signal in their spam-filtering and inbox-placement algorithms.

Misaligned email faces higher spam-folder placement rates and, when the sending domain publishes a p=quarantine or p=reject policy, outright rejection. Starting in February 2024, Gmail and Yahoo mandated DMARC authentication for bulk senders exceeding 5,000 messages per day, making alignment a de facto deliverability requirement.

According to the Validity Email Deliverability Benchmark Report, global average inbox placement rose to 87.2% in 2025, a year over year improvement, while Gmail specifically reached 89.8%, underscoring the deliverability upside of proper authentication. Additionally, BIMI requires DMARC enforcement with passing alignment to display brand logos in supported inboxes, so alignment quality directly enables brand visibility alongside inbox placement.

Can strict and relaxed DMARC alignment modes be switched after initial setup?

Yes, an organization can switch between strict and relaxed DMARC alignment modes at any time by updating the aspf and adkim tags in the DMARC DNS record. The change takes effect as soon as DNS propagates, with no registration or waiting period required.

However, transitioning from relaxed to strict requires careful auditing because legitimate third-party email that passed under relaxed mode may fail under strict when subdomain-to-parent-domain matching is no longer permitted.

The recommended approach: operate at p=none with strict alignment temporarily, monitor aggregate reports to identify failures, resolve misalignment with sending services, and only then tighten to p=quarantine or p=reject.

Once alignment is configured correctly, the remaining risk shifts to threats that bypass email authentication entirely: lookalike domains, compromised accounts, and social engineering through channels DMARC does not cover.

See How Adaptive Reduces Phishing Risk Across the Organization

Even with perfect DMARC alignment, phishing emails from lookalike domains, compromised vendor accounts, and non-email channels like SMS and voice still reach employees. Adaptive Security layers AI-powered security awareness training and phishing simulations on top of email authentication defenses to prepare employees for the threats DMARC cannot stop.

Take a self-guided tour of the Adaptive platform to see how it works in an organization's environment.