p=monthly

Email authentication news for people who run email.
October 2026 · about 5 minutes

Hey — Meysam here.

This is the first issue of p=monthly: a monthly digest of what happened over the last 30 days in the world of email authentication — RFCs, deliverability blogs, vendors, research.

I collect all of it, curate what I found most interesting into a five-minute read, and tell you whether you need to update anything in your DNS or email stack.

If this kind of email isn't for you, the unsubscribe link is at the bottom. I respect your decision and your privacy.

Before jumping in: hit reply and tell me what you'd want to hear more of — protocol depth, compliance, deliverability. I read every reply.

Everyone publishes. Fewer are listening.

New Zealand's government has a deadline this month. Its Secure Government Email framework (digital.govt.nz, updated Sep 9, 2026) requires p=reject on every email-enabled domain by October 2026. A Proofpoint analysis of more than 200 government organisations (Sep 7, 2026) found 50% there, double last year's 26%, with 35% still at monitor-only and 3% publishing no record. In the US, DigiCert checked 3,756 campaign domains ahead of the midterms (Sep 22, 2026): 18% enforce DMARC and 38% monitor without enforcing.

Publishing a policy is half the protocol. The other half is reading what comes back. CipherCue looked at 69,887 European company domains that publish DMARC (Sep 17, 2026) and found 33.5% have no rua= tag at all. Samuel Chenard's scan of 99,300 domains (Internet Society Pulse, Sep 1, 2026) put that figure at 20.7%, and showed the mailbox platform doesn't settle it: 89.4% of Microsoft 365 domains publish DMARC, and 68.3% of those enforce. An address in the record isn't proof anyone is reading, either. One Auckland stadium's reports were going to a domain that a former filtering provider retired in 2021, until a consultancy registered that domain and counted 12,615 report records arriving (SH Consulting, Aug 31, 2026). The record was fixed on Aug 21 and the reports deleted.

We see the same shape at larger scale. In our State of Email Authentication study of 5.5 million domains (February 2026), 30.4% publish DMARC, 12.8% enforce it, and 53.5% of the publishers list a reporting address. Different corpora, different sizes, one shape. p=none is a starting line. It was never meant to be a parking spot.

DKIM2 had its busiest month yet. Three drafts moved. The best-practices draft reached -01 (Sep 9). A sender-policy proposal from Google's Wei Chuang went through four versions (Sep 10–21); it would add an auth= tag to DMARC records so a domain can declare that it signs with DKIM2. It is an individual draft, not yet a working-group document. And a debug header, X-DKIM2-Info, was written up for interop testing (Sep 18). The core spec stays at -06. At the working group's Sep 23 interim, the direction was that the first DKIM2 signature must align with the From domain, and the donotexplode flag is set to be removed. Then on Sep 29, Fastmail told the list it is DKIM2-signing mail for a handful of its own domains and verifying DKIM2 on inbound mail for all customers. Real mail, real signatures, still a draft.

The tree walk is reaching your tools. Since May, DMARC is RFC 9989, and it finds your organizational domain by walking the DNS tree where it used to consult the Public Suffix List. The libraries are catching up: checkdmarc 6.0.0 (Aug 31) corrected its tree walk after an audit against the RFCs turned up 81 discrepancies, and mailauth merged its own tree walk on Sep 26 as a breaking change. One verified erratum (9150, Sep 2) fixes a cross-reference: external report destinations are verified per Section 4 of RFC 9990, not Section 3. The practical consequence is that the same subdomain can get a different answer before and after an upgrade.

An empty envelope sender gets past Microsoft 365's Direct Send control. ReliaQuest (Sep 3) showed that a message with a blank MAIL FROM and your own domain in the From header is accepted even with RejectDirectSend on, while failing DMARC on the way in. Keep the setting enabled, restrict inbound connectors to the IPs you know, and search for empty envelope senders paired with your own domain.

Exchange Online now throttles, then blocks, under-patched hybrid servers. Microsoft's Exchange team (Sep 2) set a floor: Exchange 2016 and 2019 servers sending through an OnPremises inbound connector need the October 2025 update level. Inventory every server that touches that connector, including the relay nobody remembers.

Phishing that passed every check. Brevo's incident write-up (Sep 10) describes a SAML SSO flaw that gave an attacker access to 138 customer accounts; six were used to send phishing through Brevo's own infrastructure, so it passed SPF, DKIM and DMARC. Authentication proves the domain, not the intent. Review who can log in to each sending platform, and give each one its own subdomain.

Warm-up tools now have a blocklist. Validity's Heatwave launched Sep 3 with more than 1 million domains tied to synthetic warming and cold outreach. Al Iverson's write-up (Spam Resource, Sep 9) advises avoiding those tools altogether. Look up your domains, and any lookalike "outreach" domains sales may have registered, at lookup.validity.tools.

Hosted MTA-STS (PRO+). MTA-STS means serving a policy file over HTTPS from every domain you protect, which is one more endpoint to run. You can now have DMARCguard host it for your domains. Open Hosted DNS, tick the domain and apply, then add the two CNAME records it gives you (_mta-sts and mta-sts). We serve the policy file and keep its certificate renewed. It is an add-on to the Pro plan.

DNS History (PRO). When a record changes, the first question is what it said before. You can now see every recorded change to your DMARC, SPF, DKIM and other email authentication records over time. Open DNS History and pick a domain. Records are checked every 12 hours, and Check now takes a fresh reading right after you edit your zone.

This is where we learn about email authentication protocols a bit more.

Swap in a selector you use (it's the s= tag in any DKIM-Signature header you send). The number is the length of your public key: 392 is a 2048-bit RSA key, 216 is 1024-bit, 44 is Ed25519. Anything else under 216 is an RSA key below 1024 bits and should be replaced today. A scan reported on the IETF DKIM list (Sep 17) found 512-bit and 768-bit keys still published, and made the point that a key on a selector you no longer use still counts. This month's DKIM2 best-practices draft recommends 2048 bits, and a new selector for every rotation. If yours says 216, plan the rotation, and delete the records for selectors you've retired. Our DKIM checker does the same read without a terminal.

See you on the 1st.
— Meysam · Founder, DMARCguard