SPF and DKIM for Mail.ru — the stricter checklist

If you have ever watched a campaign get 90% Inbox at Gmail and 30% Inbox at Mail.ru with the same DNS records, you have met the phenomenon this article exists to solve. Mail.ru enforces authentication more strictly than Gmail, and the default setups most senders copy from American how-tos slip past Gmail while triggering Mail.ru's stricter checks.

Why Mail.ru is stricter than Gmail

Mail.ru handles ~42% of consumer mail in Russia. Because it is the largest target for Russian-language spam operations — and because the cost of a single missed phishing campaign is reputational for the whole ISP — Mail.ru has historically enforced authentication on the strict end of the spec. Gmail aims to minimise false positives; Mail.ru aims to minimise false negatives. Three concrete examples:

• Gmail accepts 1024-bit DKIM keys. Mail.ru accepts them but weights them as less trustworthy in its ML signal.
• Gmail tolerates SPF ~all indefinitely. Mail.ru's reputation score for a domain with ~all is meaningfully below the same domain with -all.
• Gmail forgives transient DKIM validation errors (tempfail). Mail.ru treats tempfail closer to fail.

The SPF record

A working SPF record for a sender using their own domain plus a transactional ESP (SendGrid here as an example) looks like this:

; DNS record at yourdomain.com
yourdomain.com.   IN TXT   "v=spf1 ip4:203.0.113.42 include:_spf.google.com include:sendgrid.net -all"

; DNS record for subdomain sending (if you use mail.yourdomain.com)
mail.yourdomain.com.   IN TXT   "v=spf1 include:sendgrid.net -all"

Three things are specifically chosen for Mail.ru. First, the record ends with -all (hard fail) rather than ~all (soft fail) — Mail.ru scores -all as a trust signal. Second, there are fewer than ten include: chains so we stay under the SPF lookup limit. Third, every sending service is listed; a common mistake is updating the ESP but forgetting to add it to the record.

The DKIM record

DKIM for Mail.ru should be generated at 2048 bits minimum. Some ESPs still default to 1024 — explicitly request 2048 when you generate the key. Here is what the published record looks like:

; DKIM public key at selector._domainkey.yourdomain.com
s2026._domainkey.yourdomain.com.   IN TXT   (
  "v=DKIM1; k=rsa; "
  "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA"
  "1Kqx8k7vR3FhU0L0nJ4fz2Qm5p6rT8yY9oA1Bc3DdEe"
  "... (remainder of base64-encoded public key) ..."
  "QIDAQAB"
)

The selector (here s2026) is arbitrary but should be short and unique per signing key. Rotate selectors annually. If your ESP manages DKIM, use whatever selector the ESP specifies.

Selector setup walk-through

1. Generate a 2048-bit RSA key pair in your ESP's admin, or run opendkim-genkey -b 2048 -s s2026 -d yourdomain.com.
2. Publish the public key at s2026._domainkey.yourdomain.com as a TXT record.
3. Configure your sending server to sign with the matching private key using selector s2026 and domain yourdomain.com.
4. Send a test message to a Mail.ru seed and inspect the headers — look for Authentication-Results: mx.mail.ru; dkim=pass.

DMARC on top

Mail.ru honours DMARC fully. Start at p=none for two weeks to collect reports, then move to p=quarantine, and finally p=reject once you are confident no legitimate mail is unaligned.

; DMARC record at _dmarc.yourdomain.com
_dmarc.yourdomain.com.   IN TXT   "v=DMARC1; p=quarantine; adkim=r; aspf=r; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; pct=100; fo=1"

Verifying at postmaster.mail.ru

Mail.ru runs a postmaster portal at postmaster.mail.ru that gives you per-domain placement stats, complaint rates, FBL enrolment and reputation breakdowns. It is free and Russian-language only, though the interface is mostly icons and numbers.

1. Sign in with a Mail.ru account (any account — it is a panel, not a sending identity).
2. Add your sending domain; verify ownership via a TXT record.
3. Confirm DKIM signing is recognised (DKIM section shows Подтверждено / Confirmed).
4. Enrol in the feedback loop — Mail.ru will email complaint reports to your nominated address.
5. Submit the domain for the postmaster whitelist review after 30 days of clean sending.

Common failure modes and their error messages

Mail.ru SMTP rejections include human-readable reason codes. The ones senders see most often:

• 550 Message rejected under suspicion of SPAM — the ML classifier scored the message too high. Usually reputation, not a specific content trigger.
• 550 SPF check failed — the sending IP is not in any of the SPF mechanisms for your From domain.
• 550 DMARC policy violation — SPF and DKIM both failed alignment, and your DMARC policy is p=reject.
• 550 Sender address rejected: Domain not found — DNS lookup for the From domain is failing. Check MX and A records.
• 421 Try again later — greylist. Wait, retry; real senders always get through this one.

Adding your domain to the FBL loop

The feedback loop at postmaster.mail.ru forwards complaint reports — every time a Mail.ru user clicks "This is spam" on one of your messages, you get an ARF-format report at your nominated FBL address.

Enrolment is one click in the postmaster panel once domain verification is complete. The typical delivery delay for complaint reports is 4–8 hours. Use these reports to suppress complainers within 24 hours — Mail.ru penalises senders who continue mailing users who complained.

Frequently asked questions