Hosted DKIM

21 June 2026 · 25 min read

What hosted DKIM is

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every message you send. A receiving mail server fetches your public key from DNS, checks the signature against the message body and headers, and - if it matches - can trust that the message wasn't altered in transit and genuinely came from a system that holds your private key. DKIM is one of the two authentication legs DMARC checks (the other is SPF), and a valid, aligned DKIM signature is the most reliable way to pass DMARC, especially once a message has been forwarded or relayed.

Every DKIM record lives at a predictable DNS location:

<selector>._domainkey.<domain>   TXT   "v=DKIM1; k=rsa; p=<public-key>"

The selector is just a label your sending system chooses (google, s1, k1, smtp, whatever) so you can run several signing keys side by side and rotate between them without downtime.

With DMARC Engine's hosted DKIM, you don't publish that TXT record yourself and you don't manage the key material. Instead you publish one CNAME per selector that delegates to us:

<selector>._domainkey.<domain>   CNAME   <selector>.<slug>._domainkey.dmarcengine.com

<slug> is the per-domain hosting slug shown against your domain in app.dmarcengine.com/domains. Once that CNAME resolves, we serve the actual v=DKIM1 TXT content on your behalf from <selector>.<slug>._domainkey.dmarcengine.com, and we take care of key rotation, key strength, and record hygiene going forward. You add a CNAME once; we manage the moving parts behind it.

This guide covers hosted DKIM for keys you generate inside DMARC Engine, how to point common sending platforms (Google Workspace, Microsoft 365, Amazon SES, Mailchimp, SendGrid) at those keys, how rotation works, how to tell DMARC Engine that a selector is managed elsewhere, and how to verify everything lines up.

Related guides: if you haven't set up the base record yet, start with Hosted DMARC. For the SPF side of authentication, see Hosted SPF. If you're deciding between our managed approach and running everything yourself, Hosted vs DIY DMARC lays out the trade-offs. For the full authentication picture including MTA-STS and BIMI, see Hosted Authentication.

Why DKIM alignment matters for DMARC

DMARC doesn't just check that SPF or DKIM passed somewhere - it checks alignment: whether the domain in the DKIM signature's d= tag matches (or is a subdomain of, under relaxed alignment) the domain in the visible From: header. A message can have a perfectly valid DKIM signature and still fail DMARC if that signature's d= domain doesn't align with your From: domain.

This is the single most common reason DKIM "looks fine" in a raw header dump but still shows up as a DMARC failure in your Analytics reports:

• Mailchimp, SendGrid and similar platforms often sign with their own domain (d=mailchimp.com or d=sendgrid.net) by default, using their own key - that's valid DKIM, but it doesn't align with your From: domain unless you set up custom domain signing with a selector on your own domain.
• Forwarded mail frequently breaks SPF (the envelope sender changes) but DKIM survives forwarding intact, provided the forwarder doesn't rewrite the signed body/headers - this is exactly why DKIM matters more than SPF for forwarded mail.
• Multiple sending platforms all signing as your domain, but with clashing or expired keys, will show up as scattered DKIM failures per source in your reports.

Note: DMARC passes if either SPF or DKIM passes and aligns. You don't need both green on every message, but you want each of your legitimate sending platforms covered by at least one aligned, passing mechanism - and for anything routed through your mail from and click-tracking domains, Hosted SPF is the other half of that safety net.

Hosted DKIM (CNAME) vs provider-signed DKIM

There are two fundamentally different ways a message ends up with an aligned DKIM signature, and it's worth being clear on which one you're using for each sending platform.

In practice, most organisations end up with both kinds active at once: hosted DKIM for anything DMARC Engine signs directly (or for outbound relays you point at our signing endpoint), and provider-signed DKIM selectors for Google Workspace/Microsoft 365 mailboxes and marketing/transactional platforms that insist on doing their own signing. Both approaches produce a valid, aligned DKIM signature - the only difference is who holds the private key and who's responsible for rotating it. DMARC Engine's DKIM builder tracks every selector for the domain regardless of which category it falls into, so your dashboard gives you one place to see all of them.

