SPF, DKIM, and DMARC for Yandex 360 and Mail.ru in One Evening

Exact SPF, DKIM and DMARC values for Yandex 360 and Mail.ru for Business, Russian DNS registrar quirks, and a five-minute way to verify your setup.

SPF, DKIM and DMARC are three TXT records in your domain's DNS. The first lists the servers allowed to send mail on your domain's behalf, the second signs every message with a cryptographic key, the third tells the receiving server what to do with a message that fails the checks. If your outbound targets Russian and CIS inboxes — where Yandex 360 and Mail.ru for Business hold the position Microsoft 365 and Google Workspace hold in the West — the whole setup is one evening's work: copy the ready-made values from your mail platform's admin panel and paste them into your DNS host.

If the records are missing or misconfigured, the receiving server cannot tell your message from a spoof — and it defaults to suspicious. For cold outreach that is close to a guaranteed spam folder. Below: exact record values for both platforms, Russian DNS registrar quirks, and a five-minute verification.

Why missing records send you to spam

When your message arrives, the receiving server answers three questions: was the sending server allowed to write from this domain (SPF), was the message altered in transit and is it signed by the domain owner (DKIM), and what should happen when a check fails (DMARC). No answer means the filter assumes the worst.

Since February 2024, Google and Yahoo have required SPF, DKIM and DMARC — plus one-click unsubscribe and a spam-complaint rate under 0.3% — from bulk senders. The Russian platforms apply comparable checks at any volume: these records have long been a baseline reputation signal for Yandex and Mail.ru. In B2B outreach, where a domain sends hundreds of messages a day to strangers, missing setup reads as "a sender with something to hide."

Technical setup does not override the rules of the game. In Russia, as in most jurisdictions, sending advertising by email without the recipient's prior consent is a violation. A specific business proposal addressed to a company about its own line of work is not advertising — but you have to hold that line in every message. The DNS records prove something else: that the message really came from you, not from someone hiding behind your domain.

Cheat sheet: the three records

The DKIM value is unique per domain — the platform's admin panel issues the public key. MX records for receiving mail are also mandatory, but the platform shows those when you add the domain; we cover only the three sending records.

Setting up Yandex 360

1. Open the admin panel (admin.yandex.ru), domains section, and confirm domain ownership if needed.
2. SPF: create a TXT record for @ with the value v=spf1 redirect=_spf.yandex.net — this works if Yandex is the only service sending from the domain.
3. DKIM: the domain card shows the DKIM status and the public key. Create a TXT record named mail._domainkey with a value like v=DKIM1; k=rsa; p=MIIBIjANBg... — copy the key in full, no spaces or line breaks.
4. DMARC: a TXT record named _dmarc with the value v=DMARC1; p=none; rua=mailto:postmaster@yourdomain.com.
5. Come back an hour later and check that the record statuses have turned green.

Setting up Mail.ru for Business

1. In the biz.mail.ru panel, add your domain and confirm ownership by the method the panel offers.
2. SPF: a TXT record for @ with the value v=spf1 include:_spf.mxcorp.ru ~all.
3. DKIM: the panel issues a public key. Create a TXT record named mailru._domainkey with a value like v=DKIM1; k=rsa; p=....
4. DMARC: same as for Yandex — a _dmarc record with v=DMARC1; p=none; rua=mailto:postmaster@yourdomain.com.
5. Wait for DNS to propagate and check the statuses in the panel.

Sending from both platforms: building one SPF

A domain can have exactly one SPF record. Two TXT records containing v=spf1 break the check for both. If you send from Yandex and Mail.ru (plus, say, your website fires form submissions from its own server), every service goes into a single line:

v=spf1 include:_spf.yandex.net include:_spf.mxcorp.ru ~all

The rules are simple: each sending service is added via include, the record ends with the soft fail ~all, and the total number of DNS lookups across the include chain must stay at ten or fewer — exceeding the limit breaks SPF just as reliably as having none.

Quirks of Russian DNS registrars

• Record name format. reg.ru, Selectel and Yandex Cloud DNS ask for just the subdomain: mail._domainkey, _dmarc, @. Some panels (older Timeweb interfaces, hosts on ISPmanager) expect the full name with a trailing dot. Match the formatting of existing records.
• TTL. Set 3600 seconds or less while you work — then a mistake can be fixed without a day of waiting. Propagation takes from 15 minutes to 24 hours.
• Long keys. Some panels truncate TXT values longer than 255 characters. Paste the key as one line without quotes; if the panel splits the value into parts itself, that is fine — DNS stitches them back together.
• Domain transfers. Switching registrar or DNS provider often resets records to template defaults. After any move, re-check the entire set — the most common cause of "it worked yesterday."

How to verify the setup

• Inspect the records with dig TXT yourdomain.com, dig TXT mail._domainkey.yourdomain.com, dig TXT _dmarc.yourdomain.com — or any online DNS checker.
• Send a test message to Mail.ru and Gmail mailboxes, open the message source, and find the Authentication-Results line: it should show spf=pass, dkim=pass, dmarc=pass.
• Run the message through a mail tester (mail-tester.com): it shows your records' state and crude problems in the message itself.

Important: the records are an entry pass, not an inbox guarantee. After them the filter looks at domain reputation and age, so a fresh domain needs warming up before it carries cold sequences — we covered the warm-up protocol in our field notes.

Where it usually breaks

• Two SPF records on one domain — the check fails on both.
• A typo in the host name: dmarc instead of _dmarc, dkim._domainkey instead of mail._domainkey — the record exists, but the server never finds it.
• DMARC set straight to p=reject: any misconfigured system of yours (website, CRM, accounting) starts losing mail. Begin with p=none.
• Records entered at the wrong host: the domain's NS is delegated one place while you edit the zone somewhere else.
• A stale SPF after a mail migration: the domain moved from Yandex to Mail.ru, but the record stayed behind.

FAQ

Do I need these records if we only send 50 emails a day?

Yes. The formal Google and Yahoo requirements target bulk senders, but the Yandex and Mail.ru filters check for the records at any volume. Three records, entered once in an evening, are the cheapest item in the entire deliverability setup.

Can I get by with SPF and skip DKIM?

Technically the mail will send, but SPF breaks whenever a message gets forwarded, while a DKIM signature survives it. Filters look at both signals, so one record instead of three is a third of the work and most of the risk. They are configured together; there is nothing to save here.

What should DMARC start with: none, quarantine, or reject?

Start with p=none plus a reporting address. A couple of weeks will show whether all your legitimate senders — website, CRM, newsletter service — pass the checks. Then p=quarantine, and only once you confirm none of your own mail is refused, p=reject.

We run both Yandex 360 and Mail.ru — what about SPF?

One shared record: v=spf1 include:_spf.yandex.net include:_spf.mxcorp.ru ~all. Each platform has its own DKIM, and both records coexist peacefully — they use different host names.

Records are configured, but mail still lands in spam. What is wrong?

The records only vouch for the sender's authenticity. Beyond them, the filter weighs domain and IP reputation, domain age, complaints and recipient engagement. A fresh domain that fires two hundred cold emails on day one will land in spam with perfect DNS — so records are followed by warm-up and disciplined volumes. And check the message itself: a faceless advertising blast is a legal problem, not a technical one.

DNS setup and domain warm-up are the first items in our engagement protocol, before any sequence is written. If you want your current configuration — domain, records, the messages themselves — taken apart against this scheme, send us a sequence or a target list for a teardown through the form on the site. We will tell you plainly what is hurting delivery and what to do about it.