Dmarc Record Builder Laravel Package

Product Decisions This Supports

• Build vs. buy on DMARC record generation: the alternative is hand-rolled string concatenation plus ad-hoc validation scattered through the codebase. v4 removes all runtime dependencies (webmozart/assert, illuminate/collections), so adopting it no longer pins us to a Laravel major or pulls transitive packages — it can live in any PHP 8.3+ service, including non-Laravel ones.
• DMARCbis roadmap alignment: RFC 9989 drops pct and ri. v4 is standards-current. This forces a product decision: if our UI/API currently exposes pct or interval to customers, we must decide now whether to remove those controls, keep them and pin v3, or wrap the library to keep emitting legacy tags.
• Gradual enforcement policy is a customer-facing decision, not a library detail: pct is how most organizations ramp from p=none to p=reject safely. v4 cannot express it. That's a real capability gap for the next 12–24 months of DMARCbis transition, and it should be scoped explicitly rather than absorbed silently.
• Fit for multi-tenant and per-domain email auth features: SaaS admin panels, ESP/onboarding flows, and agency tooling that construct, validate, and store a DMARC record per domain are the primary use cases.
• Parse round-trip risk: parse() now treats pct/ri as unknown tags and drops them on re-cast. Any flow that reads a customer record, edits it, and republishes will silently erase their staged rollout. This needs a product guard (preserve original string, or block edit-rewrite until DMARCbis readiness is decided).

When to Consider This Package

Consider adopting (or upgrading) when:

• You generate DMARC TXT records programmatically rather than storing opaque, hand-edited strings.
• You want validated construction at the boundary (invalid rua/ruf, bad policy values, malformed addresses).
• Zero transitive dependencies and no Laravel-major coupling matter to you — long-lived apps, multi-framework estates, or supply-chain review.
• You are targeting PHP 8.3+ and DMARCbis.

Look elsewhere, or deliberately stay on v3, when:

• You need pct/ri for phased enforcement. v4 cannot express them, and dropping them changes customer-facing behavior.
• You need DNS publication, record lookup/verification, or aggregate report (RUA/RUF) ingestion and analysis — this package only builds the record string.
• You are on PHP ≤8.2 with no upgrade path before the December 2026 EOL.
• You need a full DMARC lifecycle product (alignment checks, monitoring, report dashboards) rather than a builder.

How to Pitch It (Stakeholders)

Executives: This is a small, single-purpose library that removes a maintenance liability. v4 has zero runtime dependencies — it no longer pins us to a Laravel version or drags in transitive packages, which is one less item in supply-chain review and one less blocker at framework upgrade time. It also puts us ahead of DMARCbis (RFC 9989), the standards revision that retires the pct and ri tags. The upgrade cost is bounded and mechanical: PHP 8.3, delete pct()/interval() calls, adjust one catch block. Generated records are otherwise unchanged.

Engineering: v4 is a clean break but a shallow one. The API surface we depend on — builder, create(), parse(), validation — is intact apart from pct()/interval(), which are gone along with their constructor/create() arguments and $record->pct/$record->interval properties. Validation now throws CbowOfRivia\DmarcRecordBuilder\Exceptions\InvalidDmarcRecordException, which extends \InvalidArgumentException with unchanged messages — so catching \InvalidArgumentException is a no-op migration; only code catching Webmozart\Assert\InvalidArgumentException by name needs editing. PHP 8.3 is the new floor and CI covers 8.3–8.5. One design caveat to handle deliberately: parse() now drops pct/ri on re-cast, so any read-edit-rewrite path will strip a customer's staged enforcement — preserve the original record string or gate that flow until we settle the DMARCbis posture.