How to Configure DKIM for Custom Domains

What DKIM Is and Why It Matters for Email Deliverability

Your mail server attaches a cryptographic signature to every message it sends. That signature is DKIM, short for DomainKeys Identified Mail.

The receiving provider checks the signature against a key you publish in DNS. If it validates, the message came from your domain and nobody edited it on the way. If there's no signature at all, or the key doesn't match, the message starts out with a strike against it, and spam is where a lot of those end up.

This is the cheapest deliverability work available to you. Twenty minutes of DNS edits, done once, versus the weeks it takes to warm a domain. We've written separately about how to test whether your cold email is actually landing.

The IETF's email architecture draft describes where DKIM sits in the wider mail system. Most providers check for it by default now, so leaving it unconfigured is not a neutral choice.

Understanding DKIM Record Setup Fundamentals

Three pieces make DKIM work, and the names are more intimidating than the things themselves: a selector, a public key, and a private key.

The selector is a label you pick. "default", "mail", your company name, it genuinely doesn't matter. It exists so one domain can carry several keys at once without them colliding.

The public key goes into DNS, where any mail server on the internet can read it. Its private half never leaves your sending infrastructure, and that's the part that does the actual signing.

The three DNS records you need

When you're setting up a custom sending domain, you add records at your DNS provider that point receiving servers to your public key.

Most platforms give you two or three CNAME records, each pointing at a key they host. A few, Google Workspace among them, give you a single TXT record holding the public key instead. Your email platform will tell you exactly which.

Public and private key pairs explained

A key pair is two mathematically linked codes. One is published, one is secret, and a message signed with the secret half can only be verified with the published half.

So when you send an email, your server runs the message through the private key and produces a signature that's unique to that specific message. Change a single character of the body in transit and the signature stops matching.

Nothing stops you from having more than one key pair, which is the whole reason key rotation is possible. The selector in the signature header tells the receiving server which public key to go fetch.

Generating Your DKIM Selector and Key Pair

Pick a selector name first. Any text works.

After that, your email platform almost certainly generates the key pair for you, which is the outcome you want. Hand-rolling RSA keys and pasting base64 into a DNS field is a good way to introduce a typo you will not find for a month.

SEMAOS generates and stores the keys on its side. Your job is the DNS: an ownership TXT record, three DKIM CNAMEs, plus MX and SPF records on a mail. subdomain.

Adding DKIM Records to Your DNS Provider

Your DNS provider is whoever answers queries for your domain. Sometimes that's your registrar, sometimes it's a separate service like Route 53 or Cloudflare. Worth checking before you start, because people regularly edit records at the registrar and wonder why nothing changes.

Locating your DNS provider's control panel

Log in and look for a section called DNS Management, DNS Records, or Zone File. Every provider names it something slightly different.

There'll be a button to add a record. Click it, then choose the type your platform specified, usually CNAME.

Creating CNAME records for DKIM authentication

A CNAME is an alias. It points one name at another name, and in this case it points at wherever your email platform keeps your public key.

The platform hands you the exact values. The name field will be something like selector._domainkey.yourdomain.com, the type is CNAME, and the value is a host your platform controls.

Copy, don't retype. One wrong character breaks DKIM silently, and the error you get back is the same "not detected" message you'd get if you'd added nothing at all. Add all three records before you go looking for results.

Then wait. DNS needs time to propagate, normally fifteen minutes to a couple of hours, occasionally the full 24.

How to Verify DKIM Record Configuration

There are two verifications worth running, and they answer different questions. Your platform's check tells you whether it can see its own records. A lookup you run yourself tells you what the rest of the internet sees. Do both.

What a correct DKIM record looks like in DNS

The public key lives at a name assembled from the selector and your domain:

selector._domainkey.yourdomain.com

Query that for a TXT record and you should get a string that opens with v=DKIM1, then k=rsa, then p= and a long base64 blob. Some providers hand you CNAMEs instead of a raw TXT record, in which case the CNAME points at a host they control that serves the TXT value on your behalf. Both shapes are fine. What matters is that the final resolved answer contains a p= value.

From a terminal:

dig TXT selector._domainkey.yourdomain.com +short

On Windows, nslookup -type=TXT selector._domainkey.yourdomain.com does the same job.

Reading the result

DNS propagation is not instant

New records don't land everywhere at once. Authoritative nameservers update immediately, but recursive resolvers all over the world keep handing out the old answer until the TTL runs down.

What I'd actually do: publish, wait fifteen minutes, run the lookup. Nothing back? Try a tool that queries from a different resolver before you assume you've made a mistake. A record that one resolver can see and another can't is propagation doing its thing.

Confirming signatures on real mail

A readable record only proves the key is published. It says nothing about whether your server is signing, and those two things fail independently. Send a test message to a mailbox outside your own organization, open the full headers, and find the Authentication-Results line. You want dkim=pass along with your domain and selector. dkim=none means the message went out unsigned, which points at the sending path rather than DNS.

Monitoring after the first pass

