DMARC Analyzer

TL;DR

• One DMARC record per organizational domain. Every organizational domain - the parent zone under a Public Suffix List entry, per RFC 7489 section 3.2 - needs its own _dmarc TXT record. Subdomains inherit via sp= from the apex; separate organizational domains do NOT.
• Inventory before policy. Operators routinely under-count their own domains by 30-50% on first inventory. WHOIS + CMS asset register + DNS zone enumeration + registrar account audit + acquired-company carve-out audit. Map every domain BEFORE publishing policy.
• Classify every domain. Production sending / marketing subdomain / parked / acquired-company / brand-defensive registration / delegated to third party - each category gets a different rollout cadence and end-state policy.
• Use sp= + np= aggressively. sp=reject (RFC 7489 section 6.3) hardens unused subdomains while the apex is still ramping; np=reject (RFC 9091) hardens NON-EXISTENT subdomains, closing the most common spoofing-of-random-subdomain attack.
• Central RUA reporting. Publish the same rua=mailto:dmarc-rua@example.com on every organizational domain. The policy_published.domain element in the aggregate report XML attributes each report to its source domain - one pipeline for the whole portfolio.
• Park hardening costs nothing. v=spf1 -all + v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:... + null MX (RFC 7505) on every parked domain turns the parked-domain liability into a brand-defensive asset.
• Acquired-company playbook. Inventory -> p=none with reporting -> 14-30 day visibility window -> align legitimate senders -> rollout cadence -> consolidate reporting. Skipping the visibility window is the single most common acquired-company mistake.

1. The multi-domain DMARC problem

Single-domain DMARC playbooks - the typical "publish p=none, watch the reports, move to p=reject" cadence - assume the operator owns ONE domain that sends mail. Real enterprises do not. The median 500-employee company operates 6-12 organizational domains: the primary brand domain, an acquired-company domain that has not yet been migrated, 2-4 marketing landing-page domains, a regional-localized domain (.de, .co.uk, .jp), 1-2 brand-defensive registrations (typosquat-protection), and a handful of parked-but-not-deleted properties from prior rebranding. The Fortune 500 median is 50-200 organizational domains. MSPs managing client portfolios routinely touch thousands.

Each of those domains needs its own _dmarc record, but the right policy is NOT the same. A production-sending domain wants a deliberate none -> quarantine -> reject rollout that depends on per-domain sender inventory. A parked domain wants p=reject from day one because it sends no mail. An acquired-company domain wants a visibility window before policy moves. A brand-defensive typosquat registration wants the same hardening as a parked domain. A delegated-to-third-party domain (an outsourced marketing landing page where a SaaS vendor controls DNS) needs coordination with the third party. One cadence does not fit all.

The portfolio-operator failure mode is uniform: operators rush the production domain to p=reject while parked and acquired domains sit at the implicit no DMARC record state - which means NO DMARC enforcement at the receiver. Attackers target the unprotected domains because they look like the brand but are not behind the strict policy. The portfolio-strategy guide closes that gap: one strategy across the whole portfolio, different per-category tactics within it.

2. Building the domain inventory

Operators routinely under-count their own domain portfolio by 30-50% on first inventory. Six sources, run all of them and reconcile.

2.1 WHOIS lookup against registrar accounts

The registrar account is the authoritative source of registered domains. Export the registrant list from every registrar account the company uses (often more than one: legacy IT migrations leave domains scattered across GoDaddy + Network Solutions + Namecheap + Gandi + corporate-grade MarkMonitor or CSC). Cross-reference against accounts-payable for registrar invoices to catch domains paid for but not in the centralized registrar.

2.2 DNS zone enumeration

For each registrar-listed domain, query the parent nameservers for active DNS records. A domain that has NO records at all is a dormant registration - still owned, still spoofable, needs hardening. A domain with active records is in some operational state.

2.3 Brand and trademark portfolio

The legal team's trademark portfolio names brands that should be defensively registered as domains. A brand without a corresponding registration is typosquat-exposed; that gap is part of the portfolio strategy even if the registration is pending.

2.4 CMS and marketing-asset register

Landing-page CMS instances (Webflow, WordPress multisite, HubSpot, Marketo, Mailchimp), CRM custom-domain configurations, and marketing-team custom-tracking domains routinely use organizational subdomains or entirely separate domains that the IT team did not register. Inventory the marketing-asset register.

2.5 Acquired-company carve-out audit

Mergers and acquisitions ship domains that were owned by the acquired entity. The acquisition documents list the assets transferred. The IT integration team often inherits a domain list without DMARC posture data.

2.6 Outbound mail audit

Inspect the company's sent mail headers for the last 30 days from the corporate gateway. The sender envelope-from domains reveal every domain actually used for production sending - including domains the IT team forgot existed. The DMARC Analyzer header analyzer (includes/EmailHeaderParser.php) surfaces SPF / DKIM / DMARC posture per envelope-from for quick triage.

3. Domain taxonomy - six categories

Every inventoried domain falls into one of six categories. Each category has a different DMARC strategy.

The two largest categories by count are usually "parked" and "brand-defensive registration" - these are also the two categories with the cheapest DMARC hardening because they send no mail. Hardening them is the highest-leverage portfolio-wide win.

4. The organizational domain rule (RFC 7489 §3.2)

RFC 7489 section 3.2 defines the organizational domain as the zone immediately above a Public Suffix List entry. The DMARC lookup algorithm queries _dmarc.<header-from-domain> for a TXT record; if none exists, it falls back to _dmarc.<organizational-domain>. This is the mechanism that makes the apex _dmarc record cover all subdomains.

4.1 Public Suffix List - the canonical reference

The Public Suffix List (PSL) is the authoritative list of effective TLDs maintained by Mozilla and used by every major receiver. For marketing.example.com: .com is the PSL entry; the organizational domain is example.com. For marketing.example.co.uk: .co.uk is a PSL entry; the organizational domain is example.co.uk, NOT co.uk. The DMARC alignment guide (help_dmarc_alignment.php) has the full alignment walk; this page covers the portfolio implication: every organizational domain you own needs its own _dmarc record.

4.2 Worked example: portfolio organizational-domain mapping

A portfolio with these domains:

example.com
shop.example.com
marketing.example.com
example.de
example.co.uk
acquiredco.com
brand-typosquat.io
example-parked.net

Has SIX organizational domains: example.com, example.de, example.co.uk, acquiredco.com, brand-typosquat.io, example-parked.net. The shop. and marketing. subdomains inherit from example.com via sp=. Each of the six organizational domains needs its own _dmarc TXT record.

4.3 Where this trips operators

• ccTLD organizational domain: example.co.uk is the organizational domain, not example.com. A _dmarc.example.com record does NOT cover marketing.example.co.uk - the UK domain needs its own _dmarc.
• Subdomain delegation: if marketing.example.com is delegated to an ESP via NS records, the ESP controls DNS and the apex _dmarc.example.com record still covers the subdomain (the lookup falls back up the tree).
• Government and academic ccTLDs: .ac.uk, .gov.uk, .edu.au are PSL entries; organizational domain is one label below.

5. Subdomain inheritance: sp= and np=

Two tags govern subdomain policy. The sp= tag (RFC 7489 section 6.3) overrides the apex p= for subdomains that EXIST. The np= tag (RFC 9091 section 3.1) overrides for subdomains that do NOT exist.

5.1 The sp= tag - subdomain inheritance override

If sp= is omitted, subdomains inherit the apex p=. If present, the sp= value takes precedence for any subdomain that does not have its OWN _dmarc record. The common deployment pattern during rollout:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; sp=reject; rua=mailto:dmarc-rua@example.com"

Why: the apex is at quarantine because production senders on example.com are still ramping and the operator does not want false-positive rejects. Subdomains - which legitimate senders rarely use without explicit setup - get sp=reject so attackers cannot spoof noreply.example.com or info.example.com or any other unused-but-spoofable subdomain. Once apex senders are clean, raise the apex to p=reject and remove sp= (it then inherits reject from the apex).

5.2 The np= tag - non-existent subdomain policy (RFC 9091)

RFC 9091 (published July 2021) added the np= tag for NON-EXISTENT subdomains. Without np=, some receivers do not apply the apex sp= to truly non-existent subdomains - attackers can send from xfgr.example.com that has zero DNS records and slip through because the receiver does not have an unambiguous policy lookup. Set np=reject to close that gap:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc-rua@example.com"

For portfolio operators, np=reject is the cheapest portfolio-wide hardening - publish it alongside p= and sp= on every organizational domain, even on parked domains where it costs nothing and prevents the most common spoofing pattern. As of 2026, receiver support for np= is implemented by Google, Microsoft 365, Yahoo, Proofpoint, Mimecast, and the major receiver platforms.

5.3 Per-subdomain override

Any subdomain can publish its OWN _dmarc.<subdomain>.<example.com> record to override the inherited policy. This is the pattern for a single subdomain that needs a different cadence: marketing.example.com at p=none for visibility while example.com apex is at p=reject - publish _dmarc.marketing.example.com explicitly. The per-subdomain record wins over inherited sp=.

6. Per-category policy strategy

6.1 Production sending domains

Follow the canonical single-domain rollout playbook (see DMARC policy rollout): none -> quarantine (with pct= ramp) -> reject. Use sp=reject during the quarantine phase so unused subdomains are hardened immediately. Final state: p=reject; sp=reject; np=reject.

6.2 Marketing subdomains

Most marketing subdomains inherit from the parent organizational domain. The exceptions are subdomains delegated to an ESP via NS records where the ESP-managed DNS does not include a per-subdomain _dmarc record - the parent's _dmarc still applies via the organizational-domain lookup. Verify by querying _dmarc.<marketing-subdomain> directly; if it returns NODATA, the parent apex's policy applies.

6.3 Parked domains

One-shot hardening from day one. See section 9 for the canonical pattern.

6.4 Acquired company domains

Visibility-first playbook. See section 8 for the canonical 6-step integration sequence.

6.5 Brand-defensive registrations

Treat as parked. The defensive registration was made to prevent a typosquat attacker from owning the domain; hardening it with p=reject + sp=reject + np=reject + null SPF + null MX closes the spoofing vector even if the brand never uses the domain. Add the registration to the central RUA pipeline to detect spoofing attempts.

6.6 Delegated-to-third-party domains

The third party controls DNS, which means they control the _dmarc record. Coordination required: include DMARC posture as a contract requirement and verify quarterly. If the third party cannot publish p=reject, reclaim DNS control.

7. Reporting consolidation - one central RUA

Publish the same rua=mailto:dmarc-rua@example.com on every organizational domain you own. RFC 7489 section 7.1 explicitly supports a single reporting endpoint across many domains - the aggregate report XML carries a policy_published.domain element so the receiver can attribute each report to its source domain.

7.1 The internal-domain shortcut

When the rua= mailto address shares an organizational domain with the reporting domain (e.g. example.com publishes rua=mailto:dmarc-rua@example.com), no special authorization is needed. The receiver sends reports directly.

7.2 The external-domain authorization (RFC 7489 §7.1)

When the rua= address is on a DIFFERENT organizational domain (e.g. example.com publishes rua=mailto:reports@third-party-analyzer.io), the destination domain MUST publish an authorization record:

example.com._report._dmarc.third-party-analyzer.io.  IN  TXT  "v=DMARC1"

Without this authorization record, RFC 7489 compliant receivers refuse to send reports to the external domain (preventing reflection-DoS abuse). For portfolio operators using a third-party DMARC analyzer service, this means EACH of your organizational domains needs an authorization record at the analyzer's domain.

7.3 The DMARC Analyzer reference pipeline

The project ingests aggregate reports for any number of domains under one user account via includes/DmarcParser.php; the forensic-report parser includes/ForensicReportParser.php handles ruf= reports the same way. The dashboard groups by reported domain so the source of each report is unambiguous across the portfolio. The IMAP fetcher (includes/ImapFetcher.php) and Microsoft Graph fetcher (includes/GraphFetcher.php) automate report ingestion from a single monitoring mailbox - one mailbox for the entire portfolio.

7.4 RUA volume scaling