Tip: if you're not sure which category a given sending tool falls into, check that tool's own DKIM/authentication setup page first - nearly all of them tell you outright whether they expect a CNAME (delegated key) or a raw TXT value (fixed key) for their DKIM selector.

Generating a hosted DKIM key and selector

1. Sign in to app.dmarcengine.com and open Domains.
2. Select the domain you want to add DKIM to. If the domain isn't listed yet, add it first - hosted DKIM requires the domain to already be under management.
3. Open the DKIM builder from the domain's service list, or navigate there directly and pick the domain from the selector.
4. Click Generate key. Choose:
5. - Selector name - a short label (letters, digits, hyphens). If this is your first hosted key, dmarcengine or s1 is a sensible default; if you expect to rotate keys manually rather than automatically, a dated selector like 2026a makes it obvious at a glance which key is active.
6. - Key strength - DMARC Engine defaults to 2048-bit RSA, which is the current best-practice minimum. Leave this as-is unless you have a specific reason to change it (some very old DNS resolvers historically struggled with very long TXT records, which is one reason we serve it as a CNAME rather than asking you to paste a giant key into your own zone).
7. Click Create. DMARC Engine generates the key pair, stores the private key securely, and shows you the CNAME record to publish.
8. Copy the CNAME record shown in the app. It will look like this (with your actual domain, selector and slug filled in):

   Host:  google._domainkey.example.com
   Type:  CNAME
   Value: google.acme-corp._domainkey.dmarcengine.com
   TTL:   3600 (or your DNS provider's default)
   

1. Log in to your DNS provider (Cloudflare, GoDaddy, Route 53, etc.) and add that CNAME record exactly as shown - host, type and value must match, and don't add a trailing dot unless your provider requires one for CNAME targets.
2. Save the change in your DNS provider and return to the DKIM builder in DMARC Engine.
3. Click Check status (or wait for the next automatic scan). Once the CNAME has propagated, the builder shows the selector as Active and starts serving your public key at that location.

Warning: DNS propagation isn't instant. Give it anywhere from a few minutes to a few hours depending on your provider and the record's previous TTL. Don't start pointing a live sending platform at a selector until DMARC Engine shows it as Active - a selector that a sender references before it resolves will simply fail to verify, which looks identical to a broken signature to the receiving mail server.

Once the selector is Active, you can use it in two ways depending on the sending platform:

• Sign with it directly. If you're relaying outbound mail through a system DMARC Engine controls the signing for (for example, our SMTP relay or an integration that calls our signing API), point that system at the selector and it starts signing immediately using the hosted key.
• Hand the selector to a platform that signs itself - this is the Google Workspace/Microsoft 365/SES pattern below, where the platform generates its own key and you publish a CNAME to their DKIM host rather than ours. In that case the selector you create in step 4 is really just a placeholder for tracking; skip ahead to "Setting up common senders."

Choosing selector names

Selector names are arbitrary labels - DKIM doesn't attach any meaning to them beyond being unique within the domain's _domainkey namespace - but a few conventions make life easier later:

• Match the platform's own selector where it assigns one. Google, Microsoft 365, SES and SendGrid all pick (or let you pick) a specific selector string; use that exact string in DMARC Engine and in DNS rather than renaming it, otherwise you'll spend time cross-referencing two different names for the same key.
• Use something identifiable for keys you generate yourself. dmarcengine, a platform name (smtp-relay), or a short date stamp (2026a) all work; avoid generic labels like default once you have more than one selector, since it becomes ambiguous in reports.
• Keep it short. Selectors become part of a DNS hostname (<selector>._domainkey.<domain> and, for hosted keys, <selector>.<slug>._domainkey.dmarcengine.com), and very long labels can push you closer to DNS hostname length limits, particularly on domains that already have a long name.
• Never reuse a selector name for a different key. If you retire a selector and later want to reuse the same label for an unrelated key, delete the old DNS record fully first and confirm it's stopped resolving - otherwise a receiving server caching the old key may validate (or fail to validate) against stale data during the transition.

Setting up common senders

Most sending platforms give you a DKIM selector and a value (either a full public key or their own CNAME target) to publish. Because DMARC Engine hosts your _domainkey subdomain via CNAME per selector, you add one CNAME per platform selector to your zone, alongside any hosted-DKIM selectors from the previous section. The platform's own signing infrastructure does the rest.

Google Workspace

1. In the Google Admin console, go to Apps → Google Workspace → Gmail → Authenticate email.
2. Select the domain and click Generate new record. Choose a 2048-bit key if offered.
3. Google shows a DKIM selector (commonly google) and a TXT record value starting with v=DKIM1; k=rsa; p=....
4. Instead of publishing that TXT value directly, publish a CNAME through DMARC Engine so it's tracked alongside your other authentication records:
5. - In app.dmarcengine.com/dkim, add a selector named google (matching Google's selector exactly) and mark it as managed externally (see below) rather than generating a new hosted key - you want DMARC Engine to know this selector exists and is expected, without it trying to serve its own key material for it.
6. - Publish the DNS record Google actually requires. Google expects the literal TXT value at google._domainkey.example.com, so in this case you publish Google's TXT record directly (not a DMARC Engine CNAME) - see the callout below.
7. In your DNS provider, add:

   Host:  google._domainkey.example.com
   Type:  TXT
   Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...
   

1. Back in the Google Admin console, click Start authentication.
2. Wait up to 48 hours (usually much less) and confirm the status shows Authenticating email with DKIM.

Note: Google Workspace signs with its own key and doesn't support delegating that key to a third party via CNAME - it needs the literal TXT value at its selector. That's fine: DMARC Engine's job here is to make sure this selector is recorded so nothing in your monitoring or alerts flags it as unexpected, and so your Analytics view correctly labels DKIM results signed d=example.com under selector google as legitimate Workspace mail.

Microsoft 365

1. In the Microsoft 365 admin center, go to Settings → Domains, select your domain, and open DKIM (or use the Exchange admin center → Mail flow → DKIM).
2. Microsoft 365 uses two fixed selectors, selector1 and selector2, and expects CNAME records pointing at Microsoft's own DKIM hosts - which is convenient, since it's the same delegation shape DMARC Engine uses.
3. Before enabling DKIM signing in Microsoft 365, publish both CNAMEs in your DNS provider:

   Host:  selector1._domainkey.example.com
   Type:  CNAME
   Value: selector1-example-com._domainkey.example.onmicrosoft.com

   Host:  selector2._domainkey.example.com
   Type:  CNAME
   Value: selector2-example-com._domainkey.example.onmicrosoft.com
   

(Microsoft shows you the exact target values for your tenant in the DKIM screen - copy them from there rather than guessing the pattern.)
4. In app.dmarcengine.com/dkim, add both selector1 and selector2 and mark them managed externally, so DMARC Engine tracks them without trying to serve its own key.
5. Back in the admin center, toggle Enable for DKIM signing on the domain.
6. Allow propagation, then confirm the toggle stays enabled (Microsoft flips it back off automatically if it can't resolve the CNAMEs).

Warning: if you enable DKIM signing in Microsoft 365 before the CNAMEs resolve, Microsoft 365 will silently fail to sign with DKIM (falling back to its default onmicrosoft.com selector, which won't align with your domain) and may reset the toggle off. Publish the DNS first, confirm it resolves, then enable.

Amazon SES

1. In the Amazon SES console, open Verified identities, select your domain, and go to the Authentication tab.
2. Under DKIM, choose Easy DKIM and select RSA_2048_BIT (Amazon's recommended default over the older 1024-bit option).
3. SES generates three CNAME records, each with an SES-specific selector (for example abcd1234...), pointing at *.dkim.amazonses.com:

   Host:  abcd1234._domainkey.example.com
   Type:  CNAME
   Value: abcd1234.dkim.amazonses.com

   Host:  efgh5678._domainkey.example.com
   Type:  CNAME
   Value: efgh5678.dkim.amazonses.com

   Host:  ijkl9012._domainkey.example.com
   Type:  CNAME
   Value: ijkl9012.dkim.amazonses.com
   

1. Publish all three CNAMEs in your DNS provider exactly as SES shows them.
2. In app.dmarcengine.com/dkim, add each of the three selectors and mark them managed externally.
3. Return to the SES console; the identity's DKIM status changes to Successful once SES can resolve all three CNAMEs (this is usually fast since you're just delegating straight to Amazon).
4. If you use configuration sets or multiple sending domains/subdomains in SES, repeat this per identity - each verified identity gets its own three selectors.

Tip: Amazon SES supports DKIM key rotation automatically for Easy DKIM identities on a rolling basis; you don't need to republish these CNAMEs when SES rotates behind the scenes, because you delegated to their host rather than pinning a specific key value.

Mailchimp

1. In Mailchimp, go to Domains (under account settings) and add/verify the sending domain you use for campaigns.
2. Mailchimp's domain verification includes a CNAME-based DKIM record using the selector k1 (or mte1 for Mandrill/Transactional Email):

   Host:  k1._domainkey.example.com
   Type:  CNAME
   Value: dkim.mcsv.net
   

1. Publish that CNAME in your DNS provider.
2. In app.dmarcengine.com/dkim, add selector k1 and mark it managed externally.
3. In Mailchimp, click Verify Domain and wait for the green check.

Warning: by default Mailchimp signs campaign mail with d=mailchimp.com or d=mcsv.net alongside your custom domain's SPF, which does not align with your From: domain for DMARC purposes unless you complete Mailchimp's domain authentication (the steps above). Skipping this step is the single most common reason marketing sends fail DMARC while transactional mail from the same organisation passes fine.

SendGrid

1. In SendGrid, go to Settings → Sender Authentication → Authenticate Your Domain.
2. Choose your DNS host if prompted (this only affects the record format SendGrid shows you, not what you actually publish) and select whether to use automated security (recommended) so SendGrid rotates keys for you.
3. SendGrid gives you three CNAME records: one for a DKIM selector pair and one for a tracking/link domain, similar to:

   Host:  s1._domainkey.example.com
   Type:  CNAME
   Value: s1.domainkey.u1234567.wl123.sendgrid.net

   Host:  s2._domainkey.example.com
   Type:  CNAME
   Value: s2.domainkey.u1234567.wl123.sendgrid.net

   Host:  em1234.example.com
   Type:  CNAME
   Value: u1234567.wl123.sendgrid.net
   

(Exact hostnames vary per account - always copy the values SendGrid shows you rather than the example above.)
4. Publish all the CNAME records SendGrid lists.
5. In app.dmarcengine.com/dkim, add both DKIM selectors (s1, s2 or whatever SendGrid assigned you) and mark them managed externally.
6. In SendGrid, click Verify on the domain authentication screen.
7. If SendGrid's "automated security" is enabled, it rotates the underlying keys behind these same CNAMEs periodically - you don't need to touch DNS again for routine rotation.

Note: the third CNAME above (the "link branding"/em____ record) isn't DKIM - it's for click-tracking domain alignment, which affects link reputation but not DKIM/DMARC directly. Publish it if SendGrid asks for it, but it's a separate concern from the DKIM selectors.

Marking a selector as managed externally

Every selector you add in app.dmarcengine.com/dkim - whether it's a hosted key you generated or one belonging to Google, Microsoft, SES, Mailchimp, SendGrid, or any other platform - needs a status so DMARC Engine's monitoring knows what to expect.

1. Open DKIM for the domain.
2. Click Add selector (or select an existing one you added while it was still pending).
3. Enter the exact selector name the sending platform uses (case-sensitive matching to what appears in DNS).
4. Under Key source, choose:
5. - Hosted by DMARC Engine - we generated the key; the record is a CNAME to us and we manage rotation. Use this only for selectors created via "Generate key" in this guide.
6. - Managed externally - the sending platform (or you) owns the key and the DNS record; DMARC Engine just tracks that this selector is expected and valid. Use this for Google, Microsoft 365, SES, Mailchimp, SendGrid and any similar platform-signed selector.
7. Optionally add a note (e.g. "Google Workspace - added 2026-07-04") so future admins on your team know why the selector exists.
8. Save.

Once marked, an externally-managed selector shows up in your DKIM inventory and in Analytics DKIM breakdowns, but DMARC Engine won't attempt to rotate its key or flag its DNS shape as "not one of ours" - it's simply recorded as an expected, sanctioned signer for the domain.

Tip: doing this consistently for every platform means that when you later look at Alerts or Threats, any DKIM selector you haven't recorded and marked stands out immediately as something to investigate - either a forgotten legacy sender or, worse, someone else signing mail as your domain.

Key rotation

Rotating a DKIM key means generating a new key pair, publishing the new public key under a new (or the same) selector, letting senders switch to signing with the new private key, and eventually retiring the old one. Regular rotation limits the damage if a private key is ever exposed, and it's considered standard hygiene even without a specific incident.

How often should you rotate?

There's no single rule enforced by the DKIM specification, but a reasonable working cadence for most organisations is:

• Hosted selectors - DMARC Engine defaults to rotating on a periodic schedule automatically (visible per-selector in the DKIM builder), so you generally don't need to think about cadence at all. If you want a tighter or looser schedule for a particular selector, you can trigger a manual rotation at any time regardless of the automatic schedule.
• Externally-managed selectors - follow the platform's own guidance. Amazon SES and SendGrid rotate automatically under Easy DKIM/automated security. Google Workspace and Microsoft 365 don't rotate on a fixed timer by default, so it's worth calendaring a manual rotation roughly once a year, or immediately after any suspected credential exposure.
• Immediately, regardless of schedule - rotate any selector as soon as you suspect the private key (or an admin account with access to trigger signing) may have been compromised, or when an employee who had access to raw signing credentials leaves.

Tip: because hosted rotation requires no DNS change on your side, there's no operational reason to delay it - unlike a self-managed TXT record, there's no risk of forgetting to update DNS and breaking signing. That's the main argument for preferring hosted selectors over pasting a platform's raw key into your own zone wherever a platform gives you the choice.

Rotating a hosted key

1. Open DKIM for the domain.
2. Find the selector you want to rotate and click Rotate key.
3. DMARC Engine generates a new key pair automatically and - because the DNS record is a CNAME pointing at us rather than a static TXT value you published - updates what it serves at that same hostname immediately. You do not need to touch DNS for a rotation of a hosted selector; the CNAME you published once keeps pointing at the same place, and we simply change what resolves behind it.
4. DMARC Engine keeps the previous key valid for a short overlap window (shown on the rotation screen) so any signature already generated with the old key still verifies while the change propagates through DNS caches, then retires it.
5. Confirm the selector still shows Active after rotation and spot-check a fresh outbound message's DKIM header if you have a way to send a live test.

Note: automatic, zero-touch rotation is the main practical benefit of hosted DKIM over pasting a static TXT value into your own zone - you get the security hygiene of regular rotation without a recurring DNS change every time.

Rotating an externally-managed key

For selectors you marked as managed externally, rotation is controlled by that platform, not by DMARC Engine:

1. Trigger rotation from the platform itself - Google Workspace and Microsoft 365 offer a manual "rotate"/regenerate option in their admin consoles; Amazon SES and SendGrid rotate automatically under Easy DKIM / automated security without any action from you.
2. If the platform gives you a new selector name (rather than rotating the key behind the same selector), add the new selector in app.dmarcengine.com/dkim and publish its DNS record following the same steps as the original setup, before removing the old one.
3. Only remove the old selector's DNS record and its entry in DMARC Engine once the platform confirms it has fully switched to signing with the new key - removing it early will break DKIM for any mail still in flight signed with the old key.

Warning: never delete a DKIM selector's DNS record while it's still actively signing outbound mail, even temporarily "to test something." A receiving server that can't resolve the selector treats the signature as unverifiable, which typically counts the same as a DKIM failure for DMARC purposes.

Verify it worked

1. Check selector status in the app. Open app.dmarcengine.com/dkim - every selector for the domain should show Active (hosted) or Verified (externally managed), not Pending.
2. Confirm the DNS record resolves correctly. Use the free DNS lookup tool or the in-app Lookup checker, and query the selector directly from a terminal:

   dig CNAME google._domainkey.example.com
   dig TXT google._domainkey.example.com
   

For a hosted selector, the CNAME query should return your <selector>.<slug>._domainkey.dmarcengine.com target, and the TXT query (which most resolvers will chase through the CNAME automatically) should return a v=DKIM1; k=rsa; p=... value.
3. Send a real test message through each sending platform you configured (Workspace/365 mailbox, an SES test send, a Mailchimp test campaign, a SendGrid test API call) to an inbox you control - Gmail is convenient because it exposes authentication results easily.
4. Open the message headers. In Gmail: open the message, click the three-dot menu, choose Show original. Look for the Authentication-Results header and confirm:

   dkim=pass header.i=@example.com header.s=google
   

dkim=pass confirms the signature validated; header.i=@example.com matching your sending domain (not the platform's own domain) confirms alignment.
5. Check DMARC Engine's own reports. Aggregate (RUA) data typically arrives within 24 hours of a real send. In Analytics, filter by source/sending IP and confirm the DKIM column shows pass for that platform's traffic, and check Reports for the underlying raw records.
6. Watch for drift. Add the domain to Audit if you haven't already, so any future change to a DKIM CNAME's target (accidental deletion, a DNS provider migration that drops records, a platform changing its CNAME target) triggers an Alert rather than silently degrading your DKIM coverage.

Common problems and fixes

Note: if a problem doesn't match this table, app.dmarcengine.com/support has the full ticket queue - include the domain, selector name, and output of a dig query for the selector when you open a ticket; it saves a round trip.

FAQ

Do I need a separate DKIM selector for every sending platform?
Yes. Selectors exist precisely so you can run several signing keys - one per platform - side by side. Reusing one selector across platforms that don't share a key will break verification for whichever platform didn't generate that key.

Can I use hosted DKIM and provider-signed DKIM on the same domain?
Yes, and most organisations do. Hosted keys for anything DMARC Engine signs directly, provider-signed selectors (marked "managed externally") for Google Workspace, Microsoft 365, SES, Mailchimp, SendGrid and similar. They coexist fine as long as each selector is unique.

What key length does DMARC Engine use for hosted keys?
2048-bit RSA by default, which meets current best practice. We don't recommend dropping to 1024-bit; some receivers now treat 1024-bit RSA DKIM keys as weak.

Does rotating a hosted key ever require me to touch DNS again?
No. Because the record you published is a CNAME to DMARC Engine rather than a static TXT value, rotation happens entirely on our side - the CNAME target never changes, only what it resolves to.

What happens if I delete a DKIM selector's CNAME by mistake?
Any mail signed with that selector afterwards fails DKIM verification at the receiving end (the public key can't be found). If the domain has other passing, aligned mechanisms (SPF alignment, or another DKIM selector) DMARC can still pass overall; otherwise messages relying solely on that selector will fail DMARC. Republish the CNAME as soon as you notice - there's no grace period.

Why does my DMARC report show dkim=fail for mail signed by Mailchimp or SendGrid even though the platform says authentication succeeded?
The platform's own "authenticated" status usually just means the DKIM signature itself is cryptographically valid - it doesn't guarantee alignment with your From: domain. Check whether the platform is signing with its own domain (mailchimp.com, sendgrid.net) rather than yours, and complete the platform's custom/branded domain authentication if so.

Is a raw TXT record still an option instead of the CNAME?
Yes - for hosted keys, self-managed (publishing the v=DKIM1 TXT value directly yourself, without delegating to DMARC Engine) is always the manual alternative to the CNAME. It's what you're already doing implicitly for any platform-signed selector (Google, SES, etc.) where the platform, not DMARC Engine, owns the key. The trade-off is that you then own rotation and any future record changes yourself.

How many DKIM selectors can a domain have?
There's no hard limit imposed by DMARC Engine or the DKIM specification itself, though DNS TXT/CNAME record limits and practical management overhead are the real constraints. Most domains run somewhere between two and six active selectors across their sending platforms at any given time.

Does hosted DKIM affect my SPF lookup count?
No - DKIM and SPF are entirely separate mechanisms with separate DNS namespaces (_domainkey vs the domain's own TXT record). If you're running into SPF's 10-lookup limit, that's addressed by Hosted SPF's automatic flattening, not by anything here.

Can I check a DKIM record without a full account?
Yes - the free DNS tools on the public site let you check any domain's DKIM, SPF and DMARC records without signing in. For ongoing monitoring, alerts, and per-selector management, you'll want a domain set up in app.dmarcengine.com/domains.