Defaults.Exposed › Setup walkthroughs › DKIM › REG.RU

How to set up DKIM on Reg.ru

Read the domain’s nameservers before you open anything else, because Reg.ru has two panels that both accept a DNS (Domain Name System) record and only one of them is live for any given domain. ns1.reg.ru and ns2.reg.ru mean the personal account zone editor is authoritative. ns1.hosting.reg.ru and ns2.hosting.reg.ru mean the live zone sits in the hosting control panel instead, and the personal account editor will still accept a record that never reaches the published zone. A correct key added in the panel that is not live will look broken.

Which nameservers, which panel

If the nameservers 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, so the record goes there. If the nameservers name a different company altogether, the DKIM (DomainKeys Identified Mail) record belongs at that company, not at Reg.ru.

Reg.ru is the domain registrar and, for domains left on its own nameservers, the DNS host. Its nameservers answer for 1,910,203 domains in the October 2026 census, 0.59% of the domains that have nameservers. For those domains, the Reg.ru zone is the one receivers read from.

Who makes the key

Reg.ru publishes exactly the TXT (Text) or CNAME (Canonical Name) 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 carries a dedicated article for turning on DKIM and DMARC (Domain-based Message Authentication, Reporting and Conformance) for it.

For every other mailbox provider, the key pair is made inside that provider’s console. It keeps the private half and signs your outgoing mail; you get the public half plus a short label called a selector. A receiving server takes that selector from the DKIM-Signature header, looks up <selector>._domainkey.yourdomain.com, and checks the signature against the key it finds. The DKIM guide covers that check in full.

The record, in Reg.ru’s field names

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
  host  selector2._domainkey   value  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 (Time to Live) on this record type.

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.

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.

Traps specific to Reg.ru

• On hosting nameservers, editing the personal account zone changes nothing the domain answers with, because the hosting control panel holds the live zone instead. This is the trap that wastes the most time here, and nothing in either panel will point it out.
• Putting the full host, including the domain, into the subdomain field produces a doubled domain, because Reg.ru appends the domain for you.
• Adding a TXT record where the provider specified CNAME, or the reverse, means the DKIM record never validates even though the key itself is correct.
• Truncating the key or leaving a stray space or line break in the pasted value breaks the signature even when every other field is right.
• Saving the record in Reg.ru is not the last step for some providers: Google Workspace and others require a separate switch back in their own console to start signing outgoing mail.
• A record that looks published in Reg.ru’s zone editor can still take minutes up to a couple of hours before it resolves publicly.

The selector has to match what the provider signs with, character for character, since the receiver builds its lookup from the s= tag in the signature. Your SPF record belongs in the same zone, as a separate TXT row at the domain root rather than at a selector host.

Save, 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, so reopen that block after saving and confirm the record shows the selector, type and value exactly as entered.

After that, run the free scan against your domain. It queries the selector the way a receiving mail server queries it and reports whether the published key can be read.

How the scan grades this record: the DKIM check, with its pass and fail rules and how many domains pass it.

Finish from the mail side. Send a message from the domain to a mailbox you can open and read its Authentication-Results header. dkim=pass with your domain in header.d= means the published key verified the signature, which is the only result that proves the publishing and the signing are both right.

When it does not pass

Go back to the nameservers first, because the two-panel problem is the one failure unique to this registrar and it survives every other check looking correct. Then the subdomain field for a doubled host, then the record type, then the tail of the pasted value, then whether the provider still needs signing switched on.

If everything is right and a scan still finds nothing, the cause may be how checking works. There is no way to list the DKIM records on a domain, so any checker has to ask for selectors by name and can only ask for the ones it knows to try. A key under a selector the checker doesn’t try is invisible to it, so this scan records that case as not determinable, never as absent. The census has the same limit: of the 76,563,365 domains where it could run the DKIM check, it found a key at a known selector on 38,666,798 (50.5%).

Finding your DKIM selector shows how to read the live selector out of a message you have already sent.

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