A 100-domain portfolio receives 100-300 aggregate reports per day (each receiver sends one report per source domain per 24h). At 500-1500 domains the rate scales to 1500-5000 reports per day - inbox quota becomes a concern. Best practice: dedicated monitoring mailbox with at-least-100GB quota and a parser with periodic ingestion + delete (the project's IMAP fetcher implements this).

8. Acquired-company integration playbook

Acquired-company domains are the highest-risk portfolio category because the IT team inherits domains without knowing the senders. Skip the visibility window and your first p=reject will reject legitimate mail you did not know existed. The canonical 6-step sequence:

1. Inventory the acquired domain DNS state. Document existing SPF, DKIM selectors, DMARC record (if any), MX, A/AAAA, mail-related TXT. Use the Domain Security Checker (anchored against includes/DnsChecker.php) for the snapshot.
2. Publish p=none with reporting. If no DMARC record exists, publish v=DMARC1; p=none; rua=mailto:dmarc-rua@<your-central-domain>. If the acquired company's rua= already points elsewhere, ADD your address as a second comma-separated destination so reporting flows to BOTH the legacy and your central pipeline during the transition.
3. Wait 14-30 days collecting reports. The aggregate reports map every legitimate sender the acquired company uses - including legacy SaaS the new IT team does not know about (a recurring discovery is long-forgotten payroll systems, expense-report tools, marketing-automation accounts).
4. Align legitimate senders. Add the discovered senders to the acquired-domain SPF, configure DKIM at each sender, verify alignment via test sends.
5. Move to p=quarantine then p=reject. Follow the canonical single-domain rollout cadence (DMARC policy rollout). Add sp=reject; np=reject in the same record.
6. Consolidate reporting. Once the acquired domain reaches p=reject, remove the legacy rua= destination, keeping only your central pipeline. The acquired domain is now a fully-integrated portfolio member.

Common mistake: jumping from step 1 directly to step 5 because "we know what senders the company uses". Aggregate reports always reveal additional senders - skip the visibility window and the first p=quarantine will quarantine legitimate mail.

9. Parked domain hardening - the null-SPF + reject-DMARC pattern

Parked domains send no mail by definition but are the most attractive spoofing targets because they look like the brand. The canonical hardening pattern costs nothing and prevents the most common attack vector.

9.1 The four records

; SPF - authorize zero senders
example-parked.com.  IN  TXT  "v=spf1 -all"

; DMARC - reject everything, report to central pipeline
_dmarc.example-parked.com.  IN  TXT  "v=DMARC1; p=reject; sp=reject; np=reject; adkim=s; aspf=s; rua=mailto:dmarc-rua@example.com"

; Null MX (RFC 7505) - declare the domain accepts no mail
example-parked.com.  IN  MX  0 .

; Optional - DKIM with empty key (defensive)
*._domainkey.example-parked.com.  IN  TXT  "v=DKIM1; p="

9.2 What each record does

• SPF -all: any IP claiming to send from the parked domain FAILS SPF. The -all is hard-fail (not ~all softfail) because no legitimate sender exists.
• DMARC p=reject; sp=reject; np=reject: receivers reject any mail from the parked domain. Apex, existing subdomains, and non-existent subdomains all covered.
• adkim=s; aspf=s: strict alignment - even if an attacker somehow gets SPF or DKIM to pass via a relaxed-alignment trick, the strict alignment will catch it.
• rua=mailto:: you SEE the spoofing attempts. Parked-domain RUA reports are often the first detection signal for active brand-impersonation campaigns.
• Null MX (RFC 7505): the single MX of priority 0 pointing to . declares the domain accepts no mail. Sending MTAs see this and never even attempt delivery.
• Empty DKIM wildcard: a wildcard DKIM record with empty p= revokes any selector the attacker might try; defense in depth.

9.3 Portfolio-wide automation

For a 100+ domain portfolio, automate the hardening via Terraform / Pulumi / API DNS management. The four-record bundle is identical across all parked domains except for the domain label - a templated apply across the portfolio is a single PR. The DNS Record Generator builds syntactically-correct DMARC + SPF + null MX records for one-shot copy-paste deployment.

10. Common multi-domain mistakes

• Hardening only the production domain. Production at p=reject + parked and acquired domains at no-DMARC = attackers pivot to the unprotected domains. Inventory and harden every organizational domain in the portfolio, not just the flagship.
• Forgetting the ccTLD organizational domain. example.co.uk is its OWN organizational domain; _dmarc.example.com does NOT cover it. Each ccTLD registration needs its own _dmarc record.
• Skipping the acquired-company visibility window. Jumping from acquisition to p=quarantine without 14-30 days of aggregate-report visibility quarantines legitimate mail you did not know existed. Always run the visibility window.
• Reusing a DKIM key across organizational domains. DKIM signatures are bound to the d= tag domain; receivers query <selector>._domainkey.<d-domain>. You cannot share a key across example.com and example.net. Each organizational domain needs its own selector + key.
• Missing the external-domain authorization record. Using a third-party DMARC analyzer service: each of your organizational domains needs a <your-domain>._report._dmarc.<analyzer-domain> TXT record. Without it, RFC 7489 compliant receivers refuse to send reports to the external analyzer.
• Omitting np=. Without np=reject, attackers send from non-existent subdomains and slip past the apex sp=. RFC 9091 np= support is widespread among major receivers in 2026; set it on every organizational domain.
• Treating brand-defensive registrations as low-priority. They are EXACTLY the registrations attackers would target if uncontested. Same hardening as parked domains - one-shot p=reject from day of registration.
• No central reporting inventory. Aggregate reports flow to multiple addresses, no single dashboard, no portfolio view. Consolidate into one rua= address on every organizational domain.

11. Troubleshooting common multi-domain issues

11.1 "Our acquired-company domain is sending mail but I see no aggregate reports"

• Verify the acquired domain has a _dmarc record published. Many acquired companies have no DMARC record at all, which means no reports.
• If the record exists, verify the rua= destination is on YOUR organizational domain OR has the _report._dmarc authorization record at your domain.
• Wait 24-48h after publishing - receivers batch reports daily.

11.2 "A subdomain I did not configure DMARC for is showing up as a spoofing target"

• Verify the apex has sp=reject or p=reject (which is inherited if sp= omitted).
• If the subdomain is NON-existent, verify np=reject is published on the apex.
• Confirm the receiver supports np= (Google, Microsoft 365, Yahoo, Proofpoint, Mimecast all do as of 2026).

11.3 "Receiver refuses to send aggregate reports to our third-party DMARC analyzer"

• Add the external-domain authorization record at the analyzer's domain: <your-domain>._report._dmarc.<analyzer> IN TXT "v=DMARC1". Without it, RFC 7489 compliant receivers refuse.
• One authorization record PER organizational domain in your portfolio that uses the analyzer.

11.4 "Different domains in our portfolio get different DMARC pass rates - why?"

• Different senders. Each organizational domain has its own set of legitimate senders; alignment and DKIM coverage vary per-domain.
• Check per-domain in the dashboard - the DMARC Analyzer dashboard groups aggregate reports by reported domain so per-domain pass-rate trends are visible.
• Investigate the lowest-pass-rate domain first - it has the most operational gap.

11.5 "An acquired domain hit p=reject and now legitimate mail is bouncing"

• The visibility window was insufficient. Move the apex back to p=quarantine immediately - this is reversible with a TTL-bounded propagation window.
• Inspect the aggregate reports for the failing source IPs - they are the senders that were missed during the visibility phase.
• Add the missing senders to SPF + DKIM, verify alignment, then re-attempt p=reject.

12. Frequently asked questions

Do I need a separate DMARC record for every domain I own?

Yes. DMARC is published per organizational domain. Every organizational domain that sends or could send mail needs its own _dmarc TXT record. Subdomains inherit the parent organizational domain policy via the sp= subdomain inheritance tag, but separate organizational domains - example.net, acquiredcompany.com, brand-defensive-registration.io - each need their own _dmarc record.

What is the sp= tag and how does subdomain inheritance work?

The sp= tag specifies the DMARC policy for subdomains separately from the apex domain. If sp= is omitted, subdomains inherit p= from the apex. The common pattern during rollout is p=quarantine sp=reject: apex at quarantine because production senders are ramping, subdomains get the stricter reject so attackers cannot spoof unused subdomains.

What is the np= tag and why does it matter for multi-domain operators?

The np= tag (RFC 9091) specifies the DMARC policy for NON-EXISTENT subdomains. Without np=, attackers can send mail from random-named subdomains that have no DNS footprint and slip through. np=reject closes that gap and is the cheapest portfolio-wide hardening.

How do I consolidate DMARC reporting for many domains into one pipeline?

Publish the same rua= mailto address on every organizational domain. The aggregate report XML carries policy_published.domain so each report is attributable. For external analyzer destinations, publish a domain._report._dmarc.analyzer authorization record per organizational domain.

What should I do with parked domains that send no mail?

Apply the null-SPF + p=reject + sp=reject + np=reject hardening pattern. v=spf1 -all, v=DMARC1; p=reject; sp=reject; np=reject; rua=, plus null MX (RFC 7505). Costs nothing and prevents the most common brand-impersonation attack vector.

How do I handle DMARC for a newly acquired company domain?

Use the 6-step acquired-company playbook: inventory, publish p=none with central reporting, 14-30 day visibility window, align legitimate senders, move to p=quarantine then p=reject, consolidate reporting. The visibility window is the most commonly skipped step and the most common cause of false-positive rejects.

Why does my DMARC report show records for a domain I did not register?

Two common causes. An attacker is spoofing a look-alike domain (typosquat) and your aggregate reports surface failure attempts from neighbouring zones. Or a receiver attributed a report to your address by mistake; verify by checking policy_published.domain in the report XML against domains you actually own.

Can I use the same DKIM key across multiple domains?

No. DKIM signatures are bound to the d= tag domain. Receivers query selector._domainkey.d-domain so you cannot share a key across example.com and example.net. You CAN reuse a key across subdomains of one organizational domain (mail.example.com signs with d=example.com) but cross-organizational-domain sharing is prevented by the DKIM record location semantics.

13. Related guides

• DMARC primer (help hub) - the DMARC-specific pillar covering the single-domain rollout fundamentals this guide scales to the portfolio.
• DMARC record tags explained - tag-by-tag reference for every DMARC tag including sp= and np=.
• DMARC alignment explained - the organizational-domain and Public Suffix List walkthrough the portfolio strategy depends on.
• DKIM DNS TXT-record byte syntax (RFC 6376 §3.6.1 tag-list grammar) — the PORTFOLIO-WIDE-PER-MEMBER-DKIM-TXT- RECORD-BYTE-LEVEL-AUTHORING-UNIFORMITY companion to this multi-domain DMARC strategy. Where THIS page documents the portfolio-coordination architecture across N portfolio members (single-org-many-brands / many-org / parked-domain / acquired-domain patterns), the DKIM-DNS-syntax spoke documents the PUBLISHER-SIDE TXT-RECORD BYTE-LEVEL AUTHORING REFERENCE whose UNIFORM per-portfolio-member byte-correct publication is the LOAD-BEARING UPSTREAM PRECONDITION every per-portfolio-member multi-brand DMARC-policy coordination THIS page documents structurally depends on. The PORTFOLIO-WIDE- PER-MEMBER-DKIM-TXT-RECORD-VS-MULTI-DOMAIN- COORDINATION cross-reference establishes FOUR structurally-distinct per-portfolio- member-DKIM-TXT-record-tag-to-multi-domain- coordination-dimension coupling dimensions: (i) UNIFORM RFC 8301 §3 RSA-2048 minimum p= public-key-strength publication across N portfolio members as load-bearing portfolio-wide multi-brand DMARC-enforcement coordination prerequisite — a multi-domain portfolio where ONE portfolio member still publishes pre-2018 1024-bit RSA p= public-key material on its selectors produces per- portfolio-member DIVERGENT DKIM-aligned-pass- rate distributions at modern Microsoft / Google / Yahoo receivers (the 1024-bit- publishing member collapses to dkim=fail while the 2048-bit- publishing members produce dkim=pass) — denying the multi-domain strategy this page documents the UNIFORM per-portfolio-member cohort DKIM-aligned-pass-rate floor every portfolio-wide p=reject coordination structurally requires; the DKIM-DNS-syntax spoke documents the RFC 8301 §3 RSA-2048 floor as the canonical UNIFORM per-portfolio-member publishing discipline whose enforcement is the multi-domain coordination prerequisite; (ii) UNIFORM byte-correct v=DKIM1 version-prefix + p= base64- encoded public-key-material publication across N portfolio members as load-bearing parked-domain-selector-absence-vs-active- domain-selector-presence DISCIPLINE — the portfolio-coordination architecture's parked-domain posture this page documents REQUIRES the parked domain to have ZERO selectors published (allowing the per- receiver receiver-side DKIM evaluation to return dkim=none) WHILE the active portfolio members publish byte-correct DKIM TXT records with non-empty p= tags; a parked domain that accidentally inherited a defunct selector TXT record with empty p= tag produces dkim=permerror (key syntax) at every receiver, denying the parked- domain posture this page documents; the DKIM-DNS-syntax spoke documents the canonical empty-p= revocation semantics vs. record-absence semantics as the publisher-side authoring discipline whose correct execution distinguishes the parked-domain posture from the defunct- selector defect class; (iii) UNIFORM multi-string TXT chunking discipline per RFC 1035 §3.3.14 across N portfolio members as load-bearing portfolio-wide 2048-bit-RSA-publication-correctness prerequisite — selectors publishing 2048-bit RSA p= public-key material exceeding the 255-octet per-TXT- character-string boundary WITHOUT correct multi-string chunking produce dkim=permerror (key syntax) at every receiver — a per-portfolio-member publication-discipline defect that breaks the UNIFORM per-portfolio-member cohort DKIM-aligned-pass-rate baseline the multi- domain coordination this page documents depends on; the DKIM-DNS-syntax spoke documents the multi-string chunking discipline as the canonical publisher-side publication discipline whose UNIFORM per-portfolio-member enforcement is the portfolio-wide 2048-bit-RSA-publication- correctness prerequisite; (iv) STRICT prohibition of stale t=y testing-flag past the 24-72h burn-in window across ALL portfolio members as load-bearing per-portfolio-member burn-in-cleanup DISCIPLINE — a multi-domain portfolio where ONE portfolio member's selectors still publish stale t=y produce DECEPTIVELY-SILENT per-portfolio-member DIVERGENT DMARC-via-DKIM evaluation outcomes at every receiver per RFC 6376 §3.6.1 — the stale-t=y member's auth_results/dkim/result=pass elements are SILENTLY ignored by DMARC- alignment evaluation, producing cohort- divergent policy_evaluated/dkim=fail rows in the per-portfolio-member RUA aggregate streams; the DKIM-DNS-syntax spoke documents the t=y burn-in cap as the canonical UNIFORM per-portfolio- member burn-in-cleanup discipline whose violation produces this DECEPTIVELY-SILENT per-portfolio-member cohort-divergent defect class. Read THIS multi-domain DMARC strategy reference WITH the DKIM-DNS-syntax spoke when the per-portfolio-member DKIM TXT-record audit step arrives at the portfolio operator's queue: the multi- domain strategy page documents the PORTFOLIO-WIDE COORDINATION ARCHITECTURE, the DKIM-DNS-syntax spoke documents the PER-TAG PUBLISHER-SIDE TXT-RECORD AUTHORING discipline every per-portfolio-member publication MUST UNIFORMLY satisfy for the portfolio-wide multi-brand DMARC-policy coordination this page documents to advance.
• DKIM selectors explained - the PORTFOLIO-WIDE-SELECTOR-NAMESPACING- DISCIPLINE companion to this multi-domain DMARC strategy. Where THIS page documents the portfolio-coordination architecture (parallel vs serial rollout across N portfolio members, the four-pattern decision framework — single-org-many-brands / many- orgs-one-tenant / acquired-domain-wind-down / parked-domain-enforcement, the per-domain risk tiering, the org-wide DMARC-pass-rate floor management), the DKIM-selectors spoke documents the PER-DOMAIN-PER-VENDOR- SELECTOR-PUBLICATION-DISCIPLINE that the portfolio operator must apply uniformly across every portfolio member to make the multi-domain coordination architecture operationally viable. The four-axis MULTI- DOMAIN-VS-SELECTOR-NAMESPACING comparison exposes the structurally-distinct PORTFOLIO- COORDINATION-ON-SELECTORS roles: (i) single-org-many-brands portfolios MUST publish per-brand selectors uniformly across all N portfolio brands — a single SendGrid s1._domainkey published only at the parent-org domain does NOT cover child brand signing relationships; the portfolio operator MUST provision the per-vendor selector at EACH brand-domain's s1._domainkey.<brand-A>, s1._domainkey.<brand-B>, etc. so each brand's outbound mail validates against its own organisational-domain selector; the selectors spoke documents the per-vendor namespacing catalogue every portfolio member's DNS- published selector topology must mirror; (ii) many-orgs-one-tenant portfolios face uniform selector-publication coordination across multiple tenant-side selector defaults (Workspace google._domainkey, M365 selector1._domainkey + selector2._domainkey, cPanel default._domainkey) where every brand-domain in the tenant MUST publish the same selector pattern in its own DNS — the selectors spoke catalogues the per-tenant default-selector conventions the portfolio operator must coordinate; (iii) acquired- domain-wind-down sequences require auditing the legacy brand's EXISTING per-selector DKIM-key topology before the parent org's DMARC policy is extended — historical third-party-vendor selectors at s1._domainkey.<legacy-acquired- brand> may still be active and producing legitimate signed mail the parent org's policy must accommodate before advancing to p=reject; the selectors spoke documents the per- legacy-selector retirement checklist; (iv) parked-domain enforcement uses the per-key SELECTOR-ABSENCE pattern — the portfolio operator publishes NO selector TXT records at any *._domainkey.<parked-domain> wildcard, so any inbound DKIM verification against the parked-domain produces dkim=none and the parent's p=reject portfolio policy executes the reject without false- positive risk; the selectors spoke documents the parked-domain selector- absence posture as the canonical zero- lookup-budget selector publication pattern for non-mailing portfolio siblings. Read the DKIM-selectors spoke alongside this multi-domain strategy when scoping the portfolio-wide per-vendor selector publication topology — the per-vendor selector namespacing discipline the spoke documents is the BUILDING-BLOCK repeated across every portfolio member's published DKIM-key topology, and the multi-domain strategy's per-brand DMARC enforcement coordination cannot safely advance any portfolio member to p=reject without confirmed per-member-per-vendor selector publication uniformity.
• DKIM-Signature header anatomy — the PORTFOLIO-WIDE-PER-MESSAGE- DKIM-SIGNATURE-HEADER-BYTE-UNIFORMITY companion to this multi-domain strategy reference. Where THIS page documents the per-portfolio-member DMARC-policy-mode coordination contract (per-brand independent rollout cadence with cross-brand RUA-stream aggregation), the DKIM-Signature header-anatomy spoke is the per-message signature-header byte- grammar reference whose RFC 6376 §3.5 tag-list compliance must be UNIFORM across all N portfolio members before cross-portfolio policy-mode advancement can safely proceed. The PORTFOLIO-WIDE- PER-MESSAGE-SIGNATURE-TAG-COORDINATION cross-reference establishes FOUR structurally-distinct cross-portfolio signature-tag-coordination dimensions whose per-member variance breaks portfolio-level p=reject deployment safety: (i) per-portfolio- member d=-tag attribution consistency — the per-message DKIM-Signature header d= tag MUST resolve to each portfolio member's own organizational domain (not cross-portfolio-shared signing-service domain) so the receiver-side DKIM-Signature header anatomy documented by the spoke produces the per-portfolio-member organizational-domain attribution required for that member's DMARC adkim=r/s alignment under the per-member policy-mode this page documents — cross-portfolio d=<shared-domain> signing breaks the per-member alignment invariant; (ii) per-portfolio- member s=-tag selector namespace coordination — the per-message DKIM-Signature header s= tag MUST resolve to each portfolio member's authoritative DNS zone at <s=>._domainkey. <d=> per the PORTFOLIO-WIDE- SELECTOR-NAMESPACING-DISCIPLINE companion above documents — per-portfolio- member s= namespace collisions or per-member-per-vendor selector-publication gaps break the spoke's documented receiver-side parse contract uniformly across the affected portfolio segment; (iii) per- portfolio-member h= coverage and bh= body-hash discipline consistency — the per-message signing service for each portfolio member MUST include From: in the h= list (RFC 6376 §3.5 mandatory) and emit a SHA-256 bh= body-hash matching canonicalized-body bytes — per-portfolio- member h=-coverage gaps (acquired-brand legacy ESP forgets From: in h= while parent-portfolio modern ESP includes it) or per-member bh= body-hash mismatches produce per-member dkim=fail verdicts that cascade into per-portfolio-member RUA- stream attribution patterns the cross- brand aggregation THIS page documents observes; (iv) per-portfolio- member a= algorithm consistency + b= per-message signature-byte correctness — cross-portfolio a=rsa-sha256 vs a=ed25519-sha256 drift produces per-member verifier-support landscape divergence (older receivers without ed25519 support produce per-member dkim=permerror rather than dkim=fail); per-portfolio-member private-key rotation cadence drift produces per-message b= bytes computed against stale per-member published-key versions — both break the spoke's documented receiver-side cryptographic-verification contract on per-portfolio-member basis. Pair this page (the multi-domain portfolio coordination reference) with the DKIM-Signature header-anatomy spoke (the per-message signature-header byte- grammar reference) when diagnosing why some portfolio members exhibit dkim=fail RUA-stream patterns while others exhibit dkim=pass uniformly under the same cross-portfolio policy-mode coordination THIS page documents — the spoke documents the canonical compliant per-message DKIM-Signature header byte-layout whose per-portfolio- member variance produces the per-member verifier verdicts the cross-brand RUA- aggregation observes.
• DKIM alignment with DMARC — the MULTI-DOMAIN-PER-BRAND-DKIM-ALIGNMENT- CONSISTENCY companion documenting the DKIM- side identifier-alignment computation (RFC 7489 §3.1.1, adkim=r vs adkim=s, the Public Suffix List organizational-domain extraction algorithm, the multiple-signature "any aligns wins" rule, the M365 onmicrosoft.com gotcha, the Workspace gappssmtp.com gotcha, the SPF-vs-DKIM asymmetry under forwarding, subdomain semantics edge cases) whose per-brand UNIFORMITY across N portfolio members is the SINGLE most important prerequisite for the multi-domain coordination architecture documented on THIS page. Where THIS page documents the portfolio-rollout architecture (parallel vs serial cadence across N portfolio members, per-domain risk tiering, the four-pattern decision framework — single-org-many-brands / many-orgs-one-tenant / acquired-domain- wind-down / parked-domain-enforcement), the DKIM-alignment-with-DMARC spoke is the PER-BRAND-ALIGNMENT-CONTRACT companion documenting the byte-level d=- aligned signature computation each portfolio member's sending infrastructure must satisfy independently — and the per-brand consistency the portfolio operator must verify across all N members before the per-brand policy-mode advancement this strategy documents is safe. The four-axis MULTI-DOMAIN-VS-PER-BRAND-DKIM- ALIGNMENT-CONSISTENCY comparison exposes the structurally-distinct PORTFOLIO-COORDINATION- ON-ALIGNMENT roles: (i) single-org- many-brands portfolios MUST publish a properly-aligned d= per brand domain — NOT a single d=-of-the- parent-org that fails alignment on every child brand — a Workspace tenant sending mail under brand-a.com, brand-b.com, brand-c.com with the parent org's default d= produces DKIM-pass-but-DMARC-unaligned outcomes for every brand; the portfolio operator MUST provision per-brand DKIM keys with per-brand d= values via the Workspace Admin Console BEFORE any brand advances past p=none; (ii) many-orgs- one-tenant portfolios face the onmicrosoft.com / gappssmtp.com default-signing- domain trap on EVERY portfolio member simultaneously — a single Microsoft 365 tenant hosting mail for 12 brand domains signs every brand's outgoing message with the tenant's <tenant>.onmicrosoft.com DKIM by default; ALL 12 brands fail DKIM alignment until the tenant operator enables per-brand custom DKIM signing in the Microsoft 365 Defender admin center; (iii) acquired-domain-wind-down sequences require auditing the legacy brand's existing DKIM-signing topology BEFORE the parent org's DMARC policy is extended to cover the acquired domain — the acquired legacy brand may have third-party-vendor DKIM-signing relationships (e.g. a CRM platform, an ESP, a transactional-email service) signing on its behalf with the VENDOR's d=; extending the parent's p=reject over the acquired domain without first either migrating the vendors to align under the acquired domain's DKIM key or removing the vendors will reject legitimate acquired- brand mail; (iv) parked-domain enforcement is the ONLY portfolio pattern where DKIM alignment is structurally irrelevant — parked domains by definition send no mail, so no DKIM signature is ever generated; the DKIM-alignment- with-DMARC spoke documents that parked- domain p=reject is safe precisely because the per-brand DKIM- alignment prerequisite is trivially satisfied (no signature to align). Read the DKIM-alignment-with-DMARC spoke when designing the per-portfolio-member readiness gates documented on THIS page: the per-brand DKIM-alignment posture is the prerequisite the policy-mode advancement cadence depends on, and the per-brand consistency the portfolio operator must coordinate across all N members.
• DMARC policy rollout - the single-domain none -> quarantine -> reject cadence each portfolio domain applies.
• DMARC policy modes - p=none vs p=quarantine vs p=reject (the MULTI-DOMAIN-POLICY-MODE-COORDINATION companion to this portfolio strategy) - the MULTI-DOMAIN-POLICY-MODE-COORDINATION companion documenting the head-to-head comparison of the three DMARC enforcement values p=none / p=quarantine / p=reject whose VALUE-CHOICE this portfolio strategy coordinates across N domains. Where THIS page documents the portfolio-rollout architecture (parallel vs serial cadence across portfolio members, per-domain risk tiering, the cross-domain reporting pipeline, the cross-portfolio observability dashboard), the policy-modes spoke documents the per-domain VALUE-CHOICE decision the portfolio operator MUST make for each member domain independently: when does example.com advance from p=none to p=quarantine (the canonical 2-4 week monitoring window with zero legitimate-mail-blocking risk), when does it advance to p=reject (after sustained policy_evaluated=pass at ~99.5%+ across all RUA-reporting receivers), and how does the portfolio operator coordinate the per-domain cadence across the N portfolio members in parallel without creating cross-domain failure-state confusion at the central RUA pipeline. Critical pre-condition reference: every per-domain policy-mode advance the multi-domain rollout cadence executes is bounded by the policy-mode value-grammar the policy-modes spoke documents. Read the policy-modes spoke alongside this strategy when designing the per-domain risk-tiering (Tier-1 customer-facing domains advance ASAP, Tier-2 transactional domains advance AFTER 4-week monitoring, Tier-3 parked / legacy domains can JUMP STRAIGHT to p=reject because they have NO legitimate-mail-blocking risk).
• DMARC deployment checklist - the operator quick-reference for the portfolio rollout sequence.
• DMARC for Hybrid Exchange (on-prem + M365) - the MULTI-DOMAIN-HYBRID-SENDER- INVENTORY-CROSS-BRAND-DUAL-EGRESS- TOPOLOGY companion to this portfolio strategy. Where THIS page documents the portfolio-rollout architecture (parallel vs serial cadence across N portfolio members, per-domain risk tiering, the four-pattern decision framework — single- org-many-brands / many-orgs-one-tenant / acquired-domain-wind-down / parked-domain- enforcement), the DMARC-for-Hybrid-Exchange spoke documents the SENDER-TOPOLOGY- SPECIFIC inventory-explosion every portfolio member sharing a hybrid Exchange + EOP infrastructure encounters: EACH brand domain's sender inventory MUST enumerate TWO orthogonal egress paths (the EOP-outbound IP range covered by include:spf.protection.outlook.com + the on-prem Edge Transport IP that must be added as an explicit ip4:<on-prem-edge-IP> mechanism), AND EACH brand domain's DKIM-signing topology MUST cover BOTH the M365-tenant selector1/selector2 CNAME publication (per-brand customer-domain CNAME delegation under the M365 tenant) AND the on-prem Edge Transport DKIM signing path (commonly the legacy on-prem DKIM key OR a missing-signature misconfiguration that breaks brand-level alignment). The structural complication compounds across multi-brand portfolios: N brand domains × 2 egress paths × 2 DKIM signing topologies = 4N sender-inventory tuples the portfolio operator must individually verify in the per-brand RUA stream. Read the DMARC-for-Hybrid-Exchange spoke alongside this portfolio strategy when ANY portfolio member's M365 deployment is on a hybrid Exchange + EOP infrastructure — the hybrid-topology dual-egress inventory step is the load-bearing per-brand authoring discipline the portfolio's per-domain SPF + DKIM publication cadence depends on, and misconfiguration of ANY brand's hybrid- egress inventory produces brand-specific legitimate-mail-blocking incidents at portfolio-wide p=quarantine / p=reject advancement.
• DMARC aggregate (RUA) reports - the XML schema reference for the reports consolidated into your central pipeline.
• DMARC troubleshooting — the PORTFOLIO-SCALE-PER-DOMAIN-DMARC-FAIL- DIAGNOSTIC-FANOUT companion to this multi- domain DMARC strategy reference. Where THIS page documents the portfolio-scale DMARC- publication strategy across N owned domains (per-domain apex DMARC TXT publication cadence, subdomain policy sp= / np= coordination, per-domain SPF / DKIM prerequisite verification, per-domain ramp-phase sequencing, RUA aggregation point consolidation), the DMARC-troubleshooting spoke is the STRUCTURAL DOWNSTREAM CONSUMER of the per-domain ramp execution — the symptom-driven diagnostic ladder operators apply when ANY portfolio-member domain's aggregate RUA stream surfaces DMARC=fail rows produces a per-domain diagnostic fanout that scales with portfolio size. Four per-portfolio-wide-diagnostic-fanout dimensions: (i) PER-PORTFOLIO-MEMBER-DOMAIN- DIAGNOSTIC-EXECUTION-INDEPENDENCE (every portfolio-member domain executes the symptom-driven diagnostic ladder INDEPENDENTLY — a Pattern-1 SPF-failure root cause on domain A is structurally unrelated to a Pattern-3 alignment-failure root cause on domain B; the spoke's diagnostic ladder documents the per-domain triage discipline operators must apply across the entire portfolio), (ii) PER- PORTFOLIO-AGGREGATION-POINT-CROSS-DOMAIN- EVIDENCE-CORRELATION attribution (when the portfolio centralises RUA ingestion to a single aggregation point, the cross-domain evidence correlation pattern — same source IP producing DMARC=fail rows across multiple portfolio-member domains — is the canonical attacker-side-spoofing-vs- legitimate-sender-misconfiguration root- cause discriminator the spoke's diagnostic ladder documents), (iii) PER-PORTFOLIO- SUBDOMAIN-POLICY-INHERITANCE-DIAGNOSTIC attribution (operators publishing sp=reject at the organisational-domain apex while leaving np=none on the non-existent- subdomain policy observe per-subdomain DMARC=fail rows whose root cause is the per-subdomain policy inheritance grammar — the spoke's diagnostic ladder catalogues this multi-domain-specific defect class), (iv) PER-PORTFOLIO-PARKED-DOMAIN-NULL-MX- DIAGNOSTIC attribution (parked portfolio- member domains that publish DMARC without SPF or DKIM observe spoofing-attack- induced DMARC=fail rows in the aggregate stream — the spoke's diagnostic ladder documents the per-domain null-MX + DMARC- reject publication discipline as the canonical parked-domain remediation reference). Critical when this multi- domain DMARC strategy guide's reader observes per-domain DMARC=fail rows in any portfolio-member's aggregate RUA stream — the DMARC-troubleshooting spoke's symptom-driven diagnostic ladder is the canonical next step in the per-domain root-cause attribution and per-portfolio-wide diagnostic-fanout coordination workflow.
• DMARC reporting pipeline - the end-to-end ingestion + deduplication + retention architecture for portfolio-scale reporting.
• TLS-RPT (SMTP TLS Reporting, RFC 8460) explained — the PORTFOLIO-WIDE-TRANSPORT-LAYER- REPORTING-PIPELINE-COMPANION-TO-DMARC-RUA companion to this multi-domain DMARC strategy reference. Where THIS page documents the portfolio-scale DMARC publication strategy across N owned domains (per-domain rua= aggregation point consolidation, per-domain ramp-phase sequencing, per-subdomain sp= / np= coordination), the tls_rpt_explained spoke is the TRANSPORT-LAYER REPORTING COMPANION documenting the per-domain _smtp._tls.<d> TXT-record publication discipline whose per-domain rua=mailto:<tls- report-mailbox>@<domain> aggregation-point coordination parallels the DMARC RUA aggregation pattern THIS page documents. FOUR per-portfolio-wide transport-layer-visibility coordination dimensions: (i) per-portfolio- member-domain TLS-RPT publication- coordination-with-DMARC-RUA-publication- cadence — operators publishing the per-domain DMARC TXT MUST coordinate per-domain TLS-RPT TXT publication at the same per-domain DNS-zone-editor boundary (the transport-layer reporting endpoint at _smtp._tls.<d> is INDEPENDENT of the DMARC endpoint at _dmarc.<d> but the per-domain publication cadence is operationally-coordinated); (ii) per-portfolio-aggregation-point-TLS-report- ingestion-pipeline-parallels-DMARC-RUA- pipeline — when the portfolio centralises DMARC RUA ingestion to a single aggregation point, the parallel TLS-RPT JSON-report ingestion pipeline becomes the canonical per-portfolio transport-layer visibility infrastructure operators co-locate with the DMARC RUA pipeline; (iii) per-portfolio MTA-STS / DANE policy-deployment- validation-via-TLS-RPT-feedback-loop — operators deploying MTA-STS or DANE across the portfolio rely on the per-domain TLS-RPT feedback loop to observe per-receiver TLS-handshake- failure events that indicate per-domain policy-publication misconfigurations or per-receiver per-MX TLS-negotiation drift; (iv) per-portfolio composite per-domain authentication-AND- transport-layer visibility-floor — operators publishing DMARC + TLS-RPT in coordinated portfolio-wide cadence achieve a composite per-domain envelope-and-transport-layer observability floor that the DMARC-RUA-only deployment cannot match. Read the tls_rpt_explained spoke ALONGSIDE this multi-domain DMARC strategy page when designing the per-portfolio reporting infrastructure — the per-domain TLS-RPT publication discipline is the canonical transport-layer companion to the per- domain DMARC RUA discipline this page documents.
• DMARC monitoring & reporting analysis - portfolio dashboard discipline, KPIs, and alert thresholds.
• How attackers bypass weak DMARC - the 22-technique attacker reference - many techniques specifically target unprotected portfolio members.
• DMARC myths & misconceptions - operator misconception debunking; several myths target multi-domain strategy.
• DMARC for Google Workspace - per-provider rollout reference for a major sender in many portfolios.
• DKIM for Google Workspace (Gmail) - the WORKSPACE-TENANT-PER-PORTFOLIO- MEMBER-DOMAIN-DKIM-PUBLICATION-FANOUT companion to this multi-domain strategy reference. Where THIS page documents the portfolio-coordination architecture for per-organisational-domain DMARC policy-tier advancement across acquired domains, parked domains, per-business- unit-product-specific domains, and the long-tail of legacy domains, the Workspace-DKIM spoke is the DEDICATED per-Workspace-tenant per-portfolio- member DKIM-publication reference operators consult when ANY portfolio member's outbound mail egresses through a Google Workspace tenant — common in acquired-domain portfolios where the acquired company's Workspace tenant was inherited as an operational asset. Three concrete multi-domain-vs- Workspace-DKIM coupling points: (i) per-portfolio-member google._domainkey publication fanout across N portfolio domains under the same Workspace tenant — a single Workspace tenant routinely serves N portfolio member domains via the "Domains → Add a domain" workflow; EACH portfolio member domain requires its OWN per- domain google._domainkey TXT-record publication at its own DNS zone, AND the Admin Console "Generate new record" workflow must be exercised PER PORTFOLIO MEMBER DOMAIN; the Workspace-DKIM spoke documents the per-domain publication discipline the multi-domain operator scales across the portfolio; (ii) per- portfolio-member gappssmtp.com signing- identity gotcha at scale — the gappssmtp.com signing-identity gotcha surfaces on EVERY portfolio-member domain that has not completed Workspace DKIM activation; the multi-domain operator must audit the per-portfolio-member Workspace DKIM-activation status at the per-domain granularity to surface latent dkim=pass + dkim-alignment-fail Workspace-egress rows in the per-portfolio-member aggregate-XML evidence stream; the Workspace-DKIM spoke documents the per-tenant activation workflow operator runs against EACH portfolio member; (iii) per-portfolio-member manual rotation cadence coordination across N portfolio domains — the Workspace per-tenant DKIM rotation is MANUAL; a multi-domain operator running N portfolio domains under the same Workspace tenant must coordinate the per-portfolio-member rotation cadence so that EACH portfolio member's per-domain DNS- zone TXT-record + Admin Console key generation stay synchronised through dual-publish + flip + retire; the Workspace-DKIM spoke documents the per-domain manual rotation discipline the multi-domain operator scales across the portfolio's Workspace-egress mail-flow. Read the Workspace-DKIM spoke ALONGSIDE this multi-domain DMARC strategy reference whenever the per-portfolio-member mail-flow inventory includes Workspace egress at the per-portfolio-member- domain granularity.
• DKIM for Microsoft 365 - the M365-TENANT-PER-PORTFOLIO-MEMBER- DOMAIN-DKIM-PUBLICATION-FANOUT companion to this multi-domain DMARC strategy reference. Where THIS page documents the portfolio-coordination architecture for operators running per-portfolio-member- domain DMARC-record fanout across a portfolio of N author-domains (where N often spans 5 to 50+ org-level and product-level domains), the M365-DKIM spoke documents the structurally-parallel per-portfolio-member-domain DKIM publication fanout when the portfolio's primary mail-flow egress is a single Microsoft 365 tenant serving multiple accepted-domains. Three concrete multi-domain-vs-M365-DKIM coordination points: (i) per-portfolio-member domain Defender accepted-domain registration — the single M365 tenant routinely serves N portfolio- member accepted-domains; the per- portfolio-member Defender registration + Enable-DKIM toggle MUST be flipped independently for each accepted-domain — DKIM activation for one accepted- domain does NOT cascade across the tenant's other accepted-domains; (ii) per-portfolio-member DNS-zone CNAME publication fanout — each accepted-domain's DNS zone must independently publish selector1. _domainkey and selector2. _domainkey CNAMEs pointing at the tenant-specific <selector>- <tenant>._domainkey.<tenant>. onmicrosoft.com targets; the per- portfolio-member DNS-zone fanout coordination is the load-bearing surface for M365 portfolio rollouts; (iii) onmicrosoft.com gotcha surfaces across ALL portfolio-member accepted- domains not yet activated — until per-portfolio-member Enable-DKIM is flipped AND CNAMEs are published, that accepted-domain's M365 egress signs with the tenant's onmicrosoft.com identity, breaking DKIM- alignment against the RFC 5322 From: and producing a per-portfolio-member DMARC- fail rate the per-author-domain aggregate-RUA stream surfaces as a per- member regression. Read the M365-DKIM spoke ALONGSIDE this multi-domain DMARC strategy reference whenever the per- portfolio-member mail-flow inventory includes Microsoft 365 egress at the per-portfolio-member-domain granularity.
• MTA-STS for Microsoft 365 - the M365-TENANT-PER-PORTFOLIO-MEMBER- DOMAIN-MTA-STS-POLICY-PUBLICATION-FANOUT companion to this multi-domain DMARC strategy reference. Where THIS page documents the portfolio-coordination architecture for operators running per- portfolio-member-domain DMARC-record fanout across a portfolio of N author- domains (where N often spans 5 to 50+ org-level and product-level domains), the M365-MTA-STS spoke documents the structurally-parallel per-portfolio- member-domain MTA-STS publication fanout when the portfolio's primary mail-flow egress is a single Microsoft 365 tenant serving multiple accepted- domains. Three concrete multi-domain-vs- M365-MTA-STS coordination points: (i) per-portfolio-member domain MTA-STS-publication trio (DNS TXT + HTTPS policy-host + per-domain TLS-RPT mailbox) fanout — the single M365 tenant routinely serves N portfolio-member accepted-domains; the per-portfolio-member MTA-STS- publication trio MUST be executed independently for each accepted-domain — publishing MTA-STS for one accepted- domain does NOT cascade across the tenant's other accepted-domains; (ii) per-portfolio-member DNS-zone publication coordination — each accepted-domain's DNS zone must independently publish the _mta-sts.<domain> TXT record (with per-domain id rev-numbering) AND host the per-tenant mta-sts.<domain> HTTPS-policy-host endpoint serving the per-domain mta-sts.txt policy file; the per-portfolio-member DNS-zone fanout coordination is the load- bearing surface for M365 portfolio transport-layer rollouts; (iii) per-portfolio-member testing → enforce mode-progression discipline as load-bearing portfolio-wide rollout- risk-mitigation — each portfolio-member's per-domain mta-sts.txt mode must independently progress from mode: testing to mode: enforce only after per-portfolio-member TLS-RPT JSON- aggregate ingestion confirms a per- domain steady-state zero-failure baseline; premature portfolio-wide enforce-mode promotion (without per- portfolio-member testing-mode steady- state baseline confirmation) is the highest-incidence cause of post-rollout portfolio-wide M365-egress delivery- failure incidents. Read the M365-MTA- STS spoke ALONGSIDE this multi-domain DMARC strategy reference whenever the per-portfolio-member transport-layer inventory includes Microsoft 365 egress at the per-portfolio-member-domain granularity.
• MTA-STS for Google Workspace (Gmail) - the WORKSPACE-TENANT-PER-PORTFOLIO- MEMBER-DOMAIN-MTA-STS-POLICY-PUBLICATION- FANOUT companion to this multi-domain DMARC strategy reference. Where THIS page documents the portfolio- coordination architecture for operators running per-portfolio-member-domain DMARC-record fanout across a portfolio of N author-domains (where N often spans 5 to 50+ org-level and product- level domains), the Workspace-MTA-STS spoke documents the structurally- parallel per-portfolio-member-domain MTA-STS publication fanout when the portfolio's primary mail-flow egress is a single Google Workspace tenant serving multiple primary-and-aliased domains. Three concrete multi-domain- vs-Workspace-MTA-STS coordination points: (i) per-portfolio- member domain MTA-STS-publication trio (DNS TXT + HTTPS policy-host + per- domain TLS-RPT mailbox) fanout — the single Workspace tenant routinely serves N portfolio-member primary-and-aliased domains; the per- portfolio-member MTA-STS-publication trio MUST be executed independently for each primary-and-aliased domain — publishing MTA-STS for one portfolio- member domain does NOT cascade across the tenant's other portfolio-member domains; (ii) per-portfolio- member DNS-zone publication coordination — each portfolio- member domain's DNS zone must independently publish the _mta-sts.<domain> TXT record (with per-domain id rev-numbering) AND host the per-tenant mta-sts.<domain> HTTPS-policy-host endpoint serving the per-domain mta-sts.txt policy file enumerating the five *.ASPMX.L.GOOGLE.COM hostnames; the per-portfolio-member DNS-zone fanout coordination is the load-bearing surface for Workspace portfolio transport-layer rollouts; (iii) per-portfolio-member testing → enforce mode-progression discipline as load-bearing portfolio- wide rollout-risk-mitigation — each portfolio-member's per-domain mta-sts.txt mode must independently progress from mode: testing to mode: enforce only after per-portfolio-member TLS-RPT JSON- aggregate ingestion confirms a per- domain steady-state zero-failure baseline; premature portfolio-wide enforce-mode promotion (without per- portfolio-member testing-mode steady- state baseline confirmation) is the highest-incidence cause of post-rollout portfolio-wide Workspace-egress delivery-failure incidents. Read the Workspace-MTA-STS spoke ALONGSIDE this multi-domain DMARC strategy reference whenever the per-portfolio-member transport-layer inventory includes Google Workspace egress at the per- portfolio-member-domain granularity.
• DMARC for transactional email — the PORTFOLIO-WIDE-TRANSACTIONAL-ESP- ALLOCATION companion to this multi-domain strategy reference. Where THIS page documents the per-portfolio-member-domain sender-inventory enumeration discipline across N portfolio members, the transactional-email spoke documents the eight canonical transactional-ESP platforms (SendGrid, Mailgun, Postmark, Amazon SES, SparkPost, Mailjet, Mandrill, Resend) whose per-portfolio-member allocation is the sender-inventory composition driver at four portfolio-vs-ESP coordination dimensions: (i) per-brand ESP-tenant partitioning — whether each portfolio brand gets its own ESP-tenant (per-brand DKIM-d= isolation, per-brand bounce + abuse contact ownership) vs shared ESP-tenant with per-brand sub-account routing (per-brand sender-subdomain isolation only); (ii) per-brand SPF include-cascade authoring — each portfolio member's SPF record must enumerate the per-brand-allocated ESP's include: token independently, with per-ESP lookup-cost arithmetic against the RFC 7208 §4.6.4 10-DNS-lookup ceiling at every portfolio member; (iii) per-brand DKIM selector + d=-tag publication — each portfolio member's customer-vanity DNS zone must publish the per-ESP-specific selector convention (SendGrid's s1/s2._domainkey CNAME- delegation, Mailgun's k1._domainkey direct-TXT, Postmark's date-stamped YYYYMMDDdd._domainkey, SES's triple-token CNAME-delegation), with per-brand selector-namespace conflict detection when two portfolio members share an ESP-tenant; (iv) per-brand per-message d=-vs-From: alignment verification — each portfolio member's per-ESP outbound traffic must be auditable for DKIM-aligned-pass at the per-message granularity before the portfolio member's p=reject cutover is safe. Read the transactional- email spoke alongside this multi-domain strategy reference whenever the portfolio sender-inventory includes transactional ESP usage at the per-portfolio-member- domain granularity, when allocating new ESP tenants across N portfolio members, or when consolidating multiple portfolio-member ESP accounts onto a single ESP-tenant footprint.
• MTA-STS vs DANE — the PORTFOLIO-WIDE-PER-MEMBER-DOMAIN- TRANSPORT-LAYER-PROTOCOL-CHOICE companion reference. Where THIS page documents the portfolio-coordination architecture across N portfolio members (single-org- many-brands / many-org / parked-domain / acquired-domain patterns) with per- member-domain DMARC-policy-tier advancement coordination, the MTA-STS-vs- DANE spoke is the BINARY-TRANSPORT-LAYER- PROTOCOL-CHOICE companion EACH per- member-domain transport-security publication discipline MUST resolve across four portfolio-wide protocol- choice coordination dimensions: (1) heterogeneous per-member-domain DNSSEC coverage profile — a multi-domain portfolio typically presents heterogeneous DNSSEC coverage across N portfolio members (some members hosted on DNSSEC-signed registrar zones, some on non-DNSSEC registrar zones, some on acquired-domain zones whose DNSSEC coverage was unsigned by the prior owner) — DANE STRUCTURALLY requires DNSSEC on the per-member-domain's parent zone AND on EACH per-member-domain's MX hostname's parent zone, so the per- member-domain protocol-choice decision- tree MUST resolve to MTA-STS for non- DNSSEC-signed members and CAN resolve to DANE OR MTA-STS for DNSSEC-signed members — the spoke documents the per- member-domain DNSSEC-coverage gating constraint the portfolio-wide protocol- choice coordination consumes; (2) per- member-domain receiver-population enforcement coverage — the per-member- domain outbound-traffic receiver mix (consumer-brand member-domain mail delivered to Gmail / Yahoo / Microsoft 365 / Apple iCloud where MTA-STS enforcement is dominant vs European-B2B- brand member-domain mail delivered to t-online.de / GMX / web.de / posteo.de / mail.de where DANE enforcement is dominant) determines whether the per- member-domain transport-security discipline favours MTA-STS-only, DANE- only, or RFC 7672 §1.3 dual-protocol coexistence — the per-member-domain receiver-population mix is the load- bearing per-member-domain protocol- choice input the spoke documents; (3) RFC 7672 §1.3 coexistence rule coordinated across N portfolio members — when a per-member-domain publisher operates BOTH MTA-STS AND DANE simultaneously, the RFC 7672 §1.3 coexistence-and-precedence rule applies: DANE-validating receivers prefer DANE; receivers that fail to DNSSEC-validate the TLSA records fall back to MTA-STS — the portfolio-wide coordination discipline requires the per-member- domain protocol-choice decisions to produce a UNIFORM portfolio-wide receiver-side fallback-precedence behaviour OR an explicitly-documented per-member-domain divergent fallback behaviour the portfolio-wide transport- failure-signal interpretation accepts; (4) per-member-domain MX-publication- discipline divergence — DANE TLSA records key on the _25._tcp.mx.<member-domain> record AT EACH per-member-domain's MX hostname's DNSSEC-signed zone; MTA-STS policy files key on the mta-sts.<member-domain> HTTPS-policy-host AT EACH per-member- domain apex — the per-member-domain publication-discipline divergence between per-MX-hostname-keyed DANE and per-member-domain-apex-keyed MTA-STS is the load-bearing per-member-domain authoring discipline the portfolio-wide transport-security publication coordination this page documents must orchestrate. Read the MTA-STS-vs-DANE spoke alongside this multi-domain strategy reference when scoping the per-member-domain transport-security publication discipline — the binary protocol choice and the per-member- domain receiver-population enforcement coverage are the load-bearing per- portfolio-member transport-layer publication decisions the multi-domain coordination architecture imposes before the portfolio-wide receive-side TLS-enforcement coverage guarantee can be declared operational across N members.
• DMARC for Microsoft 365 - per-provider rollout reference for the other major portfolio sender.
• DMARC for SaaS senders — the MULTI-AUTHOR-DOMAIN-PORTFOLIO- SHARED-SAAS-PLATFORM-DEPLOYMENT-COMPLEMENT companion to this multi-domain strategy reference. Where THIS page documents the portfolio-coordination architecture for per-organisational-domain DMARC policy- tier advancement across acquired domains, parked domains, per-business-unit-product- specific domains, and the long-tail of legacy domains, the DMARC-for-SaaS-senders spoke is the SHARED-SAAS-PLATFORM-DEPLOYMENT companion documenting the operationally- distinct case where MULTIPLE portfolio- member author-domains share a SINGLE SaaS-marketing-platform tenant whose shared-IP-pool egress identity must be independently coordinated against each author-domain's DMARC posture this page establishes. Concretely, the spoke documents FOUR multi-author-domain-SaaS-platform- deployment-coordination dimensions: (i) SaaS marketing platforms emit mail for multiple customer-tenant author-domains from a single shared-IP-pool egress identity — Salesforce Marketing Cloud, HubSpot, Marketo, Mailchimp, and Pardot each operate as multi-tenant platforms where a single SaaS-platform tenant emits mail on behalf of multiple customer author-domains (e.g. a holding company's marketing tenant emits campaigns for brand-a.com, brand-b.com, and brand-c.com from the same platform tenant under the same shared-IP- pool) — and the operator must independently coordinate the SaaS-platform's per-tenant signing identity (typically k1._domainkey.<customer-domain> CNAME-delegated to the SaaS platform's key-management zone) against each portfolio- member author-domain's DMARC-record publication; (ii) per-portfolio- member SaaS-platform onboarding requires per-author-domain DKIM CNAME publication AND per-author-domain SPF include appending — the operator must publish a per-author-domain DKIM CNAME record pointing to the SaaS platform's managed signing zone (e.g. k1._domainkey.<portfolio-member-domain> → k1.<saas-platform-domain>) AND append the SaaS platform's SPF directive (include:_spf.<saas-platform-domain>) to the portfolio member's existing SPF record — both publication steps are structurally PARALLEL to the per-portfolio- member DMARC-record fanout THIS page coordinates, fired exactly N times per portfolio (once per active customer- tenant author-domain on the SaaS platform); (iii) per-portfolio- member RUA aggregate-report monitoring of SaaS-platform egress requires per-author- domain source_ip attribution against the SaaS platform's shared-IP-pool inventory — every portfolio member's DMARC RUA aggregate-report stream surfaces SaaS- platform-egress rows with source_ip values from the SaaS platform's shared- IP-pool (typically a /24 or /22 CIDR range published in the platform's SPF include), and the multi-domain operator must coordinate per-portfolio- member attribution of these rows against the platform's per-tenant signing-identity discriminator to avoid mis-attributing one portfolio member's SaaS egress to a sibling portfolio member's domain; and (iv) SaaS-platform sub-account tenancy can collapse multiple portfolio members into a single platform tenant with per-author-domain Sender Profile isolation — Salesforce Marketing Cloud's Business Units, HubSpot's Marketing Hub seat-isolation, Marketo's smart-list partitions, and Mailchimp's audience-segmentation each provide a per-portfolio-member isolation surface within a single SaaS-platform tenant — the operator must decide whether to operate per-portfolio-member SaaS- platform tenants (one platform contract per author-domain) or a shared SaaS- platform tenant with per-author-domain Sender Profile isolation (one platform contract serving all portfolio members), with corresponding DMARC-coordination consequences in either direction. Read the DMARC-for-SaaS-senders spoke alongside this multi-domain strategy reference when the portfolio member's outbound mail-flow inventory shows a SaaS marketing platform as a primary egress channel — especially common at multi-brand enterprises where the marketing tech stack is centralised on one platform emitting from multiple portfolio author-domains.
• MTA-STS policy-file byte syntax — the PER-PORTFOLIO-MEMBER-MTA-STS- POLICY-FILE-FANOUT-PARALLEL-TO-PER- PORTFOLIO-MEMBER-DMARC-RECORD-FANOUT companion to this multi-domain strategy reference. Where THIS page documents the portfolio-coordination architecture for per-organisational-domain DMARC policy- tier advancement across acquired domains, parked domains, per-business- unit-product-specific domains, and the long-tail of legacy domains, the MTA-STS-policy-syntax spoke is the TRANSPORT-LAYER POLICY-FILE BYTE-GRAMMAR REFERENCE documenting the RFC 8461 §3.2 policy-file format whose PER-PORTFOLIO- MEMBER customisation is the structurally- parallel transport-layer deployment exercise. The PER-PORTFOLIO-MEMBER-MTA- STS-POLICY-FANOUT cross-reference establishes FIVE structurally-distinct per-portfolio-member MTA-STS deployment patterns the spoke's byte-grammar reference governs: (i) active- mail brand domains with high-volume cloud-MTA egress — each active- mail brand-domain in the portfolio publishes its own _mta-sts.<brand> TXT record + HTTPS policy file whose mx: allow-list enumerates the brand's authorised MX hosts (typically *.protection.outlook.com for M365 tenants or aspmx.l.google.com + alt1.aspmx.l.google.com for Workspace tenants); the spoke documents the canonical byte-format every brand- domain uses; (ii) acquired- company-legacy-mail domains during the post-acquisition integration window — acquired domains arrive with their own pre-existing MX topology that must be BRIDGED to the acquiring company's MTA- STS posture; the spoke documents the mode: testing intermediate byte-tag the integration-window publisher uses while the mx: allow-list bridges from the seller's MX to the buyer's MX; (iii) parked-domain pool with null-MX RFC 7505 posture — send-only-zero-receive parked domains in the portfolio still benefit from publishing an MTA-STS policy file with empty mx: set + the defensive mode: enforce tag, structurally analogous to the defensive p=reject + sp=reject tags the page's multi-domain strategy recommends for parked-domain DMARC posture; (iv) per-business-unit-product- specific domains with subdomain delegation — when a portfolio member uses subdomains for distinct business units (marketing.brand. com, support.brand.com), each subdomain may need its own MTA-STS policy file at _mta-sts.<subdomain> because RFC 8461 §2.4 explicitly denies parent-to-subdomain policy inheritance; the spoke documents the per-host policy-file byte-format the per-business-unit publication topology requires; (v) ccTLD regional portfolio members hosted on local shared-hosting providers — the ccTLD-regional portfolio members' legacy shared-hosting MX configurations often produce mx: allow- list bytes that diverge from the primary brand's cloud-MTA topology; the spoke documents the per-host byte- grammar that survives this divergence while keeping the portfolio's max_age: consistency operationally manageable. Pair this page (the portfolio-coordination strategy reference) with the MTA-STS-policy- syntax spoke (the transport-layer per- portfolio-member policy-file byte- grammar reference) when authoring the portfolio-wide transport-security deployment rollout — the spoke documents the per-portfolio-member byte-format every transport-layer deployment exercise must consume in parallel with the per-portfolio-member DMARC-record fanout this page coordinates.
• DMARC for shared hosting (cPanel / Plesk / DirectAdmin) - per-provider rollout reference for the shared-hosting domains that many SMB multi-domain portfolios still carry: legacy storefront domains, regional country-code top-level domains (ccTLDs) hosted on local shared-hosting providers for compliance reasons, sub- brand domains acquired during an acquisition where the seller's infrastructure was cPanel-hosted, and the long tail of low-traffic / never- sending domains that operators have historically parked on cPanel or Plesk because the per-domain cost ($1-$3 per month) is below the consolidation threshold. Where the Google Workspace and Microsoft 365 per-provider spokes above document the TENANT-LEVEL operator-empowerment model where the portfolio admin has full control over SPF / DKIM publication for every @domain the tenant sends from, the shared-hosting spoke documents the SHARED-HOSTING operator- empowerment CEILING where the portfolio admin has only the DNS-zone-level ability to publish DMARC at _dmarc.<domain> but often does NOT have the per-tenant ability to configure custom-domain DKIM on the shared MTA (the shared-hosting provider's MTA signs outbound mail with the provider's d= domain, not @your-portfolio-brand). This empowerment-ceiling difference directly impacts the four-pattern decision framework this page introduces (single-org-many-brands, many-orgs-one- tenant, acquired-domain wind-down, parked-domain enforcement): the parked-domain enforcement pattern is actually the EASIEST shared-hosting deployment because parked domains don't need DKIM, while the single-org-many-brands pattern is the hardest because every sending brand on shared hosting needs the operator to either (a) move sending to a custom SPF-includes-shared-hosting-IP-block record with ?all qualifier (degrading SPF strength), or (b) move sending off the shared-hosting platform entirely to a dedicated ESP where custom-domain DKIM is supported. Read this shared-hosting spoke when the portfolio includes ANY shared-hosting domain — the spoke is the authoritative per-provider procedural reference for the shared-hosting slot of the portfolio.
• DMARC for cPanel - the MULTI-DOMAIN-COHABITATION-INSIDE-A- SINGLE-CPANEL-ACCOUNT companion to this multi-domain DMARC strategy. Where the sibling shared-hosting spoke above documents the empowerment-CEILING distinction at the per-shared-hosting-provider category level (cPanel vs Plesk vs DirectAdmin spans an empowerment range and a sender-DKIM ceiling comparison), the dedicated cPanel deep-dive documents the structurally-distinct WITHIN-ONE-CPANEL-ACCOUNT multi-domain cohabitation that is the dominant SMB portfolio-on-cPanel deployment pattern. The four-axis MULTI-DOMAIN-VS-CPANEL-ACCOUNT- COHABITATION comparison exposes the structurally-distinct PORTFOLIO-COORDINATION- ON-CPANEL roles: (i) cPanel Addon- Domains and Parked-Domains cohabiting under one account share a single outbound MTA at the shared-hosting host — every portfolio member sending from the cPanel account egresses the same shared-tenant IP block, making per-portfolio-member SPF authoring IDENTICAL across the N cohabiting domains and the per-portfolio-member SPF-include token (e.g. include:shared-host- provider-spf.example) reusable verbatim across every cohabiting brand domain — the cPanel deep-dive documents the per-account shared-MTA envelope inheritance and the per-portfolio- member SPF authoring multiplier; (ii) cPanel auto-generated DKIM keyset provisioning at the Email Deliverability feature produces a per-domain default._domainkey keyset REGENERATED at each Addon Domain creation, so adding a new portfolio brand to the cPanel account spawns a new per-brand DKIM TXT record the portfolio operator must coordinate with the per-brand DNS zone — multi-domain cPanel cohabitation thus requires periodic per-account DKIM keyset audit to confirm every Addon Domain's default._domainkey is present in DNS and matches the cPanel-stored private key; the cPanel deep-dive documents the per-Addon-Domain DKIM keyset lifecycle the portfolio operator must track; (iii) cPanel Zone Editor publishes DMARC TXT at _dmarc.<addon-domain> per-portfolio-member, but cPanel's UI defaults the DMARC record to p=quarantine pct=50 on the per-account DMARC Wizard rather than leading with the p=none rua=-monitoring-first rollout this strategy documents — multi- domain cPanel cohabitation thus requires per-portfolio-member DMARC-TXT manual editing AT EACH Addon Domain to override the cPanel-default policy with the portfolio's chosen risk-tier policy ramp; the cPanel deep-dive documents the per-Addon-Domain Zone-Editor DMARC-TXT publication workflow the portfolio operator must repeat N times; and (iv) cPanel WHM-level per-account email-sending throttling + Exim mail-queue cohabitation produces a per-account aggregate-RUA reporting signature where the source-IP attribution of one Addon Domain's outbound mail is INDISTINGUISHABLE from another cohabiting Addon Domain's outbound mail at the same shared-host egress IP — multi-domain cPanel cohabitation thus requires per- portfolio-member aggregate-RUA disambiguation by the header_from / identifier_alignment_dkim / identifier_alignment_spf triplet rather than by source-IP alone, and the portfolio operator must consume per-Addon-Domain RUA streams expecting identical source-IP attribution across cohabiting siblings; the cPanel deep-dive documents the per-account shared-egress aggregate-RUA disambiguation discipline. Read the dedicated cPanel spoke alongside this multi-domain strategy whenever the portfolio includes a cPanel- hosted account with 2+ Addon Domains, 2+ Parked Domains, or 1+ Subdomain — the spoke is the authoritative per-Addon-Domain deployment reference whose four cohabitation coordination boundaries this multi-domain- strategy page is the portfolio-orchestration companion for.
• Email authentication cluster intro - the cluster-spanning primer covering DMARC, SPF, DKIM, BIMI, MTA-STS, DANE, TLS-RPT, and CAA together.
• Email authentication glossary - DefinedTerm reference for sp=, np=, organizational domain, Public Suffix List, and related portfolio vocabulary.
• BIMI VMC certificates deep dive - the MULTI-BRAND-DOMAIN- INVENTORY-PARALLEL-VMC- PROCUREMENT companion reference. Where THIS page documents the multi-domain DMARC portfolio strategy (organisational-domain sp= coverage, np= non-existent subdomain coverage, parked- domain null-SPF + DMARC p=reject bundles, acquired-company- legacy-mail domain consolidation, per- business-unit product- specific domain coordination, external- reporting-authorization _report._dmarc.<reporter-domain> TXT-record cross-domain publication coordination), the BIMI-VMC-certificates spoke is the authoritative reference for the PARALLEL PORTFOLIO-WIDE VMC PROCUREMENT EXERCISE that BOOTSTRAPS BIMI inbox- display eligibility across the brand-owning portion of the portfolio. Multi- brand portfolio publishers face the VMC-PROCUREMENT- SCOPE-QUESTION at portfolio scale: WHICH portfolio domains warrant per- domain-procured VMC + per- domain BIMI publication? The canonical taxonomy: (i) FLAGSHIP-BRAND DOMAINS carrying primary-trademark- registered marks and high- recipient-engagement mail- flow (always-VMC-procurement target — the brand- conversion-metric ROI is load-bearing); (ii) SUB- BRAND DOMAINS for distinct product lines or subsidiary brands with SEPARATE trademark registrations (per-sub- brand-VMC-procurement target with separate trademark validation workflow per VMC); (iii) ACQUIRED-COMPANY-LEGACY- MAIL domains where the acquiring entity owns the legacy trademark and wants to preserve brand continuity through the transition period (VMC- procurement target with trademark-assignment- documentation requirement); (iv) PER-BUSINESS-UNIT PRODUCT-SPECIFIC domains carrying internal sub-brand marks (case-by- case VMC analysis); (v) PARKED-DOMAIN POOL with no active mail-flow and no brand-display intent (NO VMC — only the null-SPF + DMARC p=reject bundle from THIS page); (vi) DEFENSIVE- REGISTRATION DOMAINS (typo-squatting-prevention registrations) with no brand display intent (NO VMC). Each portfolio domain in tiers (i) through (iv) requires its own VMC procurement workflow because a VMC binds a SPECIFIC TRADEMARK-REGISTERED MARK to a SPECIFIC DOMAIN per CA/Browser-Forum BR §3.2.2.8 EV validation, and the portfolio's primary-flagship VMC does not transfer to sub-brand or acquired- company-legacy domains. The portfolio-wide BIMI-deployment playbook: (i) classify portfolio domains into the six VMC-procurement tiers above; (ii) per VMC- eligible domain, perform the apex-CAA-pre-audit for DigiCert / Entrust authorisation in parallel; (iii) submit per-domain VMC applications in parallel with per-domain trademark documentation bundles; (iv) finalise per-domain SVG-Tiny-PS files matching each brand's primary mark; (v) publish per-domain default._bimi.<domain> TXT records declaring each domain's VMC + SVG bundle; (vi) verify per-domain receiver-side BIMI display at Gmail / Yahoo / Apple Mail / Fastmail. Read the BIMI-VMC- certificates spoke alongside this multi- domain-strategy page when authoring the portfolio-wide BIMI- deployment roadmap — per-brand-domain VMC procurement is the load-bearing operational exercise that BOOTSTRAPS BIMI display for the brand-owning portion of the portfolio, and the VMC-procurement-tier taxonomy is the difference between a portfolio-wide BIMI rollout that meets target brand-display coverage on schedule vs an open-ended per-domain-VMC- procurement crawl with no scope discipline.
• DKIM replay attacks explained — the PORTFOLIO-WIDE-DKIM-KEY-REUSE- AMPLIFIES-REPLAY-BLAST-RADIUS companion to this multi-domain DMARC strategy reference. Where THIS page documents the portfolio-level coordination of SPF + DKIM + DMARC publication across the brand inventory + addon-domains + parked-domains + acquired-company-legacy domains + per-business-unit-product- specific domains, the DKIM-replay-attacks spoke documents the structurally-distinct replay-attack threat-class whose blast radius scales DIRECTLY with the number of portfolio members sharing a compromised DKIM keypair. The PORTFOLIO-WIDE-DKIM- KEY-REUSE-AMPLIFIES-REPLAY-BLAST-RADIUS cross-reference establishes FOUR structurally-distinct multi-domain-replay- attack-containment-discipline dimensions: (i) per-brand-domain-selector- isolation-as-replay-blast-radius- containment-primitive dimension — if the portfolio operator publishes DISTINCT DKIM selectors per brand-domain (each portfolio member's <selector>._domainkey. <brand-domain> hosts a DISTINCT keypair), a captured-and-replayed message produced under brand-A's selector can ONLY be replayed against recipients targeting brand-A's organizational domain; if the portfolio operator REUSES a keypair across N brand-domains (publishing the same TXT-record content at every portfolio member's selector endpoint), the captured message can be RE-WRAPPED with brand-B's / brand-C's / brand-N's From: header and the receiver-side DKIM verifier validates the signature against EVERY portfolio member's selector endpoint — turning a single capture event into a portfolio-wide attack surface; the per-brand-domain selector isolation discipline THIS page documents is the structural primitive that contains the replay-attack blast radius to a single portfolio member; (ii) per-brand- domain-key-rotation-cadence-as-replay- attack-amortization-window-per-portfolio- member dimension — the DKIM-key- rotation cluster documents a 90-day rotation cadence as the canonical replay- attack-window upper bound; for the multi- domain portfolio operator, this cadence must be enforced INDEPENDENTLY per brand-domain — a portfolio operator that rotates brand-A's keypair on schedule but neglects brand-B's keypair leaves brand-B exposed to a longer replay-attack window than the operator's documented policy commits to; the portfolio- coordination discipline THIS page documents must enforce the rotation cadence as a PER-BRAND-DOMAIN invariant, not a portfolio-aggregate one; (iii) per-brand-domain-emergency- revocation-procedure-as-incident- response-isolation-primitive dimension — when a replay-attack campaign is detected against ONE portfolio member, the operator's emergency-revocation response must isolate the revocation to the affected brand-domain's selector ONLY — revoking a SHARED keypair would also break legitimate signing for every other portfolio member sharing the keypair, producing a portfolio-wide outage in response to a single-brand incident; the per-brand-domain selector isolation discipline THIS page documents is the structural prerequisite for per-brand-domain emergency-revocation the incident-response runbook requires; (iv) per-portfolio-member-RFC-9103- x-tag-expiration-as-replay-window-bound- per-brand-domain dimension — the RFC 9103 / RFC 6376 §3.5 x=<timestamp> per- message expiration tag the DKIM-replay- attacks spoke documents bounds the per- message replay-window; for the multi- domain portfolio operator the x-tag publication discipline must be enforced independently per brand-domain to ensure the per-message replay-window-bound applies to every legitimate-send-path across the portfolio — a portfolio operator that publishes x-tags for brand-A's outbound mail but omits them for brand-B's outbound mail leaves brand-B's messages with UNBOUNDED replay-windows; the per-portfolio- member x-tag publication discipline is the structural prerequisite for the portfolio-coordination replay-defense the multi-domain strategy this page documents must orchestrate. Read this DKIM-replay-attacks spoke alongside THIS multi-domain strategy reference when authoring the per-brand-domain DKIM-key-management discipline that contains the replay-attack blast radius to a single portfolio member instead of amplifying it across the entire estate.
• DMARC forensic (RUF) reports — the PORTFOLIO-WIDE-RUF-ADDRESS- ALLOCATION-AND-CROSS-DOMAIN-EVIDENCE- CONSOLIDATION companion to this multi- domain DMARC strategy reference. Where THIS page documents the portfolio-level coordination of SPF + DKIM + DMARC publication across the brand inventory + addon-domains + parked-domains + acquired- company-legacy domains + per-business-unit- product-specific domains, the DMARC- forensic-reports (RUF) spoke is the PER- MESSAGE-FAILURE-SAMPLE channel whose ruf= tag publication discipline at portfolio-scale interacts with FOUR portfolio-level RUF coordination boundaries: (i) PER-DOMAIN ruf= ADDRESS ALLOCATION — the portfolio-coordination decision between publishing a single org-shared ruf=mailto:dmarc-ruf@analytics.<org> consumed by every portfolio sibling vs per-brand-domain dedicated inboxes (ruf=mailto:ruf-<brand>@analytics.<org>) determines the per-brand attribution clarity of the forensic-evidence-receiving analyst's queue — the org-shared address model is operationally simpler but loses per-brand attribution at the inbox level; the per-brand-dedicated address model preserves attribution but increases the per-domain DNS-record-authoring surface AND the per-brand-inbox provisioning + monitoring overhead; (ii) CROSS-DOMAIN RUF CORRELATION ENABLES PORTFOLIO-WIDE ATTACK-CAMPAIGN DETECTION — when an attacker targets multiple portfolio sibling domains in coordinated phishing campaigns (a common BEC pre-flight pattern), the per-message AFRF samples arriving at the portfolio-consolidated RUF inbox surface cross-domain timestamp clusters + shared per-attacker source-IP attribution + per- attacker From:-header-rewrite-pattern fingerprints that single-domain RUF consumption would miss — the portfolio- scale RUF address strategy is structurally a CROSS-DOMAIN-ATTACK-CORRELATION- INFRASTRUCTURE-DECISION; (iii) PER-BRAND-DOMAIN FORENSIC-RATE-LIMIT RISK — major receivers (Gmail, Microsoft 365, Yahoo) rate-limit RUF emission per origin-domain (typically 1 sample per recipient per hour at scale), meaning portfolio domains with high legitimate-mail-failure volumes (parked- domain attacker-spoofed traffic) may receive only a sampled subset of RUF evidence; the portfolio-wide DMARC strategy must include a RUF-VOLUME- EXPECTATION-PER-DOMAIN baseline per portfolio-sibling for the operator's RUF inbox-provisioning + storage-retention capacity planning; (iv) GDPR / PRIVACY-POLICY MULTI-JURISDICTION ALIGNMENT FOR PORTFOLIO-WIDE RUF RECEIPT — when the portfolio spans multiple EU member-state jurisdictions (EU-shop brand + UK-services brand + Switzerland-acquisition brand), the per- brand-domain RUF receipt + the per- message AFRF payload's recipient-identifier + subject-header carriage may surface EU-resident PII subject to differing per-jurisdiction GDPR Art. 6 / Art. 9 processing-lawfulness justifications; the portfolio-wide RUF-receipt-and-retention policy must be authored to satisfy the STRICTEST per-jurisdiction policy across the portfolio sibling set, structurally more constrained than any single-domain RUF-receipt policy. Read the DMARC- forensic-reports spoke alongside this multi-domain strategy reference when authoring the portfolio-wide DMARC deployment's RUF channel — the spoke is the canonical RFC 7489 §7.3 / RFC 6591 / RFC 5965 RUF-format reference whose four portfolio-coordination boundaries this multi-domain-strategy page is the portfolio-orchestration companion for.
• Business Email Compromise (BEC) defence — the portfolio-wide attack surface every multi-domain operator must close. BEC operators routinely register lookalike domains (homoglyph, typo, cousin TLD) adjacent to the operator's portfolio AND spoof unauthenticated portfolio members whose DMARC policy is still p=none. The portfolio-wide enforcement progression THIS page documents (parked-domain bundle at every non-sending member, p=reject at every sending member, sp=reject at every organizational domain) is the load-bearing application-layer BEC defence — the BEC spoke is the FBI-IC3-tracked threat-class anchor whose stage-1 exact-domain spoofing variant this portfolio enforcement structurally defeats.
• Why SPF alone is insufficient — the PORTFOLIO-WIDE-PER-MEMBER-SPF- PROTOCOL-LEVEL-STRUCTURAL-INSUFFICIENCY- TAXONOMY-AS-LOAD-BEARING-CROSS-PORTFOLIO- JUSTIFICATION-FOR-COMPLETE-SPF-PLUS-DKIM- PLUS-DMARC-PUBLICATION-DISCIPLINE-STACK- ROLLOUT-COORDINATION companion to this multi-domain DMARC-strategy reference. Where THIS page documents the cross- portfolio per-org-domain per-active-mail- member per-parked-domain per-acquired- company-legacy-mail-domain DMARC enforcement-rollout coordination discipline (the parked-domain null-SPF + DMARC bundle at every non-sending member, the p=reject ramp at every active- sending member, the sp=reject subdomain-policy at every organisational domain, the cross-portfolio per-org-domain per-member rua-aggregate-XML evidence consolidation), the why-spf-alone-is- insufficient spoke is the SPF-PROTOCOL- LEVEL-INSUFFICIENCY-TAXONOMY canonical reference documenting WHY the per-portfolio- member per-domain SPF-only publication- discipline THIS page architects across N portfolio members is STRUCTURALLY INSUFFICIENT at the per-member per-message per-receiver authentication-evaluation boundary, and WHY the cross-portfolio per-member SPF + DKIM + DMARC complete- publication-discipline-stack must be rolled out UNIFORMLY across every portfolio member at four cross-portfolio SPF-insufficiency-coordination coupling dimensions: (i) Per-portfolio- member per-domain SPF-record-publication as load-bearing per-message-but-per- forwarder-broken authentication primitive — every portfolio member's per-domain SPF record (the per-member v=spf1 TXT-RR + per-member include: / a: / mx: / ip4: mechanism-list) is per- message-but-per-forwarder-broken at the per-mailing-list-mediator / per-corporate- gateway / per-vacation-autoresponder / per- ESP-relay envelope-rewrite boundary the why-spf-alone-is-insufficient spoke documents as load-bearing per-forwarder- class structural failure-mode; the cross- portfolio per-member-SPF-record-publication- discipline THIS page architects is STRUCTURALLY INSUFFICIENT at every per- portfolio-member per-forwarder-hop boundary; (ii) Per-portfolio- member per-domain SPF-permerror-and- temperror-class emergence as cross- portfolio per-member per-day per-message SPF-aligned-pass-rate-volatility-source — every per-portfolio-member per-domain SPF-record-publication exposes per-message SPF-PermError (record-syntax / 10-DNS-lookup- overflow / void-lookup-overflow / multi- record SPF publication) + SPF-TempError (per-receiver DNS-resolution-infrastructure- failure) verdict-class emergence the why- spf-alone-is-insufficient spoke documents as load-bearing per-publisher per-domain SPF-publication-discipline-failure-class catalogue; cross-portfolio coordination requires per-member SPF-record-publication- discipline-uniformity to avoid one-member SPF-permerror cascading into cross-portfolio per-member per-message dmarc=fail; (iii) Cross-portfolio per-member DKIM- cryptographic-foundation-publication- discipline-uniformity as load-bearing SPF-insufficiency-remedy across N portfolio members — when any per-portfolio- member per-message SPF-aligned-pass-path is defeated (per-forwarder-hop / per- permerror / per-temperror), the per- portfolio-member DMARC-aligned-pass-via- DKIM-only-path becomes load-bearing — which requires per-portfolio-member per-domain per-selector DKIM cryptographic-foundation- publication-discipline-uniformity (RSA- 2048 vs Ed25519 keypair, SHA-256 hash, canonicalization choice, private-key custody, rotation cadence) across EVERY portfolio member; without cross-portfolio DKIM-publication-discipline-uniformity, the per-member SPF-insufficiency the why- spf-alone-is-insufficient spoke documents propagates upward to per-member dmarc=fail on every DMARC-honouring receiver; (iv) Cross-portfolio per-member complete message-layer-authentication-publication- discipline-stack composition as portfolio- wide SPF-insufficiency-remediation completeness — the per-portfolio- member complete message-layer- authentication-publication-discipline- stack composes per-member SPF + per-member DKIM-cryptographic-foundation + per-member DMARC-disjunction-evaluation + per-member ARC-chain-preservation publication disciplines into the load-bearing per- portfolio-member SPF-only-insufficiency- remedy the why-spf-alone-is-insufficient spoke documents as canonical per-publisher cross-mechanism remediation completeness; the cross-portfolio per-member uniform rollout discipline THIS page architects IS the per-portfolio per-member instantiation of the per-publisher SPF- insufficiency-remedy completeness the why- spf-alone-is-insufficient spoke documents at the canonical per-publisher per-domain boundary. Read the why-spf-alone-is- insufficient spoke ALONGSIDE this multi- domain DMARC-strategy reference whenever the cross-portfolio per-portfolio-member SPF + DKIM + DMARC complete-publication- discipline-stack rollout coordination THIS page architects needs the per- portfolio-member protocol-level SPF- structural-insufficiency-class catalogue for the cross-portfolio cross-mechanism remediation completeness decision.
• Domain Security Checker - live DNS lookups for SPF, DKIM, DMARC, MTA-STS, CAA, BIMI, and DNSSEC across any portfolio domain.
• DNS Record Generator - interactive wizards for building SPF, DKIM, DMARC, BIMI, MTA-STS, CAA, and TLS-RPT records including the null-SPF + DMARC parked-domain bundle.
• SPF qualifiers explained — the LOAD-BEARING per-portfolio cross- member-domain PORTFOLIO-WIDE-PER-MEMBER- DOMAIN-TERMINAL-QUALIFIER-RAMP- COORDINATION-DISCIPLINE companion documenting the four RFC 7208 §4.6.2 qualifiers (+ Pass / - Fail / ~ SoftFail / ? Neutral) whose per-portfolio per-member-domain terminal-mechanism choice MUST be coordinated across the active-sending / parked / lookalike-defensive / subsidiary-acquired member-domain classes THIS page catalogues: active-sending member-domains follow the canonical ~all → -all enforcement-ramp playbook the qualifiers spoke documents (publish ~all with DMARC p=none + RUA during monitoring, advance to -all + DMARC p=quarantine / p=reject after ramp completion); parked / lookalike- defensive member-domains skip the deployment-monitoring phase entirely and publish v=spf1 -all immediately as the qualifiers-spoke canonical null-sender-domain configuration; subsidiary-acquired member-domains inherit the acquisition-source portfolio's per-member-domain qualifier-ramp phase at acquisition close and synchronize forward to the acquiring portfolio's per-portfolio target qualifier on a documented timeline. Where THIS page documents the per-portfolio cross- member-domain PORTFOLIO-WIDE STRATEGY REFERENCE (the per-member-domain active / parked / lookalike / subsidiary classification, the per-class DMARC + DKIM + SPF configuration, the per-portfolio cross-member-domain operational coordination patterns), the qualifiers spoke documents the PER-PORTFOLIO PER-MEMBER-DOMAIN TERMINAL-QUALIFIER-CHOICE DISCIPLINE that each member-domain ramp phase MUST publish to actually deliver the receiver-side enforcement-vs- deployment-monitoring posture this page's per-class configuration recommends. Read THIS page when STRUCTURING the per-portfolio cross- member-domain DMARC strategy across member-domain classes; read the qualifiers spoke when CHOOSING the per-member-domain SPF terminal qualifier (-all for parked / lookalike-defensive, ~all during active-sending monitoring, -all after active-sending ramp completion) that determines the receiver-side enforcement disposition each member-domain SPF record actually produces under the portfolio strategy this page documents.
• SPF mechanism tokens: include vs ip4 vs a vs mx — the PER-MEMBER-DOMAIN-PER- MECHANISM-TOKEN-CHOICE-MATRIX companion to this multi-domain DMARC strategy reference. Where THIS page documents the per-publisher per-domain portfolio-wide per-member-domain DMARC strategy (organisational-domain inheritance per RFC 7489 §3.2, per-member-domain sp= subdomain-policy propagation, per-member-domain _dmarc-record publication discipline across the per-publisher per- domain multi-domain portfolio, per- member-domain per-day per-publisher per- day DMARC-aligned-pass-rate-floor convergence), the SPF-mechanism-token- choice spoke is the PER-MEMBER-DOMAIN- PER-MECHANISM-TOKEN-AUTHORING-DISCIPLINE companion documenting the per-publisher per-domain per-member-domain per- mechanism-token authoring decision- matrix the per-publisher per-domain portfolio operator MUST compose at FOUR per-member-domain per-mechanism-token- choice-distribution dimensions: (i) per-member-domain ESP-vs-self- hosted egress per-mechanism-token- choice distribution — the per- publisher per-domain portfolio operator MUST partition the per-publisher per- domain multi-domain portfolio into per- member-domain self-hosted-egress members (favouring per-member-domain ip4: / ip6: tokens that consume ZERO of the RFC 7208 §4.6.4 ten-DNS-lookup-budget) vs per-member-domain ESP-integrated- egress members (consuming per-member- domain include: tokens for the ESP-published SPF-include macro per RFC 7208 §5.2) at the per- publisher per-domain per-member-domain SPF-record authoring boundary; (ii) per-member-domain per-publisher per-domain per-day per-member-domain SPF-aligned-pass-rate-floor portfolio- wide convergence-discipline as per- mechanism-token-choice readiness- verification — the per- publisher per-domain portfolio operator MUST track per-receiver per-day per- publisher per-day per-member-domain SPF-aligned-pass-rate-floor as the empirical-observability proxy for the per-member-domain per-mechanism-token- choice-distribution authoring- discipline correctness BEFORE ramping per-publisher per-domain per-member- domain DMARC policy from p=none through p=quarantine to p=reject across the per- publisher per-domain portfolio strategy this page documents; (iii) per-member-domain per-publisher per-domain portfolio-wide RFC 7208 §4.6.4 ten-DNS-lookup-budget per- member-domain mechanism-token-choice- budget-discipline — the per- publisher per-domain portfolio operator MUST audit per-publisher per- domain per-member-domain SPF-record mechanism-token portfolios against the per-RFC-7208-§4.6.4 ten-DNS-lookup- budget that include:, a:, mx:, and exists: mechanisms each consume, FAVOURING per-member-domain ip4: / ip6: / -all token-portfolios whose per-member-domain evaluation-budget consumption is LITERALLY ZERO, against per-member- domain ESP-included macro-cascades that compound per-member-domain SPF-permerror-risk at the per- publisher per-domain portfolio-wide per-member-domain SPF-authorisation scale; and (iv) per-publisher per-domain portfolio-wide per-member- domain v=spf1 publication-discipline-completeness invariant as per-publisher per-domain per-member-domain DMARC-enforcement- readiness gate — the per- publisher per-domain portfolio operator MUST verify EVERY per- publisher per-domain per-member- domain in the multi-domain portfolio publishes a syntactically-valid per- member-domain v=spf1 record whose per-mechanism-token- choice-distribution authorises the per-publisher per-domain per-member- domain mailflow egress source-IP footprint before declaring per- publisher per-domain per-member- domain DMARC-enforcement readiness — a per-publisher per-domain per- member-domain SPF-record-publication gap (missing per-member-domain SPF record, per-member-domain include: chain unresolvable, per-member-domain mechanism-token-choice budget exceeded) emits per-publisher per- domain per-member-domain SPF-permerror verdicts that DEGRADE the per-publisher per-domain portfolio-wide DMARC-aligned-pass- rate-floor convergence the multi- domain strategy this page documents depends on. Pair this multi-domain strategy reference with the SPF- mechanism-token spoke when AUTHORING the per-publisher per-domain portfolio- wide per-member-domain SPF-record mechanism-token portfolio — the SPF-mechanism-token spoke is the PER- MEMBER-DOMAIN-PER-MECHANISM-TOKEN- CHOICE-AUTHORING-DISCIPLINE REFERENCE whose per-publisher per-domain per- member-domain per-mechanism-token- choice decision-matrix the per- publisher per-domain portfolio operator structurally depends on to compose the per-member-domain SPF authorisation footprint THIS page's per-publisher per-domain portfolio- wide DMARC-strategy architecture materially requires.
• TLS-RPT report format - the PER-PUBLISHER-PER-MEMBER-DOMAIN- PORTFOLIO-WIDE-TRANSPORT-LAYER-JSON- AGGREGATE-REPORT-FORMAT companion to this multi-domain DMARC strategy reference. Where THIS page documents the per-publisher per-member-domain portfolio-wide DMARC-strategy architecture (per-member-domain SPF publication discipline, per-member- domain DKIM selector publication, per- organisational-domain DMARC TXT-record publication with sp= subdomain-policy inheritance and np= non-existent-subdomain policy extension per RFC 9091, per- member-domain ramp-advancement coordination across the portfolio) and surfaces the receiver-side per-day per-source-IP DMARC-aligned-pass evidence the operator consumes from the per-member-domain rua= aggregate-XML stream, the TLS-RPT report-format spoke documents the STRUCTURALLY-PARALLEL per-receiver per- publisher per-day RFC 8460 §4 JSON aggregate-report byte-grammar each per-member-domain _smtp._tls.<member-domain> endpoint receives whose per-failure result-type enum (starttls-not-supported, certificate-host-mismatch, certificate-expired, sts-policy-fetch-error, sts-webpki-invalid) is the receiver-side transport-layer observability primitive each per- member-domain STARTTLS handshake outcome surfaces to. Pair this multi-domain strategy reference with the TLS-RPT- report-format spoke at FOUR per- publisher per-member-domain portfolio- wide TLS-RPT-JSON-consumer dimensions: (i) per-member-domain per- receiver per-day JSON-report ingestion as portfolio-wide transport-layer- observability stream parallel to the per-member-domain DMARC aggregate-XML stream - each _smtp._tls.<member-domain> published rua=mailto: endpoint receives per-day JSON aggregate-reports from every receiver processing that member-domain's egress under MTA-STS or DANE policy and the report-format spoke's byte-grammar reference enables per-member-domain per-receiver per-day per-policy- evaluation parsing without which the portfolio-wide per-member-domain transport-layer evidence stream remains opaque at portfolio scale; (ii) per-failure result-type enumeration as per-publisher per-member-domain per- receiver per-day silent-failure attribution catalogue across the heterogeneous portfolio of N member- domains - the spoke's per- failure result-type enum lets the portfolio operator distinguish per- member-domain starttls-not-supported (receiver lacks STARTTLS for that member-domain's traffic) from per- member-domain sts-policy-fetch-error (member-domain's mta-sts.<member-domain> policy file unreachable) from per- member-domain certificate-host-mismatch (member-domain's mta-sts.txt mx: allow-list specifies MX hostnames whose presented certificates fail SNI matching) at the per-member-domain granularity required for portfolio-wide transport-layer triage; (iii) per-member-domain per-receiver per-day summary.total-successful-session-count / total-failure-session-count as per-member-domain MTA-STS-mode- progression-readiness empirical input - the spoke's per-day per-MX-host successful-vs-failed STARTTLS session-count aggregation is the LOAD-BEARING empirical-readiness gate the portfolio operator uses to ratchet per-member-domain MTA-STS policy from testing to enforce at heterogeneous per-member-domain rates across the portfolio (each member-domain's total-failure-session-count baseline must be sustained-low at the per-receiver-per-day level before the operator flips THAT member-domain to enforce mode); and (iv) per-failure sending-mta-ip / receiving-mx-hostname / failure-reason-code as portfolio-wide per-member-domain per- receiver per-day cross-member-domain consistency-deviation incident-triage primitive - when one member-domain shows sustained certificate-host-mismatch on a specific sending-mta-ip while peer member-domains in the same portfolio show clean STARTTLS, the per-failure attribution lets the portfolio operator attribute the failure to a specific per-member-domain certificate-misconfiguration vs a portfolio-wide CA-chain regression. Pair THIS multi-domain strategy reference with the TLS-RPT-report- format spoke when designing the per-publisher per-member-domain portfolio-wide cross-protocol-pillar observability discipline that fuses the per-member-domain DMARC RUA-XML message-layer evidence stream with the per-member-domain TLS-RPT-JSON transport-layer evidence stream into the unified portfolio-wide authentication-and-encryption-posture observability surface every production- grade per-publisher multi-domain deployment STRUCTURALLY DEPENDS on for portfolio-wide ramp-advancement coordination closure.
• BIMI SVG Tiny PS logo requirements - the PER-PUBLISHER-PER-MEMBER-DOMAIN- PORTFOLIO-WIDE-BIMI-SVG-COMPLIANCE- COORDINATION companion to this multi- domain DMARC strategy reference. Where THIS page documents the per-publisher per-member-domain portfolio-wide DMARC- strategy architecture (per-member-domain SPF / DKIM / DMARC publication with sp= / np= coordination across the portfolio), the BIMI SVG requirements spoke documents the BIMI-PROTOCOL-LAYER LOGO-ASSET AUTHORING extension whose per-publisher per-member-domain SVG-asset compliance with the BIMI Tiny PS profile is the per-portfolio per-member-domain logo- display readiness gate the per-member- domain BIMI rollout coordinates against, at FOUR per-publisher per-member-domain portfolio-wide BIMI-SVG-compliance coordination dimensions: (i) per- publisher per-member-domain SVG-asset Tiny PS profile compliance as per-member- domain logo-display readiness gate parallel to per-member-domain DMARC p=quarantine / p=reject enforcement floor - each member-domain's default._bimi.<member-domain> TXT-record l= URL must resolve to an SVG conforming byte-for- byte to the Tiny PS profile (root attributes correct + required elements present + forbidden elements absent + ≤32 KiB) the BIMI evaluator's parser accepts at the per-member-domain logo- publication readiness moment paralleling the per-member-domain DMARC enforcement floor required as the BIMI-evaluator- gating precondition; (ii) per- publisher per-portfolio per-member-domain SVG-asset 1:1 aspect-ratio + viewBox 0-512 numeric bound coordination as portfolio- wide BIMI-asset-publication uniformity constraint - per-portfolio per-member-domain logos must each conform to the 1:1 aspect-ratio + 0-512 viewBox + preserveAspectRatio="xMidYMid meet" contract independently regardless of the per-member-domain brand-mark provenance (each member-domain's brand-mark must be re-cut to the Tiny PS profile rather than shared across the portfolio); (iii) per-publisher per-portfolio per- member-domain SVG-asset <script> / <foreignObject> / <animate> / <image> / external- ref forbidden-element-class compliance as per-member-domain security-posture parallel to per-member-domain DMARC- publication-discipline - the BIMI Tiny PS profile forbids every SVG element-class capable of executing client-side code or retrieving external resources (each member-domain's SVG MUST pass the forbidden-element validation gate independently); and (iv) per- publisher per-portfolio per-member-domain SVG-asset validation toolchain coordination via the BIMI Group's svg_validator per-member- domain pre-publication CI integration as portfolio-wide BIMI-asset-publication readiness gate - the BIMI Group publishes a reference svg_validator the per- publisher per-portfolio per-member-domain operator runs in CI before publishing each member-domain's SVG asset the l= tag references, with the per-member-domain validation result feeding the per-portfolio per- member-domain BIMI-asset-publication readiness-tracking dashboard the per-publisher operator maintains alongside the per-portfolio per-member- domain DMARC ramp-advancement readiness dashboard this multi-domain reference documents. Pair THIS multi-domain DMARC strategy reference with the BIMI SVG requirements spoke when designing the per-publisher per-portfolio per-member- domain BIMI-asset-publication coordination discipline that pairs the per-member-domain DMARC-enforcement- floor readiness with the per-member- domain SVG-Tiny-PS-profile-compliance readiness into the unified portfolio- wide BIMI-publication-readiness surface every production-grade per-publisher multi-domain BIMI rollout STRUCTURALLY DEPENDS on.
• CAA records explained — the PORTFOLIO-WIDE-PER-MEMBER-CAA-RR- PUBLICATION-DISCIPLINE companion to this multi-domain DMARC strategy reference. Where THIS page architects the per- portfolio-member DMARC-policy coordination across N org domains (parallel vs serial rollout, parked-domain reject publication, acquired-domain inheritance, per-org-domain RUA-aggregation), the CAA-records-explained spoke is the per-portfolio-member apex-zone TLS-chain authorization-RR publication discipline reference documenting the per- publisher per-portfolio-member apex-zone CAA RR publication primitive whose UNIFORM cross-portfolio-member publication is the load-bearing per-publisher per-portfolio TLS-certificate issuance-authority discipline EVERY production-grade multi-brand publisher STRUCTURALLY DEPENDS on. The PORTFOLIO-WIDE- CAA-VS-MULTI-DOMAIN-COORDINATION cross- reference establishes FOUR per-portfolio- member-CAA-publication-coordination dimensions: (i) per-portfolio-member apex-zone 0 issue property-tag publication uniformity — every portfolio member MUST publish a per- organizationally-approved-CA-allowlist 0 issue "<ca>" RR-set at its apex zone, and the per-publisher per- portfolio CA-allowlist coordination across N portfolio members is the load-bearing publisher-side TLS-chain issuance-authority discipline parallel to the per-portfolio- member DMARC-policy coordination THIS page architects; (ii) parked-domain per-member CAA 0 issue ";" deny-all publication discipline — portfolio members designated as parked- domains MUST publish 0 issue ";" + 0 issuewild ";" as the per-parked-domain TLS-certificate-issuance deny-all posture, parallel to the parked- domain DMARC p=reject publication discipline; (iii) per- portfolio acquired-domain CAA inheritance audit — newly-acquired portfolio members frequently inherit incumbent CAA RRs published by the prior owner that whitelist the prior owner's CA-allowlist rather than the new publisher's per-org approved-CA-allowlist; the per-acquired- domain CAA-RR audit and rewrite is the per-publisher per-portfolio operator-side incumbent-RR-class lifecycle parallel to the per-acquired-domain DMARC-publication inheritance audit; (iv) per- portfolio per-member iodef=mailto: <security-incident-mailbox> publication and rotation — every portfolio member MUST publish a per- publisher-monitored security-incident mailbox via the CAA iodef property-tag for per-CA unauthorized- issuance-attempt incident-report reception, parallel to the per-publisher DMARC ruf=mailto: per-message-failure forensic-report channel.
• MTA-STS explained — the PER-MEMBER-DOMAIN-TRANSPORT- LAYER-MTA-STS-PUBLICATION-DISCIPLINE- AS-PORTFOLIO-WIDE-COVERAGE-DISCIPLINE companion to this multi-domain DMARC strategy reference. Where THIS page documents the per-publisher portfolio- wide application-layer DMARC publication discipline (per-member- domain _dmarc.<member-domain> TXT-RR publication at every organizational-domain boundary including parked / acquisition / send- only / receive-only members), the MTA-STS-explained pillar documents the per-publisher portfolio-wide transport- layer MTA-STS publication discipline whose per-member-domain coverage gap leaves THAT specific member uncovered at the transport-layer regardless of the parent-corporate-domain MTA-STS posture at four portfolio-wide MTA- STS coverage-discipline coordination dimensions: (i) per-member- domain INDEPENDENT MTA-STS publication — the member-A mode: enforce commitment does NOT defend member-B against transport-layer downgrade — every member- domain in the portfolio MUST publish its own _mta-sts.<member> TXT-RR + HTTPS policy-file pair; the publication is per-member scoped because RFC 8461 does NOT inherit policy across organizational- domain boundaries the way DMARC's sp= inherits across subdomain scope; (ii) parked portfolio-members are HIGH-VALUE transport-layer spoofing targets — parked member-domains the operator owns but does not send mail from must STILL publish per-member MTA-STS + DMARC p=reject + sp=reject to defend against attackers using the parked domain to deliver spoofed mail; the per-member transport-layer publication discipline gap is the canonical parked-domain spoofing- exploitation surface; (iii) per-member mx: allow- list authoring per portfolio member- domain's distinct MX infrastructure — each member-domain's mta-sts.txt body enumerates the per-member receiver- side MX hostnames; multi-brand estates with distinct per-brand- cohort hosting (one brand on EOP, another on Workspace, a third on Fastmail) require per-member independent MTA-STS policy-file authoring per the per-brand inbound topology; and (iv) per- member-domain TLS-RPT _smtp._tls.<member> publication for per-member transport- layer observability — the per-publisher portfolio operator running multi-member DMARC reporting through rua= aggregation must STRUCTURALLY PARALLEL the per- publisher portfolio TLS-RPT v=TLSRPTv1; rua=mailto: publication at every per-member _smtp._tls.<member> leaf to maintain symmetric per- member transport-layer observability across the portfolio coverage boundary. Read the MTA-STS-explained pillar alongside this multi-domain DMARC strategy reference when architecting per-publisher portfolio- wide transport-layer coverage parity across every organizational-domain member in the estate.
• DKIM key rotation — the PER-PUBLISHER-PER-PORTFOLIO-PER- MEMBER-DOMAIN-DKIM-KEY-ROTATION- COORDINATION companion to this DMARC multi-domain strategy reference. Where THIS page documents the per-publisher per- portfolio per-member-domain DMARC publication coordination discipline (per-member-domain SPF + DKIM + DMARC publication at each member-domain apex, per-portfolio organizational-domain-tree management, per- member-domain `sp=`-tag subdomain-policy inheritance, per-portfolio aggregate-report consumption pattern), the DKIM-key-rotation spoke is the per-publisher per-selector key-lifetime operator-discipline floor each per-portfolio per-member-domain DKIM-signing leg STRUCTURALLY PRESUPPOSES is being operated on a coordinated rotation cadence. FOUR per-publisher per-portfolio per-member- domain DKIM-rotation coordination dimensions: (i) per-publisher per-portfolio per- member-domain rotation-cadence-floor portfolio-wide convergence as load-bearing operator-discipline primitive — per-publisher operators managing a portfolio of N member-domains MUST coordinate per- member-domain DKIM-rotation cadence to a portfolio-wide RFC 8301-recommended 90-180- day floor; per-member-domain rotation- cadence divergence across the portfolio produces heterogeneous per-member-domain key-compromise-window profiles the DKIM- key-rotation spoke catalogues as the portfolio-wide operator-discipline regression class whose per-publisher per-portfolio remediation requires central per-member- domain rotation-cadence-calendar coordination; (ii) per-publisher per-portfolio per- member-domain dual-selector overlap-window rotation coordination as per-receiver per- resolver-cache TTL-bounded propagation- window-floor portfolio-wide convergence consumer — per-publisher operators rotating per-member-domain DKIM keys portfolio-wide MUST publish `selector2._domainkey.<member-d>` AND keep `selector1._domainkey.<member-d>` live across the per-receiver per-resolver cache- eviction window AT EACH MEMBER-DOMAIN apex independently; the DKIM-key-rotation spoke documents the per-member-domain overlap- window discipline whose regression produces per-receiver dkim=permerror verdicts on in-flight mail signed by the just-deactivated selector AT WHICHEVER member-domain published the regression- producing commit; (iii) per-publisher per-portfolio per-member-domain RSA-1024-bit legacy-key- strength portfolio-wide remediation through coordinated rotation as per-receiver RFC 8301 key-strength minimum enforcement portfolio-wide convergence consumer — per-publisher operators managing portfolios with mixed-vintage per-member- domain DKIM-key-strength postures (some member-domains on RSA-1024-bit legacy keys, others on RSA-2048-bit RFC-8301 floor) MUST coordinate per-member-domain remediation to the RSA-2048 floor through a portfolio-wide rotation event the DKIM-key-rotation spoke catalogues; per-receiver Gmail / Outlook.com / Yahoo Mail enforcement of the RFC 8301 key-strength minimum is the load-bearing empirical-observability primitive that surfaces per-member-domain dkim=neutral verdicts UNTIL portfolio-wide rotation convergence completes; (iv) per-publisher per-portfolio per- member-domain key-compromise incident- response per-member-domain blast-radius- containment through selective per-member- domain rotation as canonical per-portfolio incident-response coordination discipline — when a per-publisher per-member-domain DKIM private-key compromise event surfaces (filesystem read / source-code-repo leak / CI-secret leak), per-portfolio incident response REQUIRES per-affected-member-domain revocation-via-empty-`p=` publication PLUS emergency rotation to a new per-selector key AT THE AFFECTED MEMBER-DOMAINS ONLY (blast-radius containment to per-member- domain scope); the DKIM-key-rotation spoke documents the per-member-domain incident- response selective-rotation discipline whose per-publisher per-portfolio runbook the per-portfolio operator MUST author at the per-member-domain DNS-zone-management boundary. Read the DKIM-key-rotation spoke alongside this DMARC multi-domain strategy reference when PLANNING the per-publisher per- portfolio per-member-domain DKIM-selector rotation cadence calendar with portfolio- wide convergence coordination, when AUDITING the per-publisher per-portfolio per-member-domain RSA-1024-vs-RSA-2048 key-strength posture for portfolio-wide RFC 8301 90-180-day rotation cadence compliance, or when AUTHORING the per-publisher per- portfolio per-member-domain DKIM-private- key compromise incident-response runbook whose per-member-domain blast-radius- containment discipline the DKIM-key-rotation spoke catalogues at the per-member-domain DNS-zone-management boundary.
• ARC (Authenticated Received Chain, RFC 8617) explained — the MULTI-DOMAIN-PORTFOLIO-INDIRECT-MAIL- FLOW-ARC-AUTH-PRESERVATION companion to this multi-domain DMARC strategy reference. Where THIS page documents the per-publisher per- portfolio cross-member-domain DMARC posture coordination (org-domain rule under PSL, sp= / np= subdomain segmentation, external-reporting authorisation, per-member-domain policy-ramp cadence sequencing), the ARC-explained spoke is the INDIRECT-MAIL-FLOW-AUTH-PRESERVATION REFERENCE every multi-domain portfolio operator consults when investigating per- member-domain DMARC-pass-rate drops correlating with cross-tenant mailing-list- expansion, auto-forwarder, or hybrid-relay second-hop SPF-break failure modes. Three structurally-distinct multi-domain-portfolio- ARC-coordination dimensions: (i) per-member- domain inbound ARC-Seal verification is the receiver-side mechanism that distinguishes legitimate mailing-list-expanded mail (per- member-domain DMARC-aligned verdict preserved via ARC chain) from spoofed- through-mailing-list mail (no ARC chain or broken seal); (ii) per-member-domain outbound ARC-Sealer publication decision interacts with portfolio-wide DMARC posture — adding an ARC-sealer at one member domain's egress boundary commits the operator to ongoing chain-validity discipline across all downstream forwarder hops the per-member- domain mail traverses; (iii) per-member- domain Trusted ARC Sealers configuration at receive-side Defender / Workspace portals must be coordinated portfolio-wide because each member domain's per-tenant Trusted ARC Sealers list independently affects cross-tenant forwarded mail's DMARC verdict at receive-side.
• RFC 7489 - DMARC - the base DMARC specification (organizational domain rule at section 3.2, sp= at section 6.3, external reporting authorization at section 7.1).
• RFC 9091 - DMARC np= extension - the non-existent-subdomain policy extension.
• RFC 7505 - Null MX - the null-MX standard for declaring a domain accepts no mail.
• Public Suffix List - the canonical effective-TLD registry the organizational-domain rule depends on.
• BIMI explained - the PORTFOLIO-WIDE-BIMI-PUBLICATION- DISCIPLINE-AS-PER-ORG-DOMAIN-DOWNSTREAM- CONSUMER-OF-MULTI-DOMAIN-DMARC-POSTURE companion to this multi-domain DMARC strategy. Where THIS page architectures the portfolio-coordination decisions (parallel vs serial DMARC rollout across N org domains, parked-domain reject publication, acquired-domain inheritance, per-org-domain RUA-aggregation across sibling members), the BIMI-explained spoke documents the per-org-domain default._bimi.<portfolio-member> publication discipline as the load-bearing downstream consumer the portfolio architect must coordinate ACROSS each portfolio member's independent BIMI-display eligibility gate. Concretely, the spoke documents FOUR per-portfolio-member-BIMI- coordination dimensions for the multi- brand publisher: (i) per- portfolio-member default._bimi TXT-RR publication discipline as the per-org-domain BIMI-display- prerequisite gate — the spoke documents how each portfolio member requires an INDEPENDENT default._bimi TXT-RR publication at its own org-domain before BIMI-supporting mailbox providers will render that member's brand logo; the multi-domain strategy must therefore sequence BIMI publication AFTER each member's DMARC-enforcement posture has reached the 90-day rolling pass-rate threshold provider-specific BIMI gates require; (ii) per-portfolio- member VMC enrolment as the per-org- domain trademark-authentication coordination dimension — when the portfolio architect operates a multi-brand publisher (each member owning a distinct trademark), the spoke documents how the per-member VMC enrolment becomes a per-org-domain coordination decision (which members rate the VMC capital outlay, which use the unverified-logo BIMI-only display tier) the portfolio strategy must explicitly sequence; (iii) per- portfolio-member parked-domain BIMI suppression as the brand-protection anti-spoofing portfolio-discipline dimension — the spoke documents how parked-domain portfolio members (acquired-but-inactive brands, defensive-registration domains) MUST deliberately publish a BIMI-absent posture (no default._bimi publication) so that hostile mail purporting to be from the parked member receives NO brand-logo render even if the attacker forges a DMARC- passing posture — complementing this page's parked-domain reject publication discipline at the recipient-side visual surface; and (iv) per-portfolio- member subdomain BIMI-publication delegation as the multi-brand portfolio's per-sub-org-domain coordination dimension — the spoke documents how each portfolio member's marketing-vs-transactional sub-org-domain split (this page's §6 coordination decision) propagates into a per-subdomain default._bimi.<subdomain>. <portfolio-member> publication-or-delegation choice the portfolio architect must explicitly plan; the spoke catalogues the subdomain BIMI inheritance rules as the per-sub-org-domain coordination primitive the multi-domain strategy feeds into. Read the BIMI-explained spoke ALONGSIDE this multi-domain DMARC strategy when the portfolio architect is authoring the per-org- domain BIMI-publication sequencing playbook that consumes the DMARC- enforcement coordination this page produces.
• DKIM best practices - the PORTFOLIO-WIDE-DKIM-DEPLOYMENT- DISCIPLINE-AS-LOAD-BEARING-DOWNSTREAM- CONSUMER-OF-MULTI-DOMAIN-DMARC-POSTURE companion to this multi-domain DMARC strategy. Where THIS page architectures the portfolio-coordination decisions (parallel-vs-serial DMARC rollout across N org domains, parked-domain reject publication, acquired-domain inheritance, per-org-domain rua aggregation), the DKIM-best-practices spoke documents the canonical DKIM publication-and-rotation discipline EVERY portfolio member must operate INDEPENDENTLY but COORDINATED across the portfolio. Concretely, the spoke documents FOUR per-portfolio- member-DKIM-best-practice-coordination dimensions for the multi-brand publisher: (i) per-portfolio- member 2048-bit RSA key-strength floor as the portfolio-wide DKIM-receiver- scoring-stability deployment-practice dimension — the spoke documents the 2048-bit RSA key-strength minimum as a portfolio-uniform deployment invariant the multi-brand publisher must enforce on every portfolio member independently — heterogeneous key- strength across the portfolio destabilises the receiver-side DKIM- scoring this page's deliverability coordination depends on; (ii) per-portfolio-member selector-rotation cadence coordination as the portfolio- wide key-compromise-window deployment- practice dimension — the spoke documents the per-org-domain selector- rotation cadence (90-day to 12-month) and how the multi-brand publisher must coordinate per-member rotation calendars to avoid synchronous portfolio-wide rotation events that would overwhelm the per-org-domain DNS-publication bandwidth this page's portfolio coordination depends on; (iii) canonicalisation-mode-choice as the per- portfolio-member ARC-survivability deployment-practice dimension — the spoke documents the c=relaxed/relaxed default as a portfolio-uniform deployment invariant that lets per-portfolio- member outbound mail traverse mailing- lists and forwarders without ARC- signing-discipline divergence; and (iv) per-portfolio-member acquired- domain DKIM inheritance as the portfolio-onboarding deployment- practice dimension — the spoke documents how the acquired-domain onboarding workflow this page's §7 catalogues must apply the canonical DKIM best-practice discipline (2048-bit keys, selector-rotation cadence, canonicalisation mode) to the newly-acquired portfolio member from day 1 — NOT inherit the prior owner's legacy DKIM posture. Read the DKIM- best-practices spoke alongside this multi-domain DMARC strategy when the portfolio architect is authoring the per-org-domain DKIM deployment- discipline coordination playbook that consumes the DMARC-enforcement coordination this page produces.
• SPF 10-DNS-lookup limit and SPF flattening — the PORTFOLIO-WIDE-PER-MEMBER-SPF- 10-DNS-LOOKUP-BUDGET-COORDINATION companion to this multi-domain DMARC strategy. Where THIS page documents the per-portfolio-member DMARC- policy-mode coordination contract (per-brand independent rollout cadence with cross-brand RUA-stream aggregation), the SPF-lookup-limit spoke is the per-publisher per-domain RFC 7208 §4.6.4 ten-DNS-query-budget operational reference whose four PORTFOLIO-WIDE-PER-MEMBER-LOOKUP- BUDGET-COORDINATION dimensions structurally constrain the per-member- SPF-publication topology every portfolio member must honour before cross-portfolio policy-mode advancement: (i) per-portfolio- member shared-ESP-include cascade budget uniformity — when a portfolio uses the SAME shared ESPs (SendGrid + Mailgun + Amazon SES + a per-brand transactional sender) across all N portfolio members, EACH member's per-domain SPF record carries the SAME include-cascade lookup cost (a single include:sendgrid.net consumes 3 lookups; nested ESP-side SPF includes inflate the budget multiplicatively across all portfolio members in parallel); the SPF-lookup- limit spoke documents the per-ESP lookup-cost reference table the portfolio operator MUST consult before adding a fifth shared ESP to ANY portfolio member's SPF record, because the budget exhaustion produces identical spf=permerror cascades across every portfolio member that includes the same ESP chain; (ii) per-portfolio- member subdomain delegation as budget-split coordination primitive — when one portfolio member's SPF record is within 1-2 lookups of the §4.6.4 cap, the portfolio operator splits the SPF publication across per-subdomain records (transactional ESP at mail.<brand>, marketing ESP at newsletter.<brand>, bulk ESP at bulk.<brand>) so each per-subdomain SPF record gets its own independent 10-lookup budget; the SPF-lookup-limit spoke documents the per-subdomain delegation operational discipline that the portfolio operator applies uniformly across portfolio members whose per-domain SPF record is budget- constrained, AND the per-subdomain DMARC sp=-tag coordination THIS page documents consumes the per-subdomain SPF publication the lookup-limit spoke catalogues; (iii) per- portfolio-member flattening refresh- cadence coordination — when the portfolio operator elects to flatten one or more portfolio members' SPF records (resolving every include / a / mx down to ip4 / ip6 ranges then republishing as a flat list), the portfolio operator MUST coordinate the cron- refresh cadence across all flattened portfolio members so a single upstream ESP IP rotation does not silently break SPF on member-A while member-B's flattened record is still valid; the SPF-lookup-limit spoke documents the flattening operational trade-off (architectural risk: the flattened record diverges from the upstream sender's real IP set between refresh cycles) that the portfolio operator must amortise across N portfolio members' flattening cron jobs before cross- portfolio p=reject can safely rest on flattened SPF records; and (iv) per- portfolio-member acquired-domain legacy-ESP-include audit primitive — when the portfolio operator inherits an acquired-brand portfolio member via §7 of THIS page's portfolio- coordination playbook, the acquired-domain's existing SPF record may contain legacy ESP includes (the prior owner's marketing-automation include cascade, an abandoned transactional sender include, etc.) whose per-include lookup cost combined with the parent-org's portfolio-standard ESP-include set may push the merged SPF record over the §4.6.4 cap; the SPF-lookup-limit spoke documents the per-include legacy- ESP audit discipline the portfolio operator MUST apply to every acquired-domain BEFORE advancing the acquired brand's DMARC policy beyond p=none, because an inherited spf=permerror condition cascades into immediate dmarc=fail on every message from the acquired brand the moment the parent's enforcement policy advances. Read the SPF- lookup-limit spoke alongside this multi-domain DMARC strategy when scoping the per-portfolio-member SPF-publication topology — the per-member RFC 7208 §4.6.4 ten- DNS-query budget is a per-domain publishing constraint that structurally caps the per-member SPF-publication topology independently of every other portfolio member, and the cross- portfolio DMARC-policy-mode coordination THIS page documents cannot safely advance any portfolio member to p=reject while that member's SPF record is producing spf=permerror from a budget-exhaustion condition the lookup-limit spoke catalogues.
• SPF mechanisms explained — the PORTFOLIO-WIDE-PER-MEMBER-SPF- MECHANISM-COORDINATION-DISCIPLINE companion to this multi-domain DMARC strategy. Where THIS page documents the per-portfolio-member DMARC- policy-mode coordination contract (per-brand independent rollout cadence with cross-brand RUA-stream aggregation, per-org-domain sp= / np= subdomain-policy coordination), the SPF-mechanisms-explained spoke is the RFC 7208 §5 per-mechanism operational reference whose four PORTFOLIO-WIDE-PER-MEMBER-MECHANISM- COORDINATION dimensions catalogue the per-portfolio-member SPF publication topology every multi- brand DMARC programme depends on: (i) per-portfolio-member include: cascade uniformity coordination — when a portfolio uses the SAME shared ESPs across all N portfolio members, EACH member's per-domain SPF record must publish the SAME include: cascade (each include: consuming the recursive RFC 7208 §5.2 resolution algorithm against the per-member 10-DNS-lookup budget); the SPF-mechanisms- explained spoke documents the per- include recursive resolution semantics + cross-domain include- domain authoritative-zone ownership semantics every portfolio member's per-domain SPF publication must apply uniformly; (ii) per- portfolio-member ip4: / ip6: explicit-IP enumeration coordination — when the portfolio operator elects to flatten per-portfolio-member SPF records down to explicit ip4 / ip6 enumerations (cost zero lookups), every portfolio member publishes the SAME ip4 / ip6 list against the same upstream ESP egress-IP pool; the SPF- mechanisms-explained spoke documents the per-CIDR publication semantics (ip4:<cidr> as inclusive CIDR-block match, ip6:<cidr> as IPv6 prefix-match, RFC 7208 §5.6 evaluation algorithm) every portfolio member's flattened SPF publication must apply uniformly, AND the per-portfolio-flattening cron-refresh cadence coordination across N portfolio members; (iii) per- portfolio-member mx: mechanism vs per-domain MX RR- set inheritance — when a portfolio member's SPF record publishes the mx or mx:<other> mechanism, the per-portfolio- member MX RR-set publication directly governs the SPF per-mechanism evaluation algorithm (the mx mechanism resolves the per- portfolio-member MX RR-set's target hostnames then performs per-MX-target A/AAAA expansion per RFC 7208 §5.4); the SPF- mechanisms-explained spoke documents the per-portfolio- member mx- mechanism semantics that couples the per-member MX RR- set publication discipline to the per-member SPF evaluation outcome; and (iv) per- portfolio-member -all qualifier commitment uniformity — every portfolio member's per-domain SPF record's trailing qualifier (-all hard-fail, ~all soft-fail, ?all neutral) represents the per-portfolio- member publication-commitment the cross-portfolio DMARC-ramp consumes; cross-portfolio p=reject rollout cannot safely proceed while ANY portfolio member is still publishing ~all or ?all because the per-member softfail/neutral qualifier produces non- dispositive DMARC-pass evidence in the rua-stream the portfolio operator depends on; the SPF-mechanisms-explained spoke documents the per- qualifier publication- commitment semantics the portfolio operator must apply uniformly across N portfolio members. Read the SPF- mechanisms-explained spoke alongside this multi-domain DMARC strategy when scoping the per-portfolio-member SPF publication topology — the per-portfolio-member per- mechanism publication coordination contract is the load-bearing per-member message-layer authentication primitive whose uniformity across N portfolio members the cross-portfolio DMARC- policy-mode coordination THIS page documents structurally consumes.
• Phishing protection — the PORTFOLIO-WIDE-ANTI-PHISHING- POSTURE-AS-MULTI-DOMAIN-DMARC-DOWNSTREAM- CONSUMER companion to this multi-domain DMARC strategy reference. Where THIS page documents the per-portfolio-member DMARC-policy-mode coordination contract (per-brand independent rollout cadence with cross-brand RUA-stream aggregation, per-org-domain sp= / np= subdomain-policy coordination, per-parked-domain p=reject publication, per-acquired-domain DMARC-coverage continuity), the phishing-protection spoke is the RECEIVER-SIDE ANTI- PHISHING-DEFENCE-STACK CATALOGUE documenting how the per-portfolio-member anti-phishing posture is the per-org- domain downstream consumer of the cross- portfolio DMARC-policy-mode coordination this page architects at FOUR per- portfolio-member-anti-phishing-control- coordination dimensions: (i) per- portfolio-member p=reject coverage uniformity as portfolio-wide direct-domain-spoofing receiver-side SMTP-bounce control — every portfolio member that reaches the terminal p=reject pct=100 DMARC posture closes the direct-domain- spoofing anti-phishing control class for THAT org-domain; the cross- portfolio uniformity contract on THIS page is the load-bearing coordination primitive every portfolio-wide anti- phishing programme depends on for portfolio-wide direct-domain-spoof defeat the phishing-protection spoke catalogues; (ii) per-parked- domain p=reject publication as anti-cousin-spoofing and anti-lookalike-domain guard — the cross-portfolio strategy's per- parked-domain p=reject publication discipline closes the per-parked-domain attacker-impersonation attack surface that the phishing- protection spoke catalogues under the cousin-and-lookalike-domain attacker- bypass control class; the per-portfolio- member parked-domain publication uniformity contract THIS page documents is the structural prerequisite for the per-portfolio anti-cousin-spoofing defence-stack closure; (iii) per- org-domain BIMI-display gating as per- brand portfolio-recognition anti- phishing visual signal — the per-portfolio-member 90-day rolling DMARC pass-rate gate the phishing- protection spoke catalogues as the BIMI-display-eligibility primary control is the per-org-domain downstream consumer of the per- portfolio-member p=reject deployment uniformity THIS page architects; the cross-portfolio coordination primitive is the load- bearing precondition for the per-brand BIMI-display anti-phishing visual signal at the recipient inbox-list surface; (iv) per-acquired- domain anti-phishing-coverage continuity discipline as M&A portfolio-integration anti-phishing risk-management control — every acquired-domain whose legacy DMARC posture lags the portfolio's terminal p=reject state introduces an anti-phishing coverage-gap the phishing-protection spoke catalogues as the per-acquired- domain residual-exposure class; THIS page's per-acquired-domain integration discipline is the portfolio-wide coordination contract every M&A-driven anti-phishing continuity programme depends on. Read the phishing-protection spoke alongside this multi-domain DMARC strategy reference when scoping the per- portfolio-member anti-phishing posture the cross-portfolio DMARC-policy-mode coordination THIS page architects structurally enables.
• SPF for Microsoft 365 — the PER-M365-TENANT-MULTI-ENVELOPE- DOMAIN-SPF-INCLUDE-CASCADE-COORDINATION- AS-LOAD-BEARING-PER-PORTFOLIO-MEMBER- ENVELOPE-AUTHORIZATION-PUBLICATION- DISCIPLINE companion to this multi- domain DMARC strategy reference. Where THIS page documents the cross-portfolio DMARC-policy-mode-progression coordination across N portfolio members (per-portfolio-member p=none → p=quarantine → p=reject per- envelope-domain policy publication, per- portfolio-member rua-aggregate consolidation, per-portfolio-member organisational-domain-vs-subdomain boundary discipline, per-portfolio- member M&A-onboarding coordination), the spf_for_microsoft_365 spoke documents the per-M365-tenant SPF-include-cascade publication coordination across primary- tenant + alias-tenant envelope-domains at FOUR per-M365-multi-envelope-domain coordination dimensions: (i) per- M365-tenant primary-domain + acquired- company alias-domain + brand-alias alias-domain SPF-include-cascade publication coordination AS LOAD- BEARING-PER-PORTFOLIO-MEMBER-ENVELOPE- DOMAIN-AUTHORIZATION publication- discipline complementary to the cross- portfolio DMARC-policy-mode coordination THIS page architects — every portfolio member onboarded into the M365 tenant requires per-envelope-domain include:spf.protection.outlook.com publication; the spf_for_microsoft_365 spoke documents the per-tenant multi- envelope-domain SPF-publication coordination whose preservation is the load-bearing prerequisite to the per- portfolio-member DMARC-aligned-SPF invariant the cross-portfolio policy- mode-progression THIS page architects depends on; (ii) per-M365- tenant primary-tenant + alias-tenant RFC 7208 §4.6.4 ten-DNS-lookup ceiling budget coordination AS PUBLICATION- BUDGET-DISCIPLINE-PRESERVATION across N portfolio members — M365's per-tenant include:spf.protection.outlook.com cascade itself consumes 5+ of the ten- lookup budget; portfolio members stacking SaaS-include + transactional- ESP-include + marketing-include cascades on top of the M365 cascade quickly exceed the budget; the spf_ for_microsoft_365 spoke documents the per-tenant publication-budget discipline whose preservation across N portfolio members is the load- bearing prerequisite to the per- portfolio-member DMARC-policy-mode- progression THIS page architects; (iii) per-M365-tenant primary- domain-vs-subdomain SPF-publication boundary AS LOAD-BEARING-PER- PORTFOLIO-MEMBER ORGANISATIONAL- DOMAIN-VS-SUBDOMAIN BOUNDARY- COORDINATION discipline — per-M365-tenant subdomain SPF-record publication (e.g., marketing.<domain>, transactional.<domain>, support.<domain>) must be coordinated with the per- portfolio-member organisational- domain DMARC sp= subdomain-policy publication; the spf_for_microsoft_365 spoke documents the per-tenant subdomain SPF- publication coordination whose preservation parallels the per- portfolio-member organisational- domain DMARC subdomain-policy coordination THIS page architects; (iv) per-M365-tenant M&A- onboarding SPF-include-cascade cutover-window coordination AS PER- PORTFOLIO-MEMBER MIGRATION- ONBOARDING-DISCIPLINE complementary to the cross-portfolio M&A DMARC- policy-mode-onboarding coordination THIS page architects — every M&A-acquired company onboarded into the M365 tenant requires per- envelope-domain SPF-include-cascade cutover from the acquired company's legacy SPF-publication to the per- M365-tenant SPF-include-cascade publication, with overlap-window coordination preventing per-source- IP authorization gaps; the spf_for_ microsoft_365 spoke documents the per-tenant M&A-onboarding SPF- cutover-window coordination whose preservation parallels the cross- portfolio M&A DMARC-policy-mode- onboarding coordination THIS page architects. Read the spf_for_ microsoft_365 spoke alongside this multi-domain DMARC strategy reference whenever the portfolio operator scopes a cross-portfolio M365-tenant SPF-publication coordination plan — the per-M365- tenant primary-domain-and-alias- domain SPF-include-cascade publication discipline the spoke catalogues IS the load-bearing per- portfolio-member envelope-MAIL-FROM authorization-publication primitive every cross-portfolio DMARC-policy- mode-progression THIS page architects depends on.
• DKIM failures explained — the PER-PORTFOLIO-MEMBER-DOMAIN DIAGNOSTIC-EVIDENCE-STREAM companion to this multi-domain DMARC strategy reference. Where THIS page architects the cross- portfolio DMARC-policy-mode- progression coordination across org-domain + sister-brand-domains + acquired-company-domains + per-product-subdomains, the DKIM-failures-explained spoke documents the four-class DKIM verdict-failure taxonomy (bodyhash-mismatch, signature-mismatch, permerror, temperror) the operator MUST diagnose INDEPENDENTLY for EACH portfolio member-domain before any per-domain ramp-advancement gate clears across the portfolio. Read THIS page when ARCHITECTING the cross-portfolio rollout coordination; read the DKIM-failures spoke when DIAGNOSING the per-member-domain DKIM-failure rows that BLOCK per-portfolio-member-domain ramp-advancement.
• SPF forwarding issues — the per-portfolio-member-domain forwarder-induced envelope-MAIL-FROM-IP- rewrite as cross-portfolio per-member-domain ramp-advancement-blocker companion to this cross-portfolio DMARC-policy-mode-progression coordination strategy. Where THIS page documents the multi-domain rollout architecture-of-record (per-portfolio organisational-domain + sister-brand-domain + acquired-company-domain + per-product- subdomain alignment-vs-failure attribution discipline, the per-member-domain RUA ingestion cadence, the per-member-domain ramp-advancement gate criteria, the cross- portfolio enforcement-floor coordination), the SPF-forwarding-issues spoke documents the per-message FORWARDER-INDUCED upstream cause that produces a recurring class of per-member-domain spf=fail rows operators MUST distinguish from spoofing-attribution rows BEFORE that member-domain's ramp can advance from p=none to p=quarantine to p=reject. Four PER-PORTFOLIO- MEMBER-DOMAIN-VS-FORWARDING-ATTRIBUTION cross-correlation axes the SPF-forwarding- issues spoke documents: (i) the per- member-domain recipient-side auto-forwarder attribution discipline — each portfolio member-domain receives its OWN per-source-IP per-day RUA-row stream with its OWN forwarder-induced spf=fail attribution pattern (iCloud forwarders, Gmail-forwarders, Outlook-forwarders, custom alias-forwarding services), and the operator MUST attribute per-member-domain rather than batch-attribute across the portfolio because a sister-brand-domain's forwarder population is typically structurally DIFFERENT from the acquired-company-domain's forwarder population; (ii) the per-member-domain mailing-list intermediary footprint diverges across the portfolio — per-product-subdomain mailing lists (newsletter@products.example.com, community@products.example.com) have a DIFFERENT mailing-list footprint than the org-domain corporate-announcements list, so the per-member-domain RUA-row stream surfaces DIFFERENT per-source-IP forwarder-attribution rows per portfolio member, and the per-member- domain ramp-advancement gate criteria MUST account for the per-member-domain mailing- list footprint INDEPENDENTLY; (iii) the per-member-domain ARC- trust-anchoring rescue path operates INDEPENDENTLY per portfolio member — the org-domain's known-trustworthy ARC sealer population is structurally INDEPENDENT of the acquired-company-domain's ARC sealer population, so per-member-domain ARC-trust- chain attribution MUST be evaluated per portfolio member rather than batch-evaluated across the portfolio; (iv) the cross-portfolio enforcement-floor coordination STRUCTURALLY DEPENDS on per-member-domain forwarding-attribution-vs-spoofing-attribution discipline — a per-member-domain ramp-advancement gate cannot clear until that member-domain's forwarder-induced spf=fail row class has been distinguished from genuine spoofing-attribution rows, so the cross- portfolio enforcement-floor cadence is gated by the SLOWEST per-member-domain forwarding- attribution-discipline closure. Read THIS page when ARCHITECTING the cross-portfolio rollout coordination; read the SPF-forwarding- issues spoke when DIAGNOSING the per-member- domain forwarder-induced spf=fail rows that BLOCK per-portfolio-member-domain ramp-advancement.
• DKIM canonicalization — the per-portfolio per-member-domain DKIM canonicalization-mode coordination as load-bearing cross-portfolio ramp- advancement prerequisite companion to this multi-domain DMARC strategy reference. Where THIS page documents the per-portfolio cross-member-domain DMARC- rollout coordination, the DKIM canonicalization spoke documents the per- message canonicalization-mode byte- normalization grammar whose per-publisher per-member-domain publication-discipline coordination is the LOAD-BEARING per- portfolio cross-member-domain authentication-publication-discipline prerequisite every cross-portfolio rollout STRUCTURALLY DEPENDS on. Four DKIM- CANONICALIZATION-VS-PORTFOLIO-COORDINATION cross-correlation axes the canonicalization spoke documents: (i) per-portfolio cross-member-domain canonicalization-mode publication divergence STRUCTURALLY GATES per-portfolio cross-member-domain intermediary-mutation footprint coordination — a per-portfolio publisher operating brandA.com with c=simple/simple AND brandB.com with c=relaxed/relaxed emits per- member-domain divergent per-receiver per- day body-hash-mismatch attribution that the cross-portfolio operator-side ramp- advancement-decision discipline MUST reconcile member-domain-by-member-domain BEFORE the cross-portfolio enforcement- floor cadence advances; (ii) per- portfolio cross-member-domain intermediary- mutation footprint coordination STRUCTURALLY GATES per-member-domain ramp-advancement cadence — a per-portfolio member-domain whose primary audience is mailing-list-routed (developer ML, customer- community ML) emits per-member-domain per- receiver per-day dkim-fail-row cliffs that the per-publisher cross-portfolio operator MUST attribute to per-intermediary footer- injection mutation rather than per- publisher per-domain spoofing-attribution BEFORE that member-domain's ramp can advance; (iii) per-member-domain c=simple vs c=relaxed publication choice STRUCTURALLY GATES per- portfolio cross-member-domain rollout- coordination — per-portfolio publishers operating multiple member- domains MUST coordinate per-member-domain canonicalization-mode publication choices to a per-portfolio standard (typically c=relaxed/relaxed per-portfolio cross-member-domain) BEFORE the per- portfolio operator-side ramp-coordination decision discipline can consume comparable per-member-domain per-receiver per-day attribution evidence; (iv) per- member-domain ramp-advancement STRUCTURALLY DEPENDS on per-portfolio cross-member- domain canonicalization-mode body-hash coverage-rate baseline — the cross-portfolio enforcement-floor cadence is gated by the SLOWEST per-member-domain DKIM-aligned-pass coverage-rate baseline which in turn depends on the per-member- domain canonicalization-mode-vs- intermediary-mutation-footprint coordination the per-portfolio operator MUST maintain for cross-member-domain ramp-advancement cadence parity. Read THIS page when ARCHITECTING the per-portfolio cross- member-domain DMARC rollout coordination; read the DKIM canonicalization spoke when AUDITING the per-portfolio cross-member- domain canonicalization-mode publication discipline whose per-member-domain body- hash coverage-rate baseline is the LOAD- BEARING per-portfolio cross-member-domain authentication-publication-discipline prerequisite every cross-portfolio enforcement-floor cadence advancement STRUCTURALLY DEPENDS on.
• Email spoofing explained — the per-portfolio per-member-domain anti-spoofing posture coordination companion to this DMARC multi-domain strategy reference. Where THIS page documents the per-publisher per- portfolio cross-member-domain DMARC ramp-advancement coordination discipline (the per-member-domain rollout sequencing, the per-portfolio p=quarantine-to-p=reject parity floor, the per-portfolio cross-member-domain publication-discipline regression budget), the email-spoofing spoke is the PER-ATTACK-CLASS REFERENCE documenting the per-publisher per- domain attack-surface catalogue (the canonical From-domain-spoofing pattern, the per-receiver display-name-only- rendering display-name-spoofing pattern, the per-publisher per- portfolio lookalike-domain registration attack-class, the per-publisher per- portfolio subdomain-spoofing attack- class) whose per-attack-class defender- side mitigation discipline the per- portfolio operator MUST coordinate across member-domains to maintain portfolio-wide anti-spoofing-floor parity. Four PORTFOLIO-ANTI-SPOOFING- POSTURE-COORDINATION cross-correlation axes the email-spoofing spoke documents: (i) per-portfolio cross-member- domain From-domain-spoofing attack- surface uniformity — every unprotected member-domain in the portfolio is a per-attacker-targetable From-domain-spoofing vector regardless of the protected-member-domain ramp state; (ii) per-portfolio lookalike-domain registration attack- class as portfolio-perimeter coordination primitive — the per-publisher per-portfolio lookalike-domain registration discipline (proactive defensive registration of homograph and visually-similar member-domain variants) is the load-bearing portfolio-perimeter coordination primitive the per-portfolio operator applies BEFORE the per-publisher per- member-domain p=reject anti-spoofing- floor parity rollout; (iii) per- portfolio subdomain-spoofing attack- class as per-member-domain organizational- policy sp=-tag publication- discipline coordination input — the per-publisher per-portfolio subdomain-spoofing attack-class catalogue is the upstream determinant of the per-member-domain organizational- policy sp=reject publication- discipline the per-portfolio operator publishes to close per-member-domain per-subdomain attack-surface; (iv) per-portfolio cross- member-domain authentication-publication- discipline-vs-anti-spoofing-floor parity rollout — the per-publisher per-portfolio cross-member-domain DMARC ramp-advancement coordination structurally depends on per-member- domain per-attack-class anti-spoofing- floor parity discipline. Pair this page (the per-portfolio cross-member- domain DMARC ramp-advancement coordination reference) with the email- spoofing spoke (the per-attack-class catalogue reference) when designing the per-portfolio cross-member-domain anti-spoofing-floor parity rollout discipline.
• DANE explained — the per-publisher per-MX DANE TLSA- record transport-layer cryptographic-trust- anchor publication-discipline companion to this DMARC multi-domain-strategy reference. Where THIS page documents the per-publisher per-portfolio cross-member-domain DMARC ramp-advancement coordination discipline (the per-member-domain rollout sequencing, the per-portfolio p=quarantine-to-p=reject parity floor, the per-portfolio cross- member-domain publication-discipline regression budget), the DANE-explained spoke is the PER-PUBLISHER-PER-MX-RFC-7672- TLSA-RECORD-AS-DNSSEC-ANCHORED-TRANSPORT- LAYER-CRYPTOGRAPHIC-TRUST-ANCHOR-PUBLICATION reference documenting the per-publisher per- MX-host TLSA-record byte-grammar publication and the per-MX cryptographic-trust-anchor binding gate that authenticates the receiving-side STARTTLS cert at the transport layer. Four CROSS-PORTFOLIO- TRANSPORT-LAYER-CRYPTOGRAPHIC-PUBLICATION- COORDINATION dimensions the DANE-explained spoke documents: (i) per-portfolio cross-member-domain DANE TLSA-publication- coverage uniformity discipline — the per-portfolio operator coordinates DANE TLSA-publication coverage across N member- domains so that every member-domain MX- host's transport-layer cryptographic-trust- anchor publication uniformly meets the portfolio's transport-layer authentication- and-encryption-floor parity baseline; (ii) per-portfolio cross-member- domain DNSSEC zone-signing-coverage uniformity as upstream prerequisite — DANE TLSA-record verification requires DNSSEC-signed zones, so the per-portfolio cross-member-domain DNSSEC zone-signing- coverage uniformity is the load-bearing upstream prerequisite for per-portfolio cross-member-domain DANE publication coordination — every member-domain not DNSSEC-signed is a per-portfolio cross- member-domain DANE-coverage parity gap; (iii) per-portfolio cross-member- domain TLSA-rotation overlap-window coordination cadence — the per- publisher per-MX-host TLSA-rotation overlap- window discipline must be coordinated across the portfolio's complete MX-host inventory so that no member-domain MX-host experiences a TLSA-rotation-induced transport-layer STARTTLS-verification cliff during a per- portfolio cross-member-domain cryptographic-anchor-publication coordinated rotation; (iv) per-portfolio cross- member-domain MTA-STS-vs-DANE publication- discipline-choice coordination — the per-portfolio operator coordinates the per-member-domain choice between RFC 8461 MTA-STS HTTPS-policy-host publication and RFC 7672 DANE TLSA-record publication so that the portfolio's cross-member-domain transport-layer cryptographic-anchor- publication choice produces uniform transport-layer authentication-and- encryption-floor parity regardless of which publication-discipline a given member-domain adopts. Read the DANE-explained spoke alongside this DMARC multi-domain-strategy reference when DESIGNING the per-portfolio cross-member-domain transport-layer cryptographic-trust-anchor-publication coordination discipline that pairs the per- portfolio cross-member-domain DMARC application-layer ramp-advancement coordination this page documents with the per-portfolio cross-member-domain DANE transport-layer cryptographic-anchor- publication coordination the DANE-explained spoke documents.
• Email security glossary — the per-portfolio cross-member-domain threat-and-defense vocabulary reference whose ~80 per-term DefinedTerm definitions name the look-alike and impersonation tactics every multi-domain portfolio operator coordinates anti-spoofing posture across. Where THIS page documents the per-portfolio cross-member-domain DMARC ramp-advancement coordination discipline (the per-org-domain + sister-brand-domain + acquired-company-domain + per-product- subdomain ramp-phase coordination, the per-member-domain Phase-1 authentication- leg-health baseline coordination, the cross-portfolio p=reject enforcement-floor coordination), the email-security-glossary spoke is the PER-PORTFOLIO-CROSS-MEMBER-DOMAIN- THREAT-TAXONOMY reference documenting the attacker-side look-alike registration tactics every portfolio operator must catalogue alongside the legitimate portfolio member-domain inventory. Four CROSS-PORTFOLIO-THREAT-TAXONOMY- COORDINATION dimensions the security- glossary spoke documents: (i) look-alike registration taxonomy as per-portfolio cross-member- domain adjacent-attack-surface inventory — the typosquatting, homograph (IDN-homoglyph), cousin-domain, and combosquatting tactics the security glossary catalogues are the per-attacker per-portfolio member-domain adjacent- attack-surface inventory the portfolio operator must defensive-register against ALONGSIDE the per-member-domain DMARC ramp coordination THIS page documents (the attacker registers examp1e.com / еxample.com [Cyrillic е] / example-corp.com against each portfolio member-domain independently); (ii) OSINT reconnaissance vocabulary as per-portfolio cross-member- domain attacker-side intelligence-gathering catalogue — the Shodan / Censys / Certificate Transparency / WHOIS / Have-I- Been-Pwned reconnaissance vocabulary the security glossary catalogues is the per- attacker per-portfolio member-domain intelligence-gathering catalogue the portfolio operator coordinates per-member- domain CT-log monitoring against (the attacker enumerates portfolio member-domain CT log entries to discover new acquisition- side member-domains, M&A-renamed member-domains, and per-product-subdomain member-domains); (iii) defense-in-depth layer vocabulary as per-portfolio cross-member- domain control-stack coordination catalogue — the secure-email- gateway (SEG) / EDR / XDR / MDR / zero- trust / phishing-resistant-MFA / DLP / conditional-access / browser-isolation defense-stack vocabulary the security glossary catalogues is the per-portfolio cross-member-domain control-stack coordination catalogue the portfolio operator coordinates alongside the per- member-domain DMARC ramp coordination THIS page documents; (iv) SOC / SIEM / SOAR / runbook vocabulary as per-portfolio cross-member- domain operations-layer playbook catalogue — the SOC / SIEM / SOAR / threat-hunting / playbook / runbook / NIST 800-61 IR lifecycle vocabulary the security glossary catalogues is the per- portfolio cross-member-domain operations- layer playbook catalogue the portfolio operator coordinates per-member-domain DMARC-aggregate-report SOC review cadence against. Read THIS page when AUTHORING the per-portfolio cross-member-domain DMARC ramp coordination discipline; read the email-security-glossary spoke when CO-AUTHORING the per-portfolio cross- member-domain threat-and-defense vocabulary catalogue whose per-attack- class defender-side mitigation discipline the per-member-domain DMARC ramp coordination THIS page documents structurally participates in.
• MX records — the per-member-domain MX-RECORD-MAIL- DELIVERY-TOPOLOGY companion to this per- portfolio cross-member-domain DMARC ramp coordination reference. Where THIS page documents the per-portfolio cross-member- domain DMARC governance discipline — per- member-domain DMARC-record publication cadence, per-portfolio per-member-domain SPF / DKIM authentication pre-condition verification, per-portfolio per-member- domain alignment-pass-rate KPI coordination, per-portfolio per-member- domain p=quarantine → p=reject ramp-step cadence, the per-portfolio cross-member-domain parked-domain / brand-protection-domain / sub-brand-domain inventory classification, the per-portfolio per-member-domain reporting-aggregation discipline — the MX-records spoke documents the per- member-domain MX-record-published mail- delivery topology that constitutes the per-portfolio cross-member-domain mail- infrastructure inventory axis the DMARC ramp coordination materially depends on. The composition operates through three per-portfolio per-member-domain MX- records-and-DMARC-strategy dependencies the per-portfolio governance discipline relies on: (i) per-member-domain MX-record null-MX (0 . per RFC 7505) publication marks the per-member-domain as a NO-MAIL parked-domain that needs an immediate p=reject DMARC ramp without any SPF / DKIM pre-condition — the per-portfolio cross-member-domain inventory classifier reads per-member- domain MX-record presence to distinguish active-mail-sending members from parked- no-mail members and routes each through the per-classification ramp policy; (ii) per-member-domain MX-record per-receiver- MX-host vendor distribution (Microsoft 365 tenants, Google Workspace tenants, AWS SES routes, self-hosted Postfix/Exim MTAs) determines the per-portfolio cross- member-domain authentication-vendor diversity surface the per-portfolio operator must coordinate alignment- verification across — different per- receiver-MX-host vendors emit different per-member-domain DMARC-aggregate-report payloads, requiring per-portfolio per- vendor-class normalisation in the aggregation pipeline; (iii) per-member- domain MX-record publication-completeness is the per-portfolio cross-member-domain baseline DNS-RR publication discipline whose per-member-domain publication- gaps surface as per-member-domain mail- delivery regressions that pollute per- portfolio cross-member-domain DMARC- aggregate-report KPI signal with non- DMARC-attributable per-message bounce regression noise. Read THIS page when AUTHORING the per-portfolio cross-member- domain DMARC ramp coordination discipline; read the MX-records spoke when INVENTORYING the per-portfolio cross- member-domain mail-delivery-topology classification axis whose per-member- domain MX-record null-MX-vs-active-MX distinction the per-portfolio cross- member-domain DMARC-ramp-policy assignment discipline materially routes against.
• Email deliverability fundamentals — the per-publisher per-domain inbox- placement-rate-as-business-outcome primitive whose four per-portfolio cross- member-domain deliverability-coordination- discipline coupling dimensions THIS multi- domain DMARC strategy reference materially coordinates: (i) per-publisher per-portfolio per-member-domain DMARC- aligned-pass-rate-floor convergence as per-member-domain deliverability-floor coordination primitive — heterogeneous per- member-domain authentication-publication- completeness creates per-member-domain deliverability divergence the per- portfolio operator MUST normalise through per-member-domain SPF + DKIM + DMARC publication-discipline-floor convergence BEFORE per-member-domain inbox-placement- rate floors can be portfolio-wide guaranteed — per-portfolio deliverability convergence IS per-member- domain publication-discipline convergence; (ii) per-publisher per-portfolio per-member-domain per-receiver per- mailbox-provider per-sender-reputation cross-contamination protection through per-member-domain reputation-isolation publication-discipline — when ONE per- member-domain takes a per-receiver per- mailbox-provider per-sender-reputation regression hit, the per-portfolio cross- member-domain operator MUST audit whether the regression CONTAMINATES sibling per- member-domain reputation through shared- egress-IP-pool / shared-DKIM-private-key / shared-SPF-include-chain infrastructure — per-portfolio per-member-domain reputation-isolation IS a per-publisher per-portfolio deliverability- floor-defense-discipline primitive; (iii) per-publisher per-portfolio per-member-domain warmup-and-ramp coordination discipline — new per-member- domain additions to the portfolio require per-receiver per-mailbox-provider per- sender-reputation warmup cadences the per-portfolio operator coordinates per- member-domain to avoid per-receiver per- mailbox-provider per-sender bulk-mail- velocity-trigger spam-filter penalty regressions that contaminate per- portfolio cross-member-domain per-receiver reputation — per-portfolio warmup-coordination IS per-portfolio deliverability-ramp-coordination; (iv) per-publisher per-portfolio cross- member-domain per-receiver per-mailbox- provider per-day inbox-placement-rate per-member-domain dashboard segmentation as load-bearing per-portfolio analytics- team observability primitive — the per- portfolio operator's per-receiver per- mailbox-provider per-day reputation- monitoring runbook MUST consume per- member-domain Sender-Score / Postmaster- Tools / SNDS-dashboard / Yahoo-Sender-Hub per-day reputation-feedback per-member- domain segmented to detect per-member- domain regression BEFORE cross-member- domain reputation contamination propagates — per-portfolio observability-discipline IS per-portfolio per-member-domain deliverability-floor- protection-discipline. Read the email- deliverability fundamentals spoke alongside this multi-domain DMARC strategy reference when coordinating per-portfolio per- member-domain deliverability-floor convergence, when authoring per-portfolio per-member-domain reputation-isolation publication-discipline runbooks, when planning per-portfolio per-member-domain warmup-and-ramp cadences for new portfolio additions, or when authoring per-portfolio cross-member-domain per-receiver per- mailbox-provider per-day reputation- monitoring observability runbooks the per- portfolio operator's deliverability operator-discipline floor materially consumes.
• SPF for Google Workspace — the per-Workspace-tenant per-custom- domain envelope-MAIL-FROM-layer SPF publication-discipline companion to this per-publisher per-portfolio-domain DMARC multi-domain strategy reference. Where THIS page documents the per-publisher per-portfolio-domain DMARC publication strategy across per-portfolio member domains (per-organisational-domain canonical baseline + per-subdomain sp= subdomain-policy delegation + per-portfolio member- domain-specific DMARC publication coordination + per-portfolio per-member- domain per-receiver-side per-day aggregate-report ingestion), the SPF-for- Google-Workspace spoke documents the per- Workspace-tenant per-custom-domain envelope-MAIL-FROM-layer SPF publication (v=spf1 include:_spf.google.com -all canonical baseline, per-tenant per- custom-domain Gmail-egress include:_spf.google.com macro expansion, per-tenant per-third- party-sender SPF-flattening discipline against the RFC 7208 §4.6.4 ten-DNS- lookup ceiling). Four per-multi-domain- portfolio SPF-publication coordination coupling dimensions matter at the per- portfolio member-domain publication- portfolio boundary: (i) per-Workspace- tenant per-portfolio-member-domain SPF publication uniformity — the per-tenant per-portfolio per-member-domain v=spf1 include:_spf.google.com -all publication-discipline IS replicated per-member-domain at the per-portfolio per-member-domain DNS-zone publication boundary; the per-tenant per-member- domain SPF-aligned-pass-rate floor the SPF-for-Google-Workspace spoke documents IS the per-portfolio member-domain envelope-layer authentication-leg input every per-tenant per-portfolio per-member- domain DMARC composite-verdict-evaluation THIS page documents depends on; (ii) per- Workspace-tenant per-portfolio per- member-domain Gmail-egress shared- infrastructure consideration — the per- tenant Gmail-egress SHARES the per- tenant _spf.google.com macro expansion across ALL per-tenant per- portfolio member domains; per-tenant per-member-domain operator awareness of the shared include:_spf.google.com per- member-domain publication discipline IS the per-portfolio member-domain envelope-layer composition primitive THIS page documents coordination floor for; (iii) per-Workspace-tenant per-portfolio per-member-domain SPF DNS-lookup-budget coordination — per-tenant include:_spf.google.com consumes ~3 DNS lookups per-member-domain of the RFC 7208 §4.6.4 ten-DNS-lookup budget; per-tenant per-portfolio per- member-domain per-third-party-sender SPF composition (per-member-domain marketing SPF, per-member-domain transactional SPF, per-member-domain SaaS-relay SPF) must coordinate with the per-tenant Gmail- egress include:_spf.google.com DNS-budget consumption to stay below the per-member-domain DNS-lookup ceiling THIS page documents per-portfolio coordination floor for; (iv) per-Workspace-tenant per- portfolio composite multi-domain publication-portfolio coordination — the per-tenant per-portfolio composite SPF + DKIM + DMARC + ARC + MTA-STS + TLS-RPT publication-portfolio THIS page's per- portfolio multi-domain DMARC strategy component IS the per-portfolio per- member-domain application-layer policy- publication primitive, the SPF-for- Google-Workspace spoke's per-tenant per- member-domain envelope-MAIL-FROM-layer publication-discipline IS the per- portfolio per-member-domain envelope- layer publication primitive, both consumed together at the per-tenant per- portfolio per-member-domain publication- portfolio-coordination floor. Read THIS page when AUTHORING the per-publisher per-portfolio-domain DMARC multi-domain strategy discipline; read the SPF-for- Google-Workspace spoke when AUTHORING the per-Workspace-tenant per-portfolio per-member-domain envelope-MAIL-FROM- layer SPF publication that per-tenant per-portfolio multi-domain DMARC strategy THIS page documents depends on as the per-portfolio per-member-domain envelope- layer authentication-leg primitive.
• DKIM cryptography basics — the PORTFOLIO-WIDE-PER-MEMBER-DOMAIN-DKIM- SIGNING-KEY-CRYPTOGRAPHIC-UNIFORMITY companion to this multi-domain DMARC strategy reference. Where THIS page documents the portfolio-scale per-member-domain DMARC publication coordination workflow (per- member-domain DMARC p= / sp= / np= tag coordination, per-member-domain RUA / RUF aggregation strategy, per-member-domain cohort-comparison reporting), the DKIM- cryptography-basics spoke is the CRYPTOGRAPHIC-PRIMITIVE-CHOICE-UNIFORMITY reference governing the per-publisher per- portfolio-member upstream DKIM-signing cryptographic posture every member-domain DMARC publication consumes. Four portfolio- wide cryptographic-coordination dimensions: (i) PER-PORTFOLIO-MEMBER-KEY-SIZE-UNIFORMITY (mixing RSA-2048 on member A with RSA-1024 on member B fragments the per-publisher cryptographic-strength posture across receivers applying per-domain-strength gating; the uniform RSA-2048 floor per RFC 8301 §3 is the load-bearing per-portfolio baseline); (ii) PER-PORTFOLIO-MEMBER-ALGORITHM- UNIFORMITY-VS-RECEIVER-COMPATIBILITY (mixing Ed25519 RFC 8463 on member A with RSA-2048 on member B forces per-receiver per-member- domain compatibility-window awareness — the per-portfolio rollout strategy must sequence Ed25519 adoption uniformly across all members rather than per-member); (iii) PER-PORTFOLIO-MEMBER-KEY-ROTATION-CADENCE- COORDINATION (uniform per-portfolio-member annual or semi-annual rotation cadence avoids per-member-domain key-age dispersion that fragments per-publisher per-rotation- boundary aligned-pass-rate cohort dynamics); (iv) PER-PORTFOLIO-MEMBER-COMPOSITE- CRYPTOGRAPHIC-AND-DNS-PUBLICATION-PORTFOLIO (per-member-domain DKIM cryptographic- primitive choice composes with per-member- domain SPF + DMARC + MTA-STS + TLS-RPT DNS-publication portfolios at the per- publisher per-portfolio-member composite authentication-and-encryption publication- discipline floor THIS page documents coordination of). Read the DKIM-cryptography- basics spoke alongside this multi-domain strategy guide when AUTHORING the per- portfolio cryptographic-primitive-choice publication discipline, when PLANNING per- portfolio-member uniform DKIM key-rotation cadences, or when AUDITING per-portfolio cryptographic-strength posture against per-receiver per-domain compliance floors.
• DKIM troubleshooting
• DNS propagation — the DNS-timing companion to this multi-domain strategy guide. Where this page coordinates per-publisher per-portfolio per-primary-domain + per-secondary-domain + per-parked-domain DMARC publication across a multi-domain estate (the shared key-rotation calendar, the staged p=none → p=reject ramp per member domain, the parked-domain p=reject + -all posture), the DNS-propagation spoke documents the timing constraint that gates each staged change: every member domain's TXT-RR edit is governed by its own per-record TTL and negative-cache window, so a portfolio-wide rollout cannot treat a change as live the moment it is published — the operator must wait out the propagation window, verified per member domain against the RUA aggregate stream, before advancing the cross-portfolio ramp gate. A staggered rollout that ignores propagation timing produces transient per-member-domain temperror rows that are easily misread as a member-domain misconfiguration. Read the DNS-propagation spoke when sequencing record changes across the domain family this strategy page coordinates so the per-member-domain TTL windows are budgeted into the ramp schedule.
• SPF PermError vs TempError
• SPF explained (the per-domain v=spf1 envelope-sender authorization record, its mechanism set, and the -all/~all terminal qualifier per RFC 7208) — a multi-domain DMARC portfolio needs a correctly-published, separately-maintained SPF record on every member sending domain AND a neutral or v=spf1 -all record on every non-sending parked domain in the family; read the SPF primer to ground the per-member-domain SPF leg this strategy page coordinates across the portfolio before sequencing the per-domain enforcement ramp.
• TLS-RPT record syntax — the PER-MEMBER-DOMAIN-TRANSPORT-LAYER-REPORTING-PUBLICATION companion to this multi-domain DMARC strategy: a portfolio operator publishes a _smtp._tls.<member-domain> TXT-RR on every member sending domain exactly as it publishes the per-member _dmarc.<member-domain> record this page coordinates — the TLS-RPT record gives the portfolio per-member transport-layer STARTTLS-failure visibility alongside the per-member DMARC aggregate-reporting stream, so both per-member DNS-publication disciplines are sequenced together across the domain family. Read the TLS-RPT-record-syntax spoke when extending a multi-domain portfolio's per-member DNS publication discipline from application-layer DMARC policy into transport-layer TLS reporting.
• Microsoft SNDS + JMRP monitoring — ESP-style and multi-stream senders live or die by per-IP reputation: SNDS grades every registered sending IP GREEN/YELLOW/RED at Microsoft and JMRP returns each Outlook.com Junk click as an ARF complaint report.

14. Audit your portfolio

DMARC Analyzer's free Domain Security Checker performs live DMARC + SPF + DKIM + MTA-STS + BIMI + DNSSEC lookups against any domain - run it against every domain in your portfolio inventory to surface the current posture per domain in one pass. The DNS Record Generator builds syntactically-correct DMARC records with sp= + np= + null SPF + null MX bundles for one-shot parked-domain hardening. Imported DMARC aggregate reports (via includes/DmarcParser.php) plus parsed forensic reports (via includes/ForensicReportParser.php) drive the dashboard that groups by reported domain for portfolio-level visibility.

Audit my portfolio Sign up — Free plan