The first green check is the easy part. What actually costs people money is a record quietly vanishing eight months later, when someone migrates DNS providers or tidies up a zone file nobody has documented. Two habits head that off:

• Re-run the lookup on a schedule. Monthly is plenty for a domain nobody is touching. Weekly if DNS is in flux.
• Watch Authentication-Results on real outbound mail, not just the test you sent yourself in March. A shift from dkim=pass to dkim=none is the earliest warning you'll get.

SEMAOS lists every record your custom sending domain needs, and its verify step checks the DKIM records and the ownership record against live DNS. Once a domain is verified, SEMAOS doesn't keep re-checking it, so the ongoing monitoring is still on you.

DKIM Setup for Microsoft 365

Microsoft 365 won't DKIM sign mail from your custom domain until you publish two CNAME records for it and turn signing on. Microsoft generates and holds the keys itself, so you'll never see a private key or paste a public one anywhere.

The two CNAME records Microsoft gives you

Each custom domain you set up for DKIM gets two selectors, selector1 and selector2. Only one signs at a time. The other waits for the next key rotation, which is how Microsoft swaps keys without a gap in signing. For a domain added since May 2025 the records look like this:

Older domains point at selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com instead, and the letter before -v1 varies from tenant to tenant. So don't build these by hand. Copy the exact values Microsoft shows you. The target encodes your domain with dashes where the dots were, which is exactly the kind of thing that gets mistyped, and a mistyped target resolves to nothing at all.

Enter the host name as selector1._domainkey only. Most DNS providers append your domain automatically, and typing the full name gets you selector1._domainkey.yourdomain.com.yourdomain.com.

Where to click

DKIM for Microsoft 365 lives in the Microsoft Defender portal, not the admin center. Your domain has to be added in the Microsoft 365 admin center first, then:

1. Sign in at security.microsoft.com and go to Email & collaboration, Policies & rules, Threat policies, Email authentication settings. Open the DKIM tab and select your domain.
2. Try to turn signing on. Microsoft refuses with an error that lists the two CNAME values, and the domain's status changes to CnameMissing. Copy the values from the Publish CNAMEs section of the domain's details.
3. Add both records at your DNS provider.
4. Give Microsoft a few minutes (sometimes longer) to see them, then open the domain again and turn on "Sign messages for this domain with DKIM signatures".

When it works, the domain reads "Signing DKIM signatures for this domain" and the status on the DKIM tab is Valid.

Rotating keys

Rotation needs no DNS changes. Your CNAMEs already point at Microsoft, and Microsoft publishes each new public key behind them. That is the whole point of the CNAME setup.

Open the domain on the DKIM tab and select Rotate DKIM keys. The status changes to "Rotating keys for this domain and signing DKIM signatures", and the old key keeps signing for four days (96 hours) while the new one propagates. After that the other selector takes over. You can't start another rotation until this one finishes.

Keys are 1024-bit by default. To move to 2048-bit, run Rotate-DkimSigningConfig -Identity yourdomain.com -KeySize 2048 in Exchange Online PowerShell. The larger key only reaches the selector that becomes active, so you need a second rotation, 96 hours after the first, before both selectors carry 2048-bit keys.

The one way to break rotation yourself is to delete or edit one of the two CNAMEs, to tidy up the zone. Leave both in place for as long as the domain sends through Microsoft 365.

What to check when signing does not start

How this differs from a platform that issues its own DKIM records

Microsoft keeps the private key and signs on its own infrastructure. Platforms that send on your behalf, SEMAOS included, work the same way on that point, but the records are their own: on SEMAOS a custom sending domain needs an ownership TXT record at _semaos.yourdomain.com, three DKIM CNAMEs, and MX and SPF records for a mail. subdomain. You publish them and the platform signs with the matching private key. If you're on SEMAOS's shared sending domain, DKIM and DMARC are already configured and there's nothing for you to publish.

Troubleshooting Common DKIM Configuration Issues

When DKIM doesn't come up, it's usually one of a handful of things, and none of them are interesting.

Wrong record type is the most common. DKIM uses CNAME records here, not A and definitely not MX. After that it's typos, which is what happens when someone reads the value off one screen and types it into another instead of copying it. And a decent share of "broken" setups aren't broken at all, just young: the records are right and DNS hasn't caught up yet.

If you've ruled all that out and verification still fails, stop guessing and ask your email platform's support to read back the values they expect. They can see their side of the lookup and you can't.

DKIM, SPF, and DMARC: How They Work Together

DKIM is one leg of a three-legged email authentication setup. SPF and DMARC are the others.

SPF publishes a list of machines allowed to send mail for your domain. Simpler to set up than DKIM, and weaker: it breaks the moment a message gets forwarded, because the forwarding server isn't on your list.

Where they complement each other:

Most providers check all three. Miss one, or break one, and you lose inbox placement you were otherwise entitled to.

Do DKIM now, it's the shortest job. Then publish DMARC at p=none and actually read the reports for a few weeks before you tighten the policy.

FAQ