By mid-July 2026, the story of Delta Chat’s outage in Russia no longer looks like a routine technical incident. It all began on June 5, when the messenger’s Chatmail relays stopped working for users in Russia all at once. The discussion spread beyond the support forum to Mastodon, where on June 11 an analysis appeared with the same technical theory. According to it, the Rustls library that the Chatmail core used sent a unique TLS fingerprint, and this was exactly what the authorities began catching and blocking. A relay operator in Kazakhstan reported a different problem. His server and several others, including arcanechat.me, became unreachable, which forced them to move the infrastructure to Estonia and change hosting providers.

Investigation of the causes of DeltaChat’s unavailability

Roskomnadzor (Russian communications and media regulator) has had grievances with Delta Chat for a long time, so the blocking theory is valid. In 2020, the agency demanded that the developers hand over access to user data and encryption keys. At the same time, Roskomnadzor demanded that Delta Chat register in the registry of information dissemination organizers (ORI). Delta Chat refused, citing its lack of access to user data due to the peculiarities of the service’s architecture. In 2024, Roskomnadzor, this time at the request of the FSB (the Federal Security Service), again demanded registration. Delta Chat refused again. In July, Roskomnadzor issued a non-compliance report regarding the failure to fulfill ORI obligations, imposing a fine of 100,000 rubles (about $1,330).

To check whether the incident was aimed specifically at Delta Chat, we turned to the broader picture of outages from the same period. The Delta Chat outage was not an isolated incident. In late May and early June 2026, owners of websites on major Russian hosting providers began complaining that their resources were unreachable.

The hosting provider Beget announced via its official Telegram channel that some resources were partially unavailable for some users. According to Beget, the problem had a “floating” character and was linked to an update of the TSPU (technical countermeasures against threats, the deep packet inspection equipment) settings by Roskomnadzor.

Another hosting provider, Timeweb, on June 4 named changes to the TSPU settings as the likely cause of the outage on its Telegram channel. Based on the author’s firsthand experience on his own infrastructure, Timeweb’s support team denied the problem for two days in its replies to individual user requests and acknowledged it only on June 7. This observation is not independently confirmed by other sources and may reflect a specific experience of dealing with support rather than the company’s general policy. The service’s Telegram channel did mention TSPU.

On June 6, the engineer Pyotr Osetrov published a technical analysis reconstructing the new restriction algorithm, based on a reproducible experiment. He launched several parallel Google Chrome profiles and showed the conditions under which a connection was frozen. This post does not mention Delta Chat at all. The analysis is devoted to the general filtering algorithm, which argues more for the protocol-agnostic nature of the blocking than for the theory that it was targeted. A few days after publication one of the readers reported in a news item on Habr (a major Russian tech blogging platform) that the article had become unavailable, showing the hosting provider’s characteristic placeholder stating that Roskomnadzor caused access problems for Russian cloud services and websites. In the comments to a later analysis, this situation was clarified more precisely: the article was not deleted but hidden specifically for Russian IP addresses with the code HTTP 451 “Unavailable For Legal Reasons,” while remaining fully accessible from any other country comments on “Freezing by fingerprint”. This is consistent with the platform’s own documented policy: on receiving an order to block material on the territory of a specific country, Habr applies a geo-restriction with this code, determining a visitor’s country from the regional address registry database Habr, “Geographic restrictions”. The available sources do not establish whether this was a direct order from the regulator or the platform’s own initiative as a matter of moderation.

The link between this general algorithm and the specific Delta Chat case appears in this analysis on Habr. The TLS fingerprint of the ring cryptographic library, which the Chatmail Rust engine used, matched the features that the new TSPU algorithm flags as suspicious, and Delta Chat’s mail went down on several hosting providers simultaneously with other outages on June 5. The author of this analysis marks Timeweb’s June 7 acknowledgment as a fact cross-checked against three independent sources, including the already-mentioned allslava.com.

