Last updated: July 2026

In short: domainfactory offers no DKIM wizard like it does for SPF. After this guide you publish the public DKIM key of your sending service as a TXT record in the nameserver settings.

Prerequisites

  • A domainfactory account with access to the customer menu
  • The public DKIM key or CNAME specifications of your sending service (Microsoft 365, newsletter tool, your own server)

What is DKIM?

DKIM (DomainKeys Identified Mail) adds a digital signature to outgoing email, which the recipient checks via a public key published in DNS. domainfactory aptly describes DKIM in its own docs as an application example for TXT entries — it is “used similarly to SPF for authenticating sending email servers”.

For context: while SPF authorizes the server, DKIM secures the message. Only with DMARC does it become an enforceable foundation.

The starting point at domainfactory — important

Unlike with SPF, domainfactory has no DKIM wizard and no one-click DKIM signing for classic mailboxes. There simply is no DKIM article in domainfactory’s email FAQ — only SPF.

Concretely that means: DKIM at domainfactory doesn’t come from domainfactory itself, but from your sending service. It generates the key pair and gives you the public part. Your job at domainfactory is only to publish it as a TXT record (or CNAME, depending on the service). Three typical cases:

  1. You send via Microsoft 365 (with domainfactory as DNS): follow the DKIM guide for Microsoft 365 — there you get two CNAME values that you enter here.
  2. You send via an ESP/newsletter service: the service gives you a selector and key; you enter them as a TXT record.
  3. You send via your own mail server: your server (e.g. Mailcow) generates the key; you publish the TXT record.

Step-by-step guide

1. Get the key/selector from your sending service

At your sending service you’ll find the DKIM selector (e.g. selector1, s1, default) and the public key v=DKIM1; .... Note the full hostname selector._domainkey and the value.

2. Open the nameserver settings

In the customer menu, click Nameserver settings in the left menu column. In the list, click Edit to select the domain you’re setting up DKIM for.

3. Create the TXT record (or CNAME)

Create a new entry:

  • Hostname: selector._domainkey (the selector is dictated by your service)
  • Type: TXT — for a direct key. If your service requires a delegation instead (like Microsoft 365), choose CNAME and enter the specified target value.
  • Value: the v=DKIM1; ... string supplied by the service, or the CNAME target.

TXT entries at domainfactory are explicitly intended for exactly such services, “for which no dedicated entry type is available”.

4. Wait until the change is live

DNS changes take time — a few hours depending on caching. If you’ve made a mistake, you can restore the nameserver entries to their original state via “Reset nameserver entries” (careful: this also removes other changes).

Verify the result

Check your configuration with the free MXAudit scanner — it shows you DKIM, SPF, and DMARC at a glance.

Common mistakes

Expecting a DKIM wizard. Unlike with SPF, there isn’t one at domainfactory — the key always comes from your sending service.

Wrong selector hostname. The entry must be named exactly selector._domainkey, with your service’s selector. A different name makes the signature impossible to find.

TXT instead of CNAME (or vice versa). Microsoft 365 requires CNAMEs, a classic ESP often a TXT key. Use the type your service specifies.

No signing server behind it. The DNS entry alone signs nothing — the signing happens at your sending service. Both must fit together.

Further reading