Phase 3 -- Implementation Suggestions

Forward-looking suggestions raised during Phase 3 implementation that did not become part of Phase 3’s scope but that future phases should consider. Each is tagged with the phase that should evaluate it.

S-1: Encode DQ-R1-014 — Postmark Sender Signature granularity per partition (Phase 4)

A new decision-log entry should be added for Phase 4 pinning the Sender Signature shape:

• Granularity: one Sender Signature per partition sub-zone (prod.ardamails.com, demo.ardamails.com, dev.ardamails.com, stage.ardamails.com, kyle.ardamails.com), each anchored at that sub-zone’s apex. Leaves within a partition (per-tenant sub-domains) inherit the partition’s DKIM key.
• Reputation isolation: each partition has its own DKIM d= value, so receiver-side reputation is independent per partition (a noisy-neighbor partition cannot affect another’s deliverability).
• arda.ardamails.com Sender Signature stays. It is the Corporate-instance-group Signature; siblings (per-partition sub-zones) are independent of it. The ardamails.com apex is not a verification target.
• Per-tenant Signatures are deferred to Phase 5b when tenants exist. If any tenant has an isolation requirement (regulatory, brand, abuse-risk), Phase 5b can opt that tenant into its own Sender Signature.

The sendingDomainPlacement() function introduced in Phase 3 generalises trivially to partitions: the corporateZoneName argument becomes a more general “verification-anchor zone name”, consumed identically by Phase 4 stacks. The construct DnsEmailRecords is already shape-neutral after the Phase 3 refactor.

S-2: Add SPF / DMARC at each per-partition sub-zone (Phase 4)

Phase 3 places SPF (v=spf1 include:spf.mtasv.net ~all) and DMARC (v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:dmarc-reports@arda.cards) at arda.ardamails.com. The same pattern applies to each partition sub-zone in Phase 4. Two considerations:

• SPF at the sender’s From: domain is not load-bearing for envelope-SPF (Postmark’s pm.mtasv.net is the envelope) but is required for DMARC alignment when the From: domain matches the partition sub-zone.
• DMARC at the per-partition sub-zone (_dmarc.<partition>.ardamails.com) lets each partition have its own policy and reporting address. Or use a single DMARC policy at _dmarc.ardamails.com with sp= (subdomain policy) and accept that all partitions share the same policy.

Recommendation: per-partition DMARC, with rua=mailto:dmarc-reports@arda.cards reused. Lets future partition-specific tuning (p=reject for prod, p=none for dev) happen without changing the apex.

S-3: Apex ardamails.com defensive SPF (Phase 4 or sooner)

The ardamails.com apex has no SPF record today and never sends mail (it is purely a parent for delegation). Publishing v=spf1 -all at the apex tells receivers “no mail is authorized from ardamails.com directly”, defending against spoofing of the bare apex. Cheap; nice to have. Can land in Phase 4 alongside the per-partition SPF additions.

S-4: Generalise sendingDomainPlacement for non-Corporate uses (Phase 4)

The function signature today takes sendingSubdomain: string; corporateZoneName: string. The argument names are Corporate-specific even though the function’s mechanics are zone-agnostic. Phase 4 will consume it with partition-shaped inputs (sendingSubdomain: "<tenant>"; corporateZoneName: "<partition>.ardamails.com") — which works, but the parameter name reads strangely. Suggest a renamed-and-aliased version when Phase 4 lands its first consumer:

// Renamed parameters; keep the existing one as a compatibility wrapper for Phase 3.
function sendingDomainPlacement(args: {
  sendingSubdomain: string;
  verificationAnchorZone: string;  // was: corporateZoneName
}): SendingDomainPlacement;

Phase 3 consumers (Corporate) call with verificationAnchorZone = "arda.ardamails.com"; Phase 4 consumers call with verificationAnchorZone = "<partition>.ardamails.com". The function body is unchanged.

S-5: corporate-drift → mail-drift (Phase 4 or 5b)

tools/corporate-drift.ts and its workflow (corporate-drift.yml) are named after the Corporate instance group because that was the only mail surface in Phase 3. Phase 4 introduces per-partition mail; Phase 5b introduces per-tenant mail. The drift check pattern (assert Postmark state + DNS state + cross-seam agreement) is generic. Suggest renaming to mail-drift / mail-drift.yml with a parameterized scope (Corporate, per-partition, per-tenant) when Phase 4 needs the same shape of check for its sub-zones. The Phase 3 implementation can be the per-asset-pattern reference.

S-6: Workspace skill: “design-decision-as-code” (workspace)

The DQ-R1-009 incident is general enough to be a workspace skill. A short skill encoding the rule “decisions that constrain code in multiple places should be encoded as typed values or functions, with cross-seam assertions where two systems must agree” would help future projects (across infrastructure, operations, common-module) avoid the same shape of defect. Skill stub draft:

When a design decision (in decision-log.md, in a docstring, or in a runbook) constrains how more than one piece of code derives the same value, encode the decision as a typed value or function. Have every consumer read it. Add a cross-seam assertion (in a test or a drift check) that compares consumers’ derived values against each other or against a canonical computation.

To be raised with the workspace stewards as a candidate for workspace/instructions/claude/skills/.

S-7: Postmark account approval as a Phase 1 prerequisite (workspace / project template)

The post-Phase-B send-a-test was blocked by Postmark’s pending-account-approval (1-2 business day Compliance loop). For future projects that integrate with Postmark (or any third-party provider with a manual approval gate), the project’s Phase 1 (“External Resources Provisioning”) should:

• Submit the approval request as the first operator action (not after DNS + Sender Signature are set up).
• Track the approval ticket as a project artefact in the operator-checklist file.
• Block end-to-end send-a-test verification on approval (mark the verification step explicitly conditional in the project plan).

This is general enough to be a Phase 1 checklist item across all email-integration-shaped projects.