Defaults.Exposed

How to set up DKIM on Reg.ru

Setting up DKIM on Reg.ru comes down to two moves: get the selector and the public key from whoever runs your mailboxes, then publish that key as a DNS record wherever your domain’s DNS is answered. The record comes first on this page because a person who can read one can tell a good paste from a broken one.

Reg.ru is the domain registrar and, for domains left on its own nameservers, the DNS host. It publishes the DKIM record you paste into its zone editor, but it never generates a DKIM key or a selector for a third-party mailbox, except for its own mail service, where it generates the key itself.

What DKIM proves, and where the key has to live

DKIM (DomainKeys Identified Mail) puts a signature on each message sent from your domain. The mail platform signs with a private key it keeps to itself. The receiving server pulls the selector out of the DKIM-Signature header, looks up <selector>._domainkey.yourdomain.com in DNS, and checks the signature against the public key it finds there. A match tells the receiver two things: the message came from a system holding your private key, and nobody changed the body or the signed headers on the way.

That lookup is why the record goes where your DNS lives. Receivers don’t ask your mail platform for the key, and they don’t ask your registrar unless it happens to run the zone. They ask whichever nameservers your domain delegates to, and only the copy held there counts. The DKIM guide covers the check from the receiver’s side; this page covers the publishing side.

Two parties share the record and neither can do the other’s part. The mail platform generates the key pair inside its own console, keeps the private half, signs outgoing mail with it, and hands you the public half plus a selector. The DNS host publishes what you paste and has no way to invent a value that would verify.

Reg.ru publishes exactly the TXT or CNAME record you enter in its zone editor, at the host and with the value you supply. It does not generate the key, name the selector, or validate that the type you chose matches what the mail provider issued. The one exception is Reg.ru’s own mail service, where Reg.ru generates the key on its own side and its help documents a dedicated article for turning on DKIM and DMARC for it.

The record, tag by tag

Most platforms hand you a TXT record. Its value is a short run of tags separated by semicolons, and a typical one begins v=DKIM1; k=rsa; p= followed by the key. v=DKIM1 names the version and, when present, has to come first. k=rsa names the key type; k=ed25519 exists, and a platform that supports it will say so. p= carries the public key itself, hundreds of characters of base64 with no spaces, and it’s the one tag a receiver insists on.

Three optional tags matter. t=y marks the key as testing, so receivers treat a failed signature as if the message carried none. t=s says the identity in the signature has to be your domain itself, with no subdomain in front of it. h=sha256 limits the hash to the algorithm receivers use anyway.

Start with the value as your platform issued it, character for character, and don’t tidy it. Once mail is flowing, tighten in two places. If t=y is present, remove it so a failure counts as a failure. If the platform offers a 2048-bit key alongside a 1024-bit one, pick 2048, since it’s the length platforms now issue by default and receivers accept it.

Rotation stays the platform’s job: when it issues a new key under a new selector, you publish the new record and leave the old one up until nothing signs with it any more.

Some platforms give you a CNAME instead. The name is still <selector>._domainkey, and the target is a host on the platform’s own servers that holds the TXT value, which lets the platform rotate keys without you touching DNS again. If you were given a CNAME, publish a CNAME. Converting the target into a TXT record publishes a hostname where receivers expect a key.

The selector is the half people underrate. A receiver builds its lookup from the s= tag in the header, so the name you publish has to match the one the platform signs with, letter for letter. selector1 and selector2 are different keys, and so are mail and mail1. For DMARC alignment the d= in the signature also has to be your domain or a subdomain of it.

Confirm who answers DNS for your domain

A record saved in a console that your domain doesn’t delegate to is invisible to receivers, whatever that console reports.

Look at the domain’s nameservers before opening any panel. If they read ns1.reg.ru and ns2.reg.ru, the personal account zone editor is authoritative and the steps below apply directly. If they read ns1.hosting.reg.ru and ns2.hosting.reg.ru, the live records sit in the hosting control panel instead, and the personal account zone editor will accept a record that never reaches the published zone. If the nameservers name a different company altogether, the DKIM record belongs at that company, not at Reg.ru.

