OX Cloud DKIM per maildomain

Deployment status

We are currently working on deploying this new solution in our OX Cloud production environments.

It will be available to our OX Cloud US customers first - and we'll update with an availability date, as soon as we have it, and have verified that everything is working accordingly.

What is DKIM?

DomainKeys Identified Mail (DKIM) is an email authentication standard that uses a digital signature to verify an email's origin and ensure its content hasn't been altered, preventing spam and phishing by linking the message to a specific domain owner. 

In 2024 Gmail and Yahoo introduced stricter sender requirements, forcing large senders to authenticate with SPF, DKIM and DMARC, to provide easy one-click unsubscribes, and maintain low spam complaint rates to ensure better inbox security and relevance. This initiative was nicknamed "Yahoogle". In November 2025 Yahoo & Gmail further ramped up the enforcement of non-compliant traffic (https://support.google.com/a/answer/14229414?hl=en).

Relevant standards documentation:

A few words on the Why?

The email world is moving towards a situation where it becomes increasingly important that mails are signed by DKIM and that the DKIM alignment is respected.

Without it, your outbound messages might pass SPF, but still get flagged as unauthenticated. This triggers spam filters, fails DMARC alignment, and increases exposure to spoofing and phishing.

In order to accommodate this shift in requirements, we've built a DKIM solution where we can DKIM sign per maildomain with dedicated keys.

If you have not implemented this solution, then our fallback is to sign with the default brand-based key and a signing domain we control which creates valid DKIM signatures but are NOT aligned and not suitable for positive DMARC results.

Especially for customers that heavily depend on forwarding, it's recommended to implement DKIM signature per maildomain, for deliverability purposes.

A prerequisite for using the service is the following: 

Before the DNS CNAME records can be created, there must be users created with email addresses using the corresponding domain or a shared maildomain must exist.

How does the solution work?

As a mailbox provider, we do not have access to your DNS - and a working DKIM solution requires that the mailserver can check the public key pairs through DNS.

We are storing the private keys on our servers, but it requires that you configure a CNAME in DNS that points to a special TXT entry under oxcloud.zone. 

The solution currently signs with RSA keys. We will be adding support for EC keys at a later stage.

The solution also supports easy key rotation, which is triggered automatically, without involving the end user or our customers.

We provide an OX Cloud DKIM API, which can generate, remove and rotate keys. The documentation of the API is found in the link above.

The DKIM key generation API call also creates the TXT records with the public keys under the oxcloud.zone domain.

You have to create the CNAME records in DNS for your domain. Depending on your DNS solution how you add that CNAME entry may vary.

Description of the process

Step 1 : Check for existing DKIM keys

Check in DNS for regular keys - this requires that you already know the name of the selector.

A DKIM selector is essentially a method used to distinguish between multiple keys published in a single domain’s DNS records.

DKIM selectors enable the receiving email server to locate and validate the sender’s public key.

You can typically find the selector name by checking the mail source of a sent mail and look for the "DKIM-Signature” section.

We use the simple naming of selector1 and selector2.

dig TXT <selector>._domainkey.example.com +short

Example:

If nothing is setup with that selector name you will get an empty reply.

You can have other selectors set up, and they can co-exist with this setup, so you do not have to delete any other selectors - unless there is name-overlap.

Step 2: Create the DKIM key

a. Setup authentication to the API

Please coordinate this with the OX Key Account Manager or Professional Services.

API access is granted with the standard provisioning credentials.

b. Check access works correctly:

if no keys exist it will return "No DKIM entries found" with http status NOT_FOUND (404)

Depending on which environment you are currently using the URL is different:

c. Check if any keys already exists for the domain?

d. Generate new keys:

Step 3: Create the DNS CNAME entries

Create a CNAME entry in the DNS for the maildomain pointing to "selector1-<domainname>._domainkey.oxcloud.zone"

For the domain name you would have to substitute any dots with dashes, so spamtrap.dk becomes spamtrap-dk

You need to create a CNAME for both selector1 and selector2, so it's set up for the later key rotation to happen.

Example:

We suggest you add this as part of your account creation provisioning process, so right after the first email account on a domain is created, 

you generate the per maildomain DKIM keys for the domain. Similar if the domain is deprovisioned, we encourage you to remove any old keys before deprovisioning.

Step 4: Test it works

a. Check the private keys exist on our side:

b. Check the public keys can now be retrieved through the TXT record like in Step 1.

You can also use external tooling to check that the CNAME entry is correct in DNS - like https://mxtoolbox.com/dkim.aspx (it requires the domain name + the selector as input)

Example:

c. Send mail to yourself and check the DKIM signature in the mail source

How to delete existing keys before deprovisioning a domain

a. Delete the active keys through the API

b. Verify the keys are removed

you should get a 404 domain not found 

c. Remove CNAME entries from the maildomain DNS configuraton

This will differ depending on the DNS solution

d. Verify the entry is gone

The empty response will show that the CNAME entries no longer exists