A mailing service reports 98% delivery, but open rates are zero. Someone says the message landed in spam, someone else never received it. The problem is almost never the subject line or send time — it's DNS, domain reputation and list quality.
How mail providers assess messages
An email faces two checkpoints. First is SMTP: the server can reject immediately and send a service report from Mailer-Daemon with the reason and the name of the blocking server. Second is the filter: the message is accepted but routed to spam.
Yandex states openly that its filtering algorithm is proprietary. What remains are published requirements. Providers assess the sender, not the message — the entire history. They look at:
- whether SPF and DKIM pass and whether domains match the 'From' address;
- a stable IP, a valid reverse DNS record (PTR), current domain ownership data;
- addresses that do not exist: if the server replies 'no such user', sending there is prohibited — a mandatory requirement at Yandex;
- explicit recipient consent and a confirmed address;
- complaints, unsubscribes, messages deleted without reading.
Reputation is tied to domain and IP. On a shared service IP you share it with neighbours. A dedicated IP gives independence but starts from zero.
To understand what happened: read bounce messages in full — the code and server explanation point the direction. Connect the domain to Mail.ru Postmaster: it shows mailbox statistics, complaints via FBL and errors such as missing SPF or failed DMARC. If Mail.ru blocked you, fix the causes first, only then write to [email protected]. Without fixes they typically refuse unblocking. Send a test message to Yandex, Mail.ru and Gmail mailboxes, open the service headers and find the Authentication-Results line — it shows how the receiver evaluated SPF, DKIM and DMARC.
SPF, DKIM and DMARC: setup and verification
Three technologies answer one question: does the sender have the right to send on behalf of this domain. Skip one and there is a hole in the defence.
SPF is defined in RFC 7208. You publish a DNS TXT record listing servers permitted to send mail on behalf of the domain. A nuance: the check applies to the domain in the technical Return-Path address, not the 'From' field. Typical errors: two v=spf1 records on one domain (the standard permits one, two produce permerror), more than ten DNS lookups (RFC 7208 limits exactly ten terms — include, a, mx, exists, redirect and the obsolete ptr), and a new service someone forgot to add to SPF.
DKIM is defined in RFC 6376. The sender signs the message with a private key, the receiver verifies it with a public key from DNS. If the message was altered in transit, verification fails. Key length is typically 2048 bits. The main trap: many services sign messages with their own domain by default, not yours. The signature is valid but does not count for DMARC. At Yandex this is a strict requirement: all mailing messages must be DKIM-signed with your domain, and SPF must be present as well.
DMARC links SPF and DKIM to the 'From' address. A message passes DMARC if at least one check succeeds and the domain in it matches the domain in 'From' — this is called alignment. Hence the paradox: a DKIM signature from another domain and SPF on the service's technical address produce DMARC failure, even though both checks individually are green.
In May 2026 the IETF released a new edition of DMARC. The protocol is now defined in RFC 9989, aggregate reports in RFC 9990, failure reports in RFC 9991. They replaced RFC 7489 from 2015. The tags pct, rf and ri were removed, a testing flag was added. Old records continue to work, the version remains v=DMARC1. Start with p=none — nothing is blocked, but aggregate reports in XML arrive at the address in rua=. Then the ladder: collect reports for a few weeks, fix sources, move to p=quarantine, then to p=reject.
In Yandex's official requirements DMARC is listed as recommended, not mandatory. Mail.ru Postmaster treats failed DMARC as a problem. Gmail and other large receivers expect it from bulk senders.
Sending from @mail.ru, @yandex.ru or @gmail.com is prohibited. Mail.ru enabled strict DMARC policy on public domains back in 2016 — a message from such an address via a third-party service will not pass verification. Yandex requires the sender address to match the authentication account on the server. The only way out is to send from an address on your own domain.
Technical foundation: PTR, IP, headers and limits
Yandex requires a stable IP with a valid PTR record and current WHOIS data. If working through a mailing service, it handles this. Own server — PTR is configured by the IP owner.
Yandex advises sending bulk mail from a host different from the one used for regular correspondence. If that is not possible, a separate domain in 'From' is needed, such as news.example.ru. The logic: if the mailing draws complaints, business correspondence should not suffer.
From Yandex's mandatory requirements: List-Unsubscribe header per RFC 2369, following the link in it must unsubscribe immediately, the process must not take longer than ten minutes or require registration. One-click unsubscribe per RFC 8058 — via List-Unsubscribe-Post header — is mandatory at Gmail and Yahoo.
Yandex regular mailbox limits: 50 messages per day via mobile app, 1,000 via the site, 300 via mail client or SMTP. A message with ten recipients counts as ten.
List, consent and the law
Perfect DNS records will not save a mailing with a bad list. Yandex requires explicit consent and address confirmation by the recipient himself — in practice this is double opt-in: a person left an address, received a message with a link, followed it, and only then entered the active list. Addresses with 'no such user' response are removed immediately — a mandatory requirement at Yandex. Sharp volume spikes look like an account breach or the start of a spam campaign.
With purchased lists everything is simple: consent cannot be proven, part of the addresses is outdated, mailing services cut such campaigns at moderation. Business correspondence does not equal consent to advertising.
Under the law. Part 1 of Article 18 of Law No. 38-FZ of 13.03.2006 'On Advertising': advertising via telecommunications networks is permitted only with prior consent of the addressee. You must prove it, not the recipient. The Supreme Court in ruling No. 310-ES21-10616 of 08.07.2021 on case No. A14-8969/2020 confirmed this extends to email. The FAS treats email mailings as advertising via telecommunications networks. The concept of spam also appears in the Rules for Provision of Telematic Communications Services (Government Resolution No. 2607 of 31.12.2021): a message to an indefinite circle of persons without prior consent and without the ability to identify the sender. Initial collection and storage of personal data of Russian citizens must occur on servers in Russia — this is Part 5 of Article 18 of Law No. 152-FZ.
