A falling SPF compliance percentage is a signal to investigate, not a DNS diagnosis. The number may represent raw SPF pass, aligned SPF pass, a vendor-specific classification or only the messages visible to certain reporting receivers. First reconstruct its numerator, denominator and time window. Otherwise, a successful infrastructure change can be confused with an attack or a reporting artefact.
Define the measurement
Write down the precise metric: for example, “messages with aligned SPF pass divided by all messages in these received reports during this UTC interval.” Record the reporters included, volume, missing periods and any deduplication rules. Keep raw SPF outcomes separate from DMARC alignment. SPF can pass for a domain unrelated to the Author Domain, so a pass count and an aligned-pass count answer different questions. RFC 9989 §3.2.4, RFC 9989 §4.4.
Compare absolute counts as well as rates. Illustrative example: yesterday 9,900 of 10,000 observed messages had aligned SPF. Today the same 9,900 legitimate messages pass, but 10,000 additional unauthorised messages appear. Assume the original 100 non-aligned observations also remain, giving 20,000 observations today. The rate falls from 99% (9,900/10,000) to 49.5% (9,900/20,000) without a new failure in the known legitimate stream. These are synthetic arithmetic inputs, not report measurements. That remains a security-relevant change, but adding those sources to SPF would be the wrong response.
Partition before editing
Break the change down by source IP, envelope domain, From domain, provider or application, recipient reporter, address family and raw result. Find the earliest changed segment and compare it with DNS changes, new campaigns, routing changes, failover events and service migrations. Reported source addresses alone do not establish business ownership.
Classify fail, softfail, neutral, none, temperror and permerror separately. The result distinctions matter: a DNS outage does not have the same corrective action as a newly unauthorised address or a malformed record. For an error path, capture the exact policy and nested dependencies; SPF evaluation limits are not a simple count of visible include strings. RFC 7208 §4.6.4, RFC 7208 §8.
Confirm with transaction evidence
Take a representative failing message from each affected legitimate stream. Obtain SMTP logs or the received original with authentication results from a trusted boundary. Check the connecting IP and actual MAIL FROM identity, then reproduce its policy evaluation with dated DNS evidence. A dashboard label should point to these observations rather than replace them. RFC 8601 §1.2, RFC 8601 §7.1.
If the raw pass rate is stable but alignment drops, look for a new envelope domain. If only one recipient population changes, compare forwarding and connection paths. If legitimate volume falls while unfamiliar volume grows, investigate the unfamiliar sources without authorising them. Where reporting coverage changes, annotate the series rather than inventing comparability.
Restore the intended state
Choose a remedy that matches the cause: correct a policy defect, repair DNS service, restore a supported envelope configuration or stop an unintended route. Keep a saved prior state, accountable owner and explicit rollback condition. Retest the affected flows and review the next comparable reporting window. Close the incident with both the technical result and the measurement definition, including unresolved reporting gaps.
Put the decision in writing
Use a comparison worksheet with interval, reporter population, total observations, aligned-SPF count, known legitimate volume, unfamiliar volume and missing-data notes. If raw SPF remains passing while aligned SPF drops, compare the actual envelope domains before editing address permissions. A new reporter or changed deduplication rule can make two rates non-comparable. These are review criteria, not evidence of a real outage or attack.