The Delta Chat outage is part of a larger trend. It was not one messenger that suffered but a whole range of services and websites, and the blocking mechanism itself shows no signs of being aimed specifically at email protocols or Chatmail.

How do the blocks work

Three signals of one algorithm

Osetrov’s reconstruction describes the mechanism as a sequential check of three conditions when a TLS connection is established:

• whether the server’s IP address belongs to a “suspicious” subnet or autonomous system, a list that has come to include a number of large Russian data centers;
• whether the client’s TLS fingerprint is suspicious (on average this concerns fingerprints imitating Chrome, Safari, and iOS, whereas Firefox, Android OkHttp, Edge, and several others passed the check with most operators at the time of publication);
• whether more than three parallel TLS connection attempts to the same SNI were recorded, with intervals of less than 350 to 400 ms, within the last 60 seconds.

If all three conditions are met, the connection is frozen for 120 seconds. Changing the client fingerprint during the freeze added a penalty ban of another 600 seconds, regardless of the new fingerprint and SNI, although, according to the author’s June 16 update, this additional penalty was apparently removed later.

Timeline: from the first signals to the June wave

• In November and December 2025, the TSPU began blocking VLESS by indirect features in several regions, first in Tatarstan, Udmurtia, and the Nizhny Novgorod Region, then in the Sverdlovsk Region.
• On February 17, 2026, a large-scale block of the VLESS+Reality combination over TCP hit several wired operators, with a characteristic pattern of freezing after roughly the first 16 kilobytes of traffic.
• In late May, a test run began, followed by the rollout of a behavioral module in Siberia and Moscow, which caught VLESS, Xray, MTProto, WireGuard, and gRPC, but not SSH.

Two hypotheses about the cause

Collateral damage. The June 5 wave hit Delta Chat, hosting providers, and several VPN protocols at the same time. The logic of the alarm conditions (subnet, fingerprint, handshake frequency) contains nothing specific to messengers or email. The public rhetoric around the incident describes what is happening as a fight against modern protocols that disguise themselves as legitimate traffic, rather than as an attack on specific services.

Targeted escalation. This assumption rests on a real precedent: the documented conflicts between Delta Chat and RKN in 2020 and 2024. That said, so far the connection between the three incidents is not backed by technical data.

Institutionally, traffic filtering in Russia is developing according to a long-term plan. Decision No. 25-66883-01845-R on the procedure for granting a subsidy to the Main Radio Frequency Center, signed on January 13, 2025, sets target metrics: 92 percent effectiveness in restricting access to VPNs by 2030, and processing of 100% of the traffic of the Russian segment of the internet as early as 2026. We did a separate analysis on this topic. The document was later removed from Roskomnadzor’s website.

A legal shift at the level of hosting providers was being prepared in parallel: the “Anti-Fraud 2.0” amendments, under discussion since April 2026, move hosters from the status of a technical intermediary to that of a controller, obliging them to independently identify and disconnect clients who use capacity for VPNs, including cases with already-obfuscated traffic. We had an analysis on this topic too.

One more detail to round out this picture: by May 2026, Beget’s own public offer agreement already prohibited clients from hosting “mass public email services, VPN services, proxy services.” There is no direct link between this wording and the June incident, but one thing is clear: hosting providers were preparing for tighter control even before the June wave.

Both documents appeared before all the events of June 2026. This is an argument in favor of the idea that the June wave was a planned stage of a broader program rather than a spontaneous decision. The public version, voiced through the hosting providers and industry outlets, sounds simpler: a fight against protocols that disguise themselves as legitimate traffic.

Recommendations

For more precise recommendations, the Teplitsa editorial team is conducting additional research, the results of which will be published soon.

For now, the brief recommendations are as follows:

• the choice of cryptographic backend and its effect on the TLS fingerprint;
• reducing the number of parallel connections where this is possible at the relay level;
• choosing a hosting subnet with the understanding that inclusion in the “suspicious” ASN list is not published officially and can change.