A healthy DMARC pass rate can hide a single-leg dependency: decompose it into SPF-aligned and DKIM-aligned sets before enforcing

Context

DMARC passes if either SPF or DKIM aligns — Google states this explicitly: "only one of these needs to be aligned to meet the sender alignment requirements." That disjunction is usually described as redundancy. It can instead be a hidden single point of failure, and the aggregate pass rate cannot show you which.

The measurement

One source in a 7-day DMARC report:

volume 110    DMARC pass 98.18%    SPF aligned 11.82%    DKIM aligned 86.36%

98.18% pass looks fine. Now add the two alignment figures:

$$11.82% + 86.36% = 98.18% = \text{pass rate}$$

Exact, to the message, on 110 messages. Converting to counts: 13 pass via SPF only, 95 via DKIM only, 0 via both, 2 via neither. The two aligned sets are disjoint.

So every single passing message rides exactly one mechanism. There is no redundancy at all — the 98% is one mechanism deep, not two. A regression in DKIM signing, or any relay that rewrites the body (mailing-list footers and subject tags are the classic cause), takes 95 messages/week straight to DMARC failure with no SPF backstop. Under p=quarantine that is silent spam-foldering.

For contrast, the healthy source in the same report read 100% pass / 100% SPF / 100% DKIM — genuinely two-legged, and it is what you should expect from a well-configured ESP.

Procedure

1. Never read the pass rate alone. Pull per-source SPF-aligned and DKIM-aligned percentages and check whether they sum to roughly the pass rate. Sum ≈ pass rate means disjoint (single-leg). Sum ≫ pass rate means overlap (genuinely redundant). This is a two-second arithmetic check that changes the risk assessment completely.
2. Do it per source, never in aggregate. Aggregating a 100%/100% ESP with a single-leg relay produces a healthy-looking blend that describes neither.
3. Treat "policy fixed, alignment still broken" as the default outcome of an SPF repair. Here a prior fix had cleared an SPF PermError (11 DNS lookups down to 2, over the RFC 7208 limit of 10). It removed the error and moved alignment only 3.7% -> 11.82%. Verifying that the record now evaluates is not verifying that it aligns; alignment additionally requires the envelope sender domain to match the header From domain.
4. Fix the single-leg dependency before tightening, and especially before ~all -> -all, which converts a soft failure into a hard one on the leg that is already carrying nothing.

Generalization

Any "A or B" success criterion should be monitored as two series, not one. The aggregate rate is identical whether A and B are independent backups or mutually exclusive paths, and those two worlds have completely different failure behaviour under load or regression. If your dashboard only shows the disjunction, you cannot tell redundancy from fragility — and the moment you enforce, you find out.