Add the record in Reg.ru

Copy both pieces from the platform’s DKIM or email authentication page and keep that tab open until the check at the end passes. Laid out the way Reg.ru expects it, the record looks like this:

TXT record: host `google._domainkey` (or the selector your provider names, such as `selector1._domainkey` or `dkim._domainkey`), value `v=DKIM1; k=rsa; p=` followed by the key your provider generated.
CNAME record (Microsoft 365): host `selector1._domainkey`, value the `...onmicrosoft.com` target your provider names; a second CNAME at host `selector2._domainkey` pointing at its own `...onmicrosoft.com` target.

The subdomain field takes the selector on its own, such as google._domainkey, because Reg.ru appends the domain automatically; pasting the full host with the domain on the end duplicates it and breaks the record. The record type comes from the mail provider rather than from Reg.ru: Google Workspace calls for TXT, Microsoft 365 calls for CNAME. The value field carries the TXT string beginning v=DKIM1; k=rsa; p= for a TXT record, or the ...onmicrosoft.com target for a CNAME record. Reg.ru’s add-record form does not ask for a TTL on this record type.

  1. Sign in to the Reg.ru personal account, the «личный кабинет».
  2. Open the «Домены» (Domains) section from the account menu.
  3. Click the row that lists your domain to open its management page.
  4. Find the «DNS-серверы и управление зоной» (DNS servers and zone management) block on that page.
  5. Click «Изменить» (Edit) to open the zone for editing.
  6. Click «Добавить запись» (Add record) to start a new record.
  7. Select the record type your mail provider specified, either TXT or CNAME.
  8. Enter the selector alone in the subdomain field, for example google._domainkey.
  9. Paste the exact value your mail provider gave you into the value field, checking for stray spaces or line breaks.
  10. Click «Готово» (Done) to save the record, then repeat the add-record steps for a second selector if Microsoft 365 issued one.

Before you save, compare the last few characters of the pasted value with the platform’s page, because a copy that stops early publishes a key that will never verify, and the console won’t warn you. Check the selector in the name against the platform’s page in the same pass.

A few traps are specific to Reg.ru:

Save, then wait, then check

DNS changes made in the Reg.ru zone editor can take minutes up to a couple of hours before DKIM starts validating. The saved record appears back in the same «DNS-серверы и управление зоной» block on the domain’s management page.

Once the record shows in the console, run the free scan against your domain. It asks DNS for the selector the way a receiving server does and tells you in plain words whether the key is published and readable.

Reopen the «DNS-серверы и управление зоной» block after saving to confirm the record shows the selector, type and value exactly as entered.

A second check closes the loop. Send a message from the domain to a mailbox you control and open the Authentication-Results header. dkim=pass with your domain in header.d= means the signature verified against the key you published. dkim=fail or dkim=none with the record in place points at the selector or at the platform side, and the next section says where to look.

When the key is missing or malformed

Without a record at the selector, the receiver gets no key and the message carries no verified signature. It won’t bounce on that alone, though DMARC then has only SPF to lean on, and SPF breaks on forwarding, so the quote a customer forwards to a colleague arrives with neither.

A malformed record fails in the same quiet way: a p= value cut short, a stray space or line break in the middle, a doubled host such as mail._domainkey.yourdomain.com.yourdomain.com, or a selector that’s off by one character, and the receiver logs dkim=fail or dkim=permerror and moves on. You hear nothing unless DMARC reports are arriving, and the DMARC piece shows how those reports expose a DKIM failure per sending source.

The census shows how ordinary that silence is. Of the 75,823,110 domains where the September 2026 census could run the DKIM check, it found a key at a known selector on 37,999,462 (50.1%). That check works the way any checker does: there’s no way to list the DKIM records on a domain, so it can only ask for selectors it knows to try, and a platform with an unusual selector can read as absent when the key is fine.

If your scan reports nothing found while the record sits in the console, finding your DKIM selector shows how to read the live selector out of a sent message’s headers before you change anything.

Work a failure in order: the selector spelling first, the nameservers second, then the tail of the pasted value, then whether the platform still needs you to switch signing on.

Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.