A successful direct delivery is not enough evidence for a stricter DMARC policy. A forwarding service changes the sending path, and a mailing list may alter signed content. Build a small test set that represents the routes the business actually needs. Evaluate authentication separately from delivery so that an exception at one receiver does not look like universal compatibility.
Establish the baseline
References: RFC 9989 §4.4, RFC 9989 §5.3.5.
Choose authorized sender and recipient accounts and harmless content. Record the From domain, envelope sender, sending IP, DKIM selector and signing domain. Keep a direct-delivery copy and trusted receiver authentication results. Capture the applicable DMARC policy and alignment mode at the test time. If the baseline is already misaligned, repair that sender before diagnosing forwarding.
Under RFC 9989, a passing aligned SPF or DKIM mechanism can satisfy DMARC. SPF pass under a forwarder's domain is not automatically aligned with the author's domain. RFC 6376 explains why signed-content preservation matters for DKIM. Record which mechanism survives rather than treating a green overall result as an explanation.
Exercise meaningful variants
References: RFC 6376 §3.4, RFC 8617 §7.2.1.
Include unchanged forwarding, envelope rewriting, list footer insertion, subject modification and any MIME transformation the real service performs. Test multiple legitimate message types, especially those with attachments or third-party sending paths. The relevant question is whether the transformation changes material covered by the actual signature and canonicalization, not whether the message looks identical in a client.
Keep a negative control whose aligned signature is deliberately invalid in an isolated lab. A receiver that accepts both the valid and invalid cases may be applying local policy. That observation is useful, but it does not prove both messages authenticate. If ARC is present, record chain validation, the sealer and the receiver's trust decision separately. RFC 8617 does not make every valid chain a delivery command. As verified on 8 November 2026, the RFC remains Experimental and an active draft proposes Historic status; consider that proposal before creating a new ARC dependency.
Read the reproducible fixture
References: RFC 6376 §6.
The retained lab signs one harmless author.test message with a temporary RSA key and verifies it with dkimpy. The direct case passes. An unchanged forwarded copy still verifies. An SRS-style envelope change also leaves DKIM valid, even though the simplified SPF identity is now forwarder.test and does not align. A footer appended to the signed body fails verification and the exact-domain DMARC model.
Each case retains the message digest, route IP, envelope identity, signing domain and verdict. The verification key is public; no private key is retained. Rerunning the original key-generating fixture would create fresh keys and therefore fresh message hashes; it was not rerun here. Expected verdicts remain stable. This is a reproducible local test, not a full SPF resolver, DMARC implementation, ARC validator or test of a commercial mailbox provider.
Decide whether to proceed
References: RFC 9989 §8.
Create a route matrix showing the tested sender, intermediary, receiver, message variant, authentication result and final disposition. Mark untested combinations as unknown. The sample matrix should include a direct control and a failing modification, not only successful messages selected after the fact. The lab's footer failure is a reason to hold that route for repair or a separately approved exception.
Use a controlled rollout with named rollback authority and monitoring appropriate to the provider's reporting delay. Do not assume historical percentage-policy recipes still apply to the current DMARC specification. Confirm current receiver and platform behavior, then preserve the before-and-after policy and message evidence. A policy change succeeds when legitimate critical routes continue working and the organization understands the remaining failures, not merely when a DNS checker sees a stricter value.
Retained controlled forwarding route
References: RFC 7208 §4, RFC 6376 §6, RFC 8601 §5.
The retained 7 November 2026 capture at 21:32:53 UTC records a separate fixture sending the signed message through real loopback SMTP connections. These network sessions were inspected, not rerun for this review. The origin binds to 127.0.0.2, the forwarder sends onward from 127.0.0.3, and the final receiver stores each message. These addresses are confined to the local machine. The direct, unchanged-forward, rewritten-envelope and footer cases each have an actual transaction trace with timestamps, envelope identities and final acceptance. The rewrite is an SRS-style domain substitution for this lab, not a complete SRS implementation.
Each receiving boundary computes SPF using pyspf 2.0.14 with explicitly injected local TXT answers, and DKIM using dkimpy with the retained public key. The receiver adds its own Authentication-Results and Received fields after evaluation. Those results are trusted only within this controlled fixture, where the inserting code and boundary are known. It does not accept arbitrary embedded pass text as its own verdict. DNS policy is static local input, not a claim about public DNS.
At the final receiver, SPF results are pass, fail, pass and pass respectively. DKIM results are pass, pass, pass and fail. The exact-domain alignment model therefore preserves DMARC authentication for the first three cases and fails the footer case. This is not full DMARC policy discovery. The lab deliberately stores even the failing message for inspection, so its 250 response is not evidence that an enforcing production provider would deliver it.
The exception example and rollout hold are tied to that historical footer route: the unchanged route preserves the signature, while the controlled intermediary's footer breaks it. Keep any allowance unapproved until its real scope, owner, expiry and receiver behavior are reviewed. These historical controlled transactions document the local route comparison; production mailbox-provider compatibility, real business-flow authorization and any operational exception approval remain unperformed.