How to keep email authentication strong through multiple acquisitions

When the answer changes

The workflow changes according to the evidence available for each acquired domain.

• If the domain does not send mail, record that decision and protect it deliberately. Do not assume an unused-looking domain has no legacy application or forwarding path.
• If a domain sends through one managed tenant, start with the tenant's current authentication evidence and the actual messages it produces.
• If multiple providers send with the same visible From domain, each provider needs its own aligned SPF or DKIM path. Passing mail from one platform does not validate another.
• If an acquired brand must remain separate, maintain a distinct domain inventory, business owner, technical owner, and change record. A shared parent company does not create DMARC alignment between unrelated domains.
• If a domain has a DMARC policy of none, it is requesting monitoring treatment after failure, not proving that all legitimate mail is configured correctly.

CISA's DMARC implementation guidance supports a staged approach: begin by gaining visibility, correct legitimate sources, then move toward stronger policy as the evidence supports it.

A worked acquisition onboarding record

Use one working record per domain, including subdomains that have their own visible From addresses. The following is illustrative only. Do not publish real selectors, provider targets, report addresses, or customer data in a shared tracker.

Domain: acquired-example.com
Business owner: Acquired brand communications lead
Technical owner: Central email security team
Known sending paths: Workspace mail, billing platform, support platform
SPF evidence: Public TXT lookup and evaluated lookup count
DKIM evidence: Selector, signing domain, and delivered-message verification
DMARC evidence: Published policy, aggregate-report destination, alignment results
Message evidence: Redacted Authentication-Results header for each path
Policy decision: Keep p=none until every important path is aligned
Rollback record: Previous DNS value and approved change owner

This record separates configuration from proof. For example, an SPF record can look correct in DNS while a billing provider uses an envelope sender that the record does not cover. Likewise, a provider console can report DKIM configured while a delivered message has no valid signature.

Practical next steps for acquired domains

Start with the evidence that is easiest to obtain, then move toward production evidence.

1. Build the domain and sender inventory

List every acquired root domain, active sending subdomain, and visible From domain. For each, record the business purpose, known sending applications, DNS zone owner, and an accountable owner who can approve mail-flow changes.

Include dormant domains and regional brands. The aim is not to change every domain immediately. It is to make unknown sending paths visible before policy changes affect them.

2. Inspect the public DNS records

Check the exact domain that appears in the message's visible From field. Review the DMARC record at _dmarc.yourdomain.com, the SPF TXT record for the envelope-sending domain, and DKIM selector records supplied by the sending provider.

Use the DMARC checker and DNS lookup tool to inspect public records before comparing them with the intended policy. A public lookup cannot prove the production sending path, continuous state, a receiver's private decision, or future placement.

Do not replace a crowded SPF record with a guessed include chain. A syntax-valid record can still remove authorization for a live sender and interrupt mail.

3. Validate real delivered messages

Send a controlled message through every important production path. Retain redacted headers and inspect the receiver's Authentication-Results field. RFC 8601 defines this field as a receiver's authentication assessment, so record which receiver supplied it and the exact message path it observed.

Confirm four layers independently:

• DNS: query authoritative DNS and at least one public resolver after a change.
• Vendor: confirm the provider's current authentication or domain-verification status.
• Message: inspect a delivered message from the exact production path.
• DMARC: review aggregate-report data after sufficient mail has accumulated.

4. Phase enforcement by domain

Keep a domain at p=none while unresolved sources remain. Once legitimate senders are identified and aligned, establish a documented change, a rollback value, and an observation period before moving to quarantine or reject.

RFC 9989 defines the DMARC policy values, while the receiving system determines final treatment. Stronger policy requests help control spoofed use of the domain, but they do not guarantee inbox placement for legitimate mail.

Continue the acquisition inventory with Palisade

After you have checked the public record, the remaining problem is knowing which production sources across acquired domains still fail alignment as mail changes over time. Palisade is DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets for human review.

Start with Palisade

Palisade does not autonomously change a DMARC policy, prove every future message will authenticate, or control a receiver's delivery decision. A human reviews the evidence and applies any DNS or policy change.