SPF and DKIM can both show “pass” in a message header while DMARC still fails. The missing piece is alignment: the domain authenticated by SPF or DKIM must match the domain readers see in the message’s From: header, either exactly or at the organizational-domain level depending on your policy.
That distinction matters when a website, CRM, email platform, ticketing system, and payment processor all send mail for the same organization. A sender can be legitimate, and its message can be cryptographically signed, yet the visible sender identity can still be disconnected from the authentication result. The fix is not another generic DNS checklist. It is a message-by-message inventory and validation process.
What DMARC alignment actually checks
SPF authenticates a domain associated with the SMTP envelope, often called the return-path or MAIL FROM domain. DKIM authenticates the domain in the signature’s d= value. Those domains are not necessarily the same as the visible From: address.
DMARC compares those identities. A message passes DMARC when at least one authenticated result is aligned with the domain in the visible From: header. In relaxed alignment, the domains can share the same organizational domain. In strict alignment, they must match exactly. A valid DKIM signature from a vendor domain does not automatically authenticate your organization’s visible sender domain.
For example, imagine a campaign that displays updates@example.org in the inbox. The email platform may sign the message with d=vendor-mail.example and use bounces.vendor-mail.example for SPF. Both mechanisms can pass, but neither is aligned with example.org. DMARC can therefore fail even though the message came from an approved vendor.
The standards define this as identifier alignment, not as a general judgment about whether a vendor is trustworthy. That is why “SPF passed” or “DKIM passed” is not enough evidence by itself. See the DMARC specification for the alignment model.
Why approved senders still produce alignment failures
Most alignment failures come from the way a sender is configured, not from an attacker. Common causes include:
- The platform is allowed in SPF, but its envelope domain is still owned by the platform.
- The platform signs with DKIM, but the signing domain is a vendor domain instead of a domain your organization controls.
- The visible
From:address uses a subdomain while strict alignment expects an exact match. - A new sending stream, such as receipts or support mail, was added without being included in the domain inventory.
- A forwarding or mailing-list path changes the message, so its authentication results no longer reflect the original delivery path.
- Different environments use different sender domains, and only the production path was configured.
These issues are easy to miss because a normal test often checks only whether the message arrived. A better test asks which system sent it, what the recipient saw, which domains SPF and DKIM authenticated, and whether either result aligned with the visible sender.
Build a sender inventory before changing DNS
Start with a table that treats every sending path as a system dependency. Include the website, marketing platform, CRM, support desk, e-commerce or donation system, calendar or event tool, application server, and any employee-facing relay.
For each stream, record:
- Business purpose and message type
- Sending platform and technical owner
- Visible
From:domain - Envelope or return-path domain used for SPF
- DKIM signing domain and selector
- Whether SPF alignment, DKIM alignment, or both are expected
- Reply-to behavior, unsubscribe requirements, and forwarding concerns
- How the message will be tested and who reviews the result
This inventory also exposes a governance question: which domains are allowed to represent the organization? A sender can be operationally approved without being allowed to place the organization’s primary domain in the visible From: field. Separating those decisions prevents a platform configuration from becoming an accidental identity policy.
Use the message header as the source of evidence
DNS records tell you what a sender is supposed to do. A received message tells you what actually happened. Send a controlled test from every important stream to a mailbox where you can inspect the full headers.
Look for the authentication results and compare the domains, not just the pass or fail words:
- SPF: Which domain was evaluated, and did it align with the visible
From:domain? - DKIM: Which signature passed, and what domain appeared in its
d=value? - DMARC: Which mechanism, if any, supplied the aligned pass?
- Policy: What DMARC policy was discovered, and what disposition was applied?
- Path: Did the message pass directly, through a forwarder, or through a mailing list?
Keep a sanitized copy of the header evidence with the sender inventory. Do not paste full recipient addresses, message content, or sensitive tokens into a shared issue tracker. The goal is repeatable evidence, not a second uncontrolled store of personal data.
Roll out enforcement as a controlled change
Do not move from an unknown configuration straight to rejection. First publish a monitoring policy and review aggregate reports for every legitimate sender. Google’s current guidance recommends setting up SPF and DKIM before DMARC, monitoring a p=none policy, and then moving toward quarantine for a small percentage after the results are understood. The right timing depends on how many senders you have and how quickly you can investigate reports.
During rollout, group failures by source and identity. A failing vendor stream may need a custom return-path, a customer-domain DKIM setting, a different visible sender, or a decision to use a subdomain. Do not “fix” a report by weakening the policy without understanding which message path generated it.
When a stream is repaired, retest a real message and confirm the result from the recipient side. A DNS change can be correct while a platform continues signing with an old selector or using an unexpected envelope domain.
Common validation mistakes
- Testing only one sender: A newsletter can pass while receipts or password resets fail.
- Checking DNS but not headers: Published records do not prove the platform used them.
- Assuming vendor approval equals alignment: Authorization and identity are related but different decisions.
- Ignoring subdomains: Organizational-domain alignment can behave differently from strict alignment.
- Changing multiple systems at once: Bundled changes make it difficult to identify which sender was repaired.
- Treating reports as a one-time setup task: New tools, acquisitions, website changes, and staff workflows can introduce new mail streams later.
A practical DMARC troubleshooting checklist
For each message type, confirm that you can answer these questions:
- What system sent the message?
- What domain appeared in the visible
From:header? - What domain did SPF authenticate?
- What domain did the passing DKIM signature authenticate?
- Which result aligned with the visible sender?
- What did the receiving system do with the message?
- What evidence proves the fix works after DNS and platform changes?
If any answer is unknown, the sending path is not fully governed yet. Add the missing owner, domain, selector, or test evidence to the inventory before relying on the stream for important operational or marketing communication.
Make authentication part of the sending workflow
DMARC is most useful when it becomes part of normal change management. Add sender review to website launches, marketing-platform migrations, CRM changes, new transactional email features, and vendor onboarding. Require a test message and header review before a new system is allowed to send from an organizational domain.
DigitalWerks can review the sender inventory, authentication evidence, DNS and platform configuration, reporting workflow, and rollout plan as one connected system. Ask DigitalWerks to review your email sending paths before an alignment failure becomes a delivery or identity problem.