Defaults.Exposed › Setup walkthroughs › DKIM › Beget

How to set up DKIM on Beget

Most DNS (Domain Name System) panels give you a blank Host box and let you type the selector into it. Beget does not. In Beget the selector has to exist as a subzone before any record can hang off it, which means the first move is to create google._domainkey or selector1._domainkey as a subzone, and only then to put the value inside. Paste a perfectly correct key without that step and it goes nowhere, which is why a working key so often looks broken here.

Who makes the key, and who publishes it

The key never comes from Beget. Whoever runs your mailboxes generates a key pair inside their own admin console, keeps the private half, and signs your outgoing mail with it. They give you the public half plus a short label called a selector. A receiving mail server reads that selector out of your message’s DKIM-Signature header, looks up <selector>._domainkey.yourdomain.com, and tests the signature against the key that answers.

Beget publishes whatever DKIM (DomainKeys Identified Mail) record the mailbox provider hands you, under the selector name the provider chose. If Microsoft 365 issued two selectors, each subzone gets created and filled in separately. The DKIM guide covers what the receiver does once the lookup succeeds.

Beget is the DNS host and, for many of its customers, the registrar and web host as well. That is why the split confuses people: one company does three jobs, and the fourth, mail signing, sits with someone else.

Check the nameservers before you start

A DKIM record only works where the domain’s nameservers point. Beget’s nameservers are the default for a domain registered or hosted at Beget, so if you never changed them you are in the right console. If the nameservers point at Cloudflare, another host or the email provider instead, the record has to go there, not in Beget, and nothing you save here will ever be read.

What you are publishing

Laid out the way Beget expects it, the record looks like this:

TXT:   v=DKIM1; k=rsa; p=[the long key your mail provider generated]
CNAME: [the ...onmicrosoft.com target your mail provider generated]

The subzone name takes the selector alone, google._domainkey or selector1._domainkey, never the full domain, because Beget appends the domain automatically and doubling it up creates a broken host. The record type field in the Quick add block takes TXT for most providers or CNAME for Microsoft 365. The data field takes the TXT (Text) key beginning v=DKIM1; or the CNAME (Canonical Name) target ending onmicrosoft.com, pasted in full. Beget does not ask for a TTL (Time to Live) on this record.

Add the record in Beget

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 Beget control panel and open the DNS section.
2. Select your domain in the list at the top of the DNS section.
3. Click Добавить подзону, meaning Add subzone, to start a new subzone.
4. Name the subzone after the selector host alone, for example google._domainkey or selector1._domainkey.
5. Select the new subzone in the list, then click Открыть режим редактирования, meaning Open editing mode.
6. In the Быстрое добавление block, meaning Quick add, set the record type to TXT or to CNAME to match what your provider gave you.
7. Paste the value your provider gave you into the data field for that record.
8. Save the record, then repeat the whole subzone process for selector2._domainkey if Microsoft 365 issued two records.

Traps specific to Beget

• Beget has no free-form Host box on the main record form. The selector host has to exist as its own subzone before you can attach a record to it, and skipping that step is the most common failure here.
• Typing the full domain into the subzone name, such as google._domainkey.yourdomain.com, doubles the domain once Beget appends it and produces a host that never resolves.
• The console labels are in Russian: Добавить подзону, Открыть режим редактирования and Быстрое добавление. Confirm the exact wording in your own console before you click.
• Adding a TXT record where the provider issued CNAME records, or the reverse, means DKIM never validates even though a record is published.
• The key is hundreds of characters long, and a stray space, a line break or a truncated paste breaks it in ways that look identical to a correct key at a glance.

The selector matters character for character, because the receiver builds its lookup from the s= tag your provider signs with. selector1 and selector2 are two different keys, and google and google1 are not the same request. Copy the name across rather than typing it from memory.

Save, wait, then check

DNS changes generally take minutes up to a couple of hours before DKIM starts validating, so a check run immediately after saving can read as absent when nothing is wrong. The saved record appears against the subzone you created, under the domain’s DNS section, and that listing is the quickest confirmation that the subzone step took.

Once it is showing, run the free scan against your domain. It makes the same selector lookup a receiving mail server makes, and reports whether a readable key came back.

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

A check from the mail side covers the signing, which the DNS lookup cannot. Send yourself a message from the domain and read its Authentication-Results header. dkim=pass with your domain in header.d= means the signature verified against the key sitting in your Beget zone.

Reading a failure

Start with the subzone, since that is the step this console adds and no other console has. Confirm the subzone exists, that it is named for the selector alone, and that the record sits inside it rather than at the top of the domain’s zone. Then check the record type against what your provider issued. Then check the tail of the pasted value for a truncated copy. Then check the nameservers.

If all of that is right and the 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 the October 2026 census could run the DKIM check, it found a key at a known selector on 38,666,798 (50.5%), and found no key at any selector it tried on the other 37,896,567 (49.5%). That second group includes the domains whose keys sit under a selector the census doesn’t try.

If you are unsure which selector is live, finding your DKIM selector shows how to read it out of the headers 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.