DKIM Setup Guide for MSPs Managing Multiple Domains

DKIM adds a cryptographic signature to an email message. A receiving system can retrieve the public key from DNS and use it to verify that the signature is valid for the signing domain and that signed parts of the message were not changed after signing.

For an MSP, the difficult part is rarely the DNS syntax alone. The work is coordinating each sending provider, publishing the right record for the right selector, confirming that signing is enabled, and keeping evidence of what was tested.

How DKIM signing and verification work

The sending platform holds a private key and adds a DKIM-Signature header to each signed message. That header includes, among other values:

• d= — the signing domain;
• s= — the selector that identifies the public key;
• a= — the signing algorithm;
• h= — the headers covered by the signature; and
• bh= and b= — hashes and signature data used during verification.

The receiver combines the selector and signing domain to find the DNS name:

{selector}._domainkey.{signing-domain}

It retrieves the public key and verifies the signature. The current DKIM specification is RFC 6376.

A valid DKIM signature does not prove that a message is safe or that the human sender is who they claim to be. It proves that a system with access to the relevant private key signed the message and that the signed content survived verification.

Why the selector matters

A selector lets one domain use more than one DKIM key. This is useful when:

• separate providers send mail for the same domain;
• an old and new key overlap during rotation;
• different business systems use different signing services; or
• a provider manages key rotation behind a CNAME target.

Selectors are chosen by sending providers or domain operators. They are not globally enumerable. A public checker can test known or commonly used selectors, but a result of “no supported selectors found” is not proof that DKIM is absent.

TXT and CNAME publication patterns

Providers commonly use one of two patterns.

Provider supplies a TXT record

The provider generates a key pair and gives the domain operator a selector plus a TXT value containing the public key. Publish the provider-supplied value at the exact selector name, then enable signing in the provider interface if that is a separate step.

Example shape:

selector1._domainkey.example.co.za. IN TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY_DATA"

The private key stays with the signing provider. Do not ask a customer to send a DKIM private key through email, a ticket, or the Vigil public forms.

Provider supplies a CNAME record

The domain publishes a CNAME from its selector name to a provider-controlled target. This can let the provider change the key served at the target without requiring the customer to replace the CNAME each time.

Example shape:

selector1._domainkey.example.co.za. IN CNAME selector1-example.provider.invalid.

Use the exact target supplied for that tenant and domain. Do not copy a target from another customer.

CNAME delegation is a common scalable pattern when the email provider supports and controls the target. It does not transfer general DNS ownership or give an MSP access to the provider’s private key.

Provider-specific setup

Provider interfaces and record formats change. Use the current official instructions for the tenant being configured:

• Google Workspace: Set up DKIM
• Microsoft 365: Configure DKIM for a custom domain
• Twilio SendGrid: Configure domain authentication

For every provider, record:

1. the service and tenant responsible for sending;
2. the signing domain;
3. the selector or selectors supplied;
4. the required DNS record type and target/value;
5. who approved and published the change;
6. whether provider-side signing is enabled; and
7. how the result was tested.

Do not assume that a published DNS record means signing is active. Some providers require a separate enablement or verification step.

A repeatable MSP workflow

1. Inventory the sending services

Start with the systems that actually send mail using the customer’s visible From domain: primary mail, invoicing, CRM, marketing, helpdesk, monitoring, applications, and low-frequency services.

2. Confirm the signing domain and alignment

The DKIM d= domain must align with the visible From domain for DKIM to contribute to a DMARC pass. Under relaxed alignment, the domains share the same organisational domain. Under strict alignment, they are identical.

3. Generate records in the provider

Use the customer’s own provider tenant. Capture the provider output rather than recreating a public key or guessing a selector.

4. Publish through the authorised DNS process

Check the zone and record name before saving. Avoid accidentally appending the zone twice, publishing at the apex, or placing a TXT value where the provider requires a CNAME.

5. Verify authoritative DNS

Query the authoritative DNS and confirm that the exact expected record is returned. If the record is a CNAME, confirm that the target resolves to the expected DKIM material.

6. Send and inspect a test message

Send from the actual service to a mailbox where the headers can be inspected. Confirm dkim=pass, check the d= and s= values, and verify DMARC alignment. A DNS lookup alone cannot prove that outgoing messages are being signed.

7. Review later DMARC evidence

Aggregate reports can show whether DKIM passes and aligns across observed mail flows. They help identify services that were missed or configured differently from the test path.

DKIM key rotation

Rotation procedures differ by provider. A safe pattern is:

1. generate or activate a new selector;
2. publish its DNS record;
3. confirm authoritative DNS serves it;
4. send test messages and verify the new selector;
5. confirm expected production signing has moved; and
6. retire the old selector according to the provider’s documented process.

Do not delete the old public key before messages signed with it have cleared normal delivery and retry paths. Do not prescribe a universal waiting period: DNS TTLs, provider behaviour, and mail flow differ.

Common configuration mistakes

• Correct record, signing disabled: DNS exists, but the provider is not signing outbound mail.
• Wrong selector name: the record is published under a guessed or old selector.
• Zone name duplicated: a DNS interface appends the domain to a fully qualified name.
• Wrong customer target: a CNAME from another tenant or domain is reused.
• Valid DKIM without DMARC alignment: the message is signed, but the d= domain does not align with the From domain.
• Assuming discovery is complete: a checker finds no common selector, but an untested provider-specific selector is active.
• Removing an old selector too early: in-flight or retried messages can no longer be verified.
• Treating DKIM as content trust: a valid signature does not make a malicious or compromised message safe.

What DKIM does not do

DKIM does not replace SPF or DMARC. It does not evaluate message intent, scan attachments, stop lookalike domains, secure a compromised mailbox, or guarantee inbox placement. Forwarders or mailing lists can also modify signed content and invalidate a signature.

DMARC combines DKIM and SPF results with alignment to the visible From domain. Read What is DMARC? for that relationship and SPF Records Explained for the other authentication path.

Frequently asked questions

Do I need both DKIM and SPF?

DMARC needs at least one aligned pass. Configuring both where the providers support them gives legitimate mail more than one possible authentication path, but each service still needs to be tested.

Can an MSP host a customer’s DKIM private key?

That is not Vigil’s default scope. Vigil supports DKIM discovery, evidence review, validation, monitoring, and guidance. In normal provider-managed configurations, the sending provider controls the private key.

Why use more than one selector?

Different providers need separate keys, and rotation often requires an old and new selector to coexist temporarily.

How do I know that DKIM is really working?

Confirm authoritative DNS, send through the actual service, inspect the authentication results and signing domain, and then review aggregate-report evidence across normal mail flows.

For the broader operating process, read the MSP service-delivery guide. Use the free checker for a point-in-time view of supported public selectors, then confirm each sending provider directly.