Mail deliverability in the Russian web in 2026: who runs the mail, and why it matters

On 27 August 2026 we queried MX records for 600 domains (150 per zone) and matched them against known mail services. Of the 150 .ru domains, 94 accept mail:

For comparison, the international zones:

Caveats: the provider is identified by the hostname in the MX record, so relaying through an intermediate gateway is recorded as the gateway. These are domains somebody brought to our tools, not a random slice of a zone; comparing zones is sound, as they were collected identically.

First: the market is fragmented. In .com two companies cover 37% of mail-bearing domains. In .ru the largest player takes 20%, and reaching the same 37% requires three. That changes practice: SPF setup instructions, sending limits and incident procedures differ across five providers, and no universal "the way everyone does it" exists.

Second: a quarter of domains sit on a hosting company’s mail. Reg.ru, Beget and Timeweb together account for 26% of .ru domains with mail. In international zones this category is practically absent.

This bears on deliverability directly. Hosting-company mail usually leaves from addresses shared by many customers: sending reputation is communal. One neighbour on the server who starts sending spam degrades delivery for everyone else, and you cannot act on it — the lever belongs to the host, not to you. Specialist mail services separate customer streams considerably more strictly.

Practical consequence: if your mail lives on the same hosting as your site and messages start landing in spam for no visible reason, check the reputation of the sending address before your own settings.

The same data yields an unexpected combination. In .ru 59% of domains hand mail to an external service — against 45% in .com. Russian owners more often pass mail to someone who understands it.

Yet by our own authentication measurement strict SPF is set on 8% of .ru domains against 34% in .com, and DMARC on 36% against 56%.

The combination is odd, because a provider normally supplies a ready SPF string in its onboarding instructions. The likeliest explanation: the record is set once at connection — in the soft ~all mode the provider itself recommends as a safe start — and nobody returns to it. Soft mode is meant to be temporary, but nobody manages the time.

It is the same motif our other measurements found: HSTS without includeSubDomains, robots.txt with no real disallows. Configuration is taken to the point of working and not to the point of protecting.

1. Start with who is sending. If mail lives on the same hosting as the site, check whether the outbound address is listed anywhere. This is the commonest cause of a sudden delivery collapse, and it has nothing to do with your settings.
2. Reconcile SPF with your provider’s list. When mail services change, the old record often survives: it lists servers you no longer use and omits the new ones.
3. Check the ten-DNS-lookup limit. Nested include statements consume it, and exceeding it invalidates the whole record — silently, with no error.
4. Turn on DMARC at p=none with reporting. Within a couple of weeks you will see the full list of senders using your name — usually including a forgotten newsletter or a system nobody remembered.
5. Do not tighten SPF to -all until the reports are clean. That order matters: see first, forbid second.

To check your domain’s records, use the mail record checker; to take apart the headers of a specific undelivered message, the header analyser.