U.S. election email security tracker 2026
=========================================

Status: Scheduled October 13, 2026
Audience: Election-security, state-government and cybersecurity publications
Contact target: 40–60 election-security, cybersecurity and state-government reporters

Plain-language summary
A responsibly disclosed measurement of public email-authentication records: not a vulnerability ranking, compromise assessment or claim about election integrity.

Embargo approach
Provide 3–5 specialist reporters an embargoed methodology and aggregate preview after disclosure closes.

Pitch angles
- Public service: What changed after state election offices received a private configuration notice.
- Operational: The difference between publishing DMARC, collecting reports and actually enforcing it.
- Standards: A complete-population state-office measurement using RFC 9989 policy semantics and retained DNS evidence.

Methodology
- Freeze the complete 51-authority cohort on September 21 from Election Assistance Commission profiles and official authority websites.
- Scan on September 22, notify named state offices on September 23, close corrections on October 7, and perform the final rescan on October 8.
- Query _dmarc TXT, apex TXT, MX and default-selector BIMI through a recorded Google or Cloudflare public resolver with a five-second timeout and two DNS tries. Retain raw answers, response state, resolver, timestamp, parser version, and evidence hashes. NXDOMAIN and NODATA count as an observed absence; a timeout, refusal or server failure marks the entire domain unobserved and excludes it from denominators.
- Treat exactly one syntactically valid v=DMARC1 record as publication. RFC 9989 defaults an omitted p tag to none; t=y lowers the effective requested handling by one level. Effective quarantine and reject count as enforcement, while a valid rua mailto destination counts as aggregate reporting.
- Describe SPF narrowly: report whether exactly one v=spf1 record was observed, flag multiple records separately, and publish modeled recursive lookup exposure only for complete include/redirect evaluations. The model follows references to depth eight and never treats an unresolved nested query as a passing result.
- Retain a disclosure log and include corrections or contextual replies received before the correction window closes.

Limitations
- Public DNS configuration does not prove that a domain has been abused or compromised.
- The reviewed organizational domain may not expose every separate sending subdomain or vendor-managed mail stream.
- SPF lookup exposure is a record-structure model, not a full check_host() evaluation for a specific sender IP and message.

Publication policy
State election-authority domains may be named after ten business days of notice, correction review, and a post-window rescan. Legal and neutral-language approval are mandatory.

Sources
- EAC state election profiles: https://www.eac.gov/election-officials/eac-ncsl-state-election-profiles, Official starting point for all state election authorities.
- RFC 9989: DMARC: https://www.rfc-editor.org/info/rfc9989/, Current IETF DMARC policy-record syntax, discovery and evaluation standard.
- RFC 9990: DMARC aggregate reporting: https://www.rfc-editor.org/info/rfc9990/, Current IETF specification for DMARC aggregate-report requests and report format.
- RFC 7208: SPF: https://www.rfc-editor.org/info/rfc7208/, IETF SPF record syntax, multiple-record error handling and DNS-lookup limit.

Suggested citation
Palisade. “U.S. election email security tracker 2026.” Scheduled 2026-10-13. https://www.palisade.email/research/us-election-email-security-2026

Reusable charts will be available after final publication.