Someone on the membership team tells you the renewal notice went out. The AMS agrees: sent, delivered, a green check next to the batch. A week later a long-standing member writes to ask why their membership lapsed with no warning. You check. The reminder is not in their spam folder. It is not anywhere. It was never delivered, and the only trace of it is a bounce that went to a no-reply address nobody has opened in three years.
We have spent this year making member data legible to AI: readable to the agents showing up at the door, wired into copilots, restructured for retrieval. Meanwhile the oldest and plainest channel we have, an email a human being actually opens, has been quietly failing, and for a reason that has nothing to do with subject lines or send times. It is authentication. The large mailbox providers spent two years rewriting the rules for who is allowed to send mail at all, and a lot of association mail no longer clears the bar.
Here is the short version of what changed. In February 2024, Gmail and Yahoo began requiring bulk senders to authenticate their mail with three overlapping standards, SPF, DKIM, and DMARC, plus a working one-click unsubscribe and a user-reported spam rate under 0.3%.17 In May 2025, Microsoft joined them, applying the authentication requirement to anyone sending more than 5,000 messages a day to Outlook, Hotmail, and Live addresses.23 The thresholds and the fine print differ between them, but the direction does not: prove the mail is really from you, or it does not come in.
For a while the penalty was soft. Unauthenticated mail got deferred, or dropped into spam, which is annoying but survivable, because the member can still fish it out of the junk folder. That grace period is closing. Through late 2025 the providers moved from filtering unauthenticated bulk mail to rejecting it, handing back a hard error (Gmail's is the memorable 550 5.7.26, "unauthenticated email") instead of quietly filing it away.45 Rejected is worse than spam. Spam can be recovered. Rejected mail is simply gone, and the person it was meant for never knows it existed.
Why associations get hit harder
A retailer sends its mail from one marketing platform, so it has one authentication problem to solve. An association does not work that way. Renewal notices come from the AMS. The newsletter comes from a separate email tool. Event confirmations come from the registration system. Course reminders come from the LMS. The community platform sends its own digests. Receipts come from somewhere else again. This is the underside of the composable member stack I keep arguing for: more systems, each doing one thing well, also means more separate front doors, and every one of them sends mail addressed as [email protected] from its own servers. Each is a distinct sender that has to be authenticated and aligned to your domain on its own.8
That word, aligned, is where it usually breaks. DMARC does not just ask whether the mail was signed. It asks whether the signature matches the domain in the "from" line.6 Your IT lead can tell you, truthfully, "our DMARC is published," while the events platform, which nobody ever added to the record, fails alignment on every message it sends. The board sees the newsletter arrive fine, because that tool was set up with care. The member never sees the renewal notice, because the AMS was not.
The check, and who should run it
You can find this yourself this afternoon, with no budget and no project. Open a message you actually sent to members, in Gmail, and do it once for each system in turn. Click the three-dot menu and choose "Show original." At the top sit three lines, SPF, DKIM, and DMARC, each marked pass or fail for that one message. Read the AMS renewal notice. Read the event confirmation. Read the payment receipt. The systems that say fail, or that pass SPF and DKIM yet fail DMARC alignment, are the ones whose mail your members have started to lose.
| What "Show original" says | What it means, and the fix |
|---|---|
| SPF, DKIM, and DMARC all pass | Authenticated and aligned. This mail is getting through. |
| SPF or DKIM pass, but DMARC fails | The signature does not match your from-domain. This is the message that now gets rejected. Fix alignment for that one sender. |
| DKIM says none, or not signed | That platform is not signing your mail at all. Turn DKIM on inside that system and publish the key it gives you. |
| SPF softfails or fails | That server is not on your list of allowed senders. Add it to your SPF record. |
Now the part that matters more than the check itself: do not let this get answered by asking the vendor. Ask your AMS provider "are we authenticated?" and every one of them says yes, because their platform is authenticated for their own domain. That is not the question. The question is whether mail sent as your address, from their servers, aligns to the DMARC record on your domain, and that lives in DNS records only you control. If the answer comes back as "we handle deliverability for you," with no mention of an SPF entry you were asked to add or a DKIM key you were asked to publish, keep asking. The version that cannot be talked around is the one you run yourself: send one real message from each platform and read Show original.
This is also why the person who runs the check should not be whoever owns the DNS. It should be whoever owns the outcome, which in most associations is the membership or communications lead, not IT. Reading Show original takes no technical skill and no SQL. The value is in knowing, concretely, that the renewal reminder fails and the newsletter passes, because that single fact turns "deliverability" from an abstraction the vendor can wave away into one specific broken thing that someone now has to own.
One caution on the repair, because it is easy to overcorrect. The instinct, once you find failures, is to set your DMARC policy straight to reject and call it done. Do that blind and you will start bouncing your own legitimate mail from the three platforms you forgot you had. Publish DMARC at p=none first. It changes nothing about delivery, but it switches on the aggregate reports that name every source sending as you. Read those for a few weeks, authenticate each real sender you find, and only then tighten the policy toward quarantine and reject. The reports are the map. Reject is the destination, not the first step.
There is a security dividend worth naming too. The same DMARC record that gets your renewal notice delivered is what stops an outsider from mailing your members as you, which is exactly the cyber-poor, target-rich exposure I wrote about a couple of weeks back. Getting authentication right is both how your real mail arrives and how the fake mail does not. For once, the deliverability fix and the security fix are the same fix.
Quick takes
The vendor headlines this month were all AI. Momentive rolled out MomentiveIQ, a layer that unifies fundraising, membership, events, and learning under one predictive brain, and Bloomerang folded Dataro's donor modeling into its platform.9 Useful, probably. But every one of those features assumes the member is reachable in the first place. A copilot that drafts the perfect lapsed-member note is worth nothing if the note is rejected at the door. The intelligence is downstream of the plumbing, and the plumbing is where the quiet failures live.
Once your DMARC is at enforcement and a sender is verified, you unlock a small, real upside: BIMI, the standard that puts your logo in the inbox next to authenticated mail. I am wary of chasing it as a goal. It is a nice side effect of doing the authentication work properly, not a reason to do it, and treating the logo as the prize is how organizations skip past the reports that actually protect them.
The blind spot underneath all of this is the unread inbox. Bounces route to a no-reply nobody monitors, and DMARC aggregate reports arrive as XML at an address nobody set up. If you take one process step from this piece, make it this: point both at a mailbox a human reads. You cannot fix a failure you have arranged never to hear about.
Worth a read
Microsoft's own announcement of the Outlook high-volume sender rules. The primary text, in Microsoft's words, of what changed and when. Worth reading before you take a vendor's summary of it.
Google's Set up DMARC guide. Vendor-neutral enough to be the reference, and it walks the p=none to quarantine to reject progression in plain terms rather than selling you a dashboard.
The Association's Guide to Email Deliverability. The sector-specific walkthrough, including the multi-platform sending problem that makes this harder for associations than for almost anyone else.
My guess is that within a year, "why did the member not get our email" stops being a scattered help-desk ticket and becomes a standing line on the operations dashboard, sitting right next to renewal rate, because it will turn out to be the same number. The associations that get there first will be the ones who read the headers before they bought the next copilot.
Quick answers
How do I check whether my association's email is authenticated?
Open a message you recently sent to a member in Gmail, click the three-dot menu, and choose “Show original.” It lists SPF, DKIM, and DMARC with a pass or fail for that exact message. Do it once for every system that emails members, including your AMS, newsletter tool, and event platform, because each one is authenticated separately.
What changed with the Gmail, Yahoo, and Microsoft email rules?
Since February 2024, Gmail and Yahoo have required bulk senders to authenticate with SPF, DKIM, and DMARC. Microsoft joined in May 2025 for senders of more than 5,000 messages a day to Outlook, Hotmail, and Live addresses. By late 2025 the major providers moved from quietly filtering unauthenticated bulk mail to rejecting it outright, so failing mail now disappears instead of landing in spam.
Do these rules apply to a small association sending under 5,000 emails a day?
The 5,000-per-day threshold triggers the strictest enforcement, but all three providers recommend SPF, DKIM, and DMARC for every sender and filter unauthenticated mail from smaller senders too. A renewal reminder that fails authentication can be junked or rejected regardless of your volume, so the check is worth running even if you are well under the limit.
From the Mind of Ravi Rooprai is a weekly column on association tech, data, and AI. Read the perspectives for the longer arguments behind it.
Researched with AI assistance and fact-checked against primary sources. The analysis, judgment, and writing are mine. How this column is made →