legitimate sender passes spf and dkim but fails dmarc after rebranding to a new root domain

TL;DR

Rebuild authentication under the new domain instead of expecting the old alignment to carry over: publish SPF, DKIM, and DMARC for the new root domain, have every sender sign and send as the new domain, and only then retire or redirect the old domain mail. After a rebrand the From domain changed, so passes recorded against the old domain or a vendor domain no longer align, even though every individual check still says pass.

legitimate sender passes spf and dkim but fails dmarc after rebranding to a new root domain

Use this when

• Mail From the new brand domain shows spf=pass and dkim=pass but dmarc=fail.
• Senders were migrated from the old domain by changing the From address only.
• The new domain DMARC record is missing, copied wrongly, or still at a test state nobody completed.

Not for this skill when

• Mail still From the old domain fails DMARC. That is the old domain own alignment problem.
• The new domain mail fails SPF outright. Authorise its senders first, then alignment.

Steps

1. Inventory every sender that now uses the new From domain, including the quiet ones like billing, monitoring, and the helpdesk tool. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: every new domain sender is listed with its platform
2. For each sender, record which domain its envelope and DKIM signature actually use today. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: the gap between the new From and each sender authenticated domain is explicit
3. Publish the new domain records: SPF includes per sender, DKIM selectors for each platform that signs as the new domain, and a DMARC record with your reporting address. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: external lookups return complete records for the new domain
4. Switch each platform to send and sign as the new domain in production, then send tests to external mailboxes. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: tests from each platform show aligned passes and dmarc=pass for the new domain
5. Watch new domain DMARC reports for two weeks before tightening its policy to reject, and keep the old domain enforced so it cannot be spoofed during the transition. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: reports show sustained alignment and the policy step is recorded

Why it happens

A rebrand changes the one domain DMARC cares about. Organisations migrate the visible From address on day one, while envelope domains, DKIM signing domains, and DNS records still belong to the old brand or to vendors. Each check can pass in isolation and DMARC still fails, which confuses teams who read pass as success. The fix is a full authentication launch on the new domain, run with the same care as the original DMARC project, not a record copy.

Variants and edge cases

passes spf dkim but fails dmarc after rebranding new root domain

The rebrand timing phrasing with the pass but fail pattern.

new domain dmarc fail alignment old domain senders rebrand

The alignment gap variant naming sender migration.

rebranded email authentication setup spf dkim dmarc new domain checklist

The checklist variant teams search before launch day.

Compatibility: RFC 7489 DMARC, RFC 7208 SPF, RFC 6376 DKIM, sender platform custom domain features.

Edge cases to check:

• Keep sending a small volume as the old domain during transition if customers expect it, but authenticate it fully rather than abandoning it.
• Update BIMI, MTA-STS, and TLS-RPT for the new domain as separate follow ups; they do not move with DMARC.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_R9KOzUJjksktxvOjjDBr6A