Newsletter platform beehiiv announced Hex on November 11. The company says it now operates the servers and internet addresses that send mail through Hex, and publishers do not need to set it up. For a morning market briefing or a breaking news alert, the useful question is how many readers can get the issue before it goes stale. A faster sending engine can help, but its capacity figures alone cannot answer that question for your list.
Jump to a section
Separate sending speed from arrival
According to beehiiv’s published speed figures, Hex can send up to 3.7 million messages per minute, compared with 2.2 million on the previous setup. The company also reports a median of 1.8 seconds for automated emails such as welcome messages. These numbers measure different workloads. The first is a platform throughput figure. The second describes the middle automated send. Neither gives you the share of a scheduled edition accepted by Gmail before a particular deadline.
Acceptance is another step. beehiiv’s guide to delivery events says a message counts as delivered when the receiving provider accepts it. The provider can still place it in spam or a different inbox tab. The 99.1% acceptance rate beehiiv reports for Hex therefore answers a different question from where people actually saw the issue.
EmailTooltester’s November 4 snapshot gives independent context on placement. The firm observed 6,197 beehiiv messages from 122 brands in participating Gmail inboxes and reported 82.0% Primary placement. Its method uses the subset with inbox tabs enabled to measure Primary placement. It did not compare the same newsletters before and after their switch to Hex. Use the snapshot to understand what placement data measures. It cannot tell you how much Hex changed placement on your list.
Measure how many messages meet your deadline
Suppose your financial newsletter goes out at 7:00 a.m. and the lead is most useful before a 7:05 announcement. Set five minutes as the deadline. For each send, divide the messages accepted by that time by the number actually attempted. Keep suppressed addresses separate because the system never attempted them. Use the same clock and time zone for both sends. Start the clock at the scheduled send time if that is what your audience expects. Keep the recorded release time separately to tell whether the delay began before the platform tried to send.
Here are two hypothetical editions with 10,000 attempted messages each. The newer send ultimately gets 40 more accepted messages. At the five-minute mark, it has 300 fewer. A report checked the next morning would favor the send that left more messages unaccepted at the deadline. At 7:05, the shortfall against the older issue is three percentage points.
Use this comparison within a single mailbox provider first. A report across the whole list can move when you send to a different mix of addresses. Our earlier analysis shows how audience mix can hide a delivery decline. Compare the same recurring edition, sending domain and stable recipient group where you can. A new import, a changed schedule or a much larger send can explain a difference even if the sending infrastructure stayed the same.
| Measure | Earlier issue | Later issue |
|---|---|---|
| Attempted | 10,000 | 10,000 |
| Accepted by 7:05 a.m. | 9,000 (90%) | 8,700 (87%) |
| Accepted by the same next-day cutoff | 9,900 (99.0%) | 9,940 (99.4%) |
Use the evidence your account can provide
Start with the sends attempted, delivered, still retrying and bounced in beehiiv’s delivery troubleshooting guide. Save the provider breakdown at your chosen deadline if it has updated by then. Record when you collected it. A late dashboard refresh can resemble a slow send. If your account does not expose timestamps or timely provider counts, ask support for the acceptance curve for two named issues, grouped by mailbox provider. Ask which engine handled each issue before interpreting the difference as a before-and-after result.
If you only have a few inboxes you control, leave them subscribed to your normal edition and record when the message appears and where it lands. A message in a test Gmail inbox can tell you what happened to that inbox. It cannot estimate the percentage of your entire list that arrived by the deadline. Keep those observations beside the send report instead of combining them into a single rate. Use comparable mailbox settings each time. A filter that automatically moves one sender out of spam can hide the behavior you are trying to observe.
If acceptance is stable and only inbox placement slips, work on that specific problem before moving the send earlier. Check the domain that signed the message against the From address readers see. Gmail’s sender requirements explain authentication and domain alignment. Use our bulk sender guide to inspect a delivered copy. If late acceptance repeats with one provider, give support the two issue IDs, provider counts, scheduled time and observed cutoff. That gives them a much smaller problem to trace.