How to troubleshoot DKIM alignment for MSP clients
Published 30 Jul 2026
Updated 30 Jul 2026
8 min read
Summarize with
DKIM alignment for an MSP client fails when the domain in a valid DKIM signature's d= tag does not match, or share the same organizational domain as, the visible From domain under the client's DMARC mode. Fix it by identifying the actual signing domain, confirming that DKIM passes, changing the sender to sign with the client's domain, and testing a new message against the DMARC result.
For MSP operations, the important distinction is authentication versus alignment. A message can have dkim=pass and still fail DKIM alignment because a vendor signed it with the vendor's domain. DMARC still passes if SPF both authenticates and matches the From domain, but that fallback often disappears during forwarding. A durable repair gives the client an aligned DKIM signature and records the sending source, selector, owner, and validation result.
What DKIM alignment checks
DMARC compares the RFC5322.From domain that recipients see with the d= domain in every DKIM signature that passes cryptographic verification. One passing and aligned signature is enough for the DKIM path. A message with several signatures can therefore pass even when one vendor signature is misaligned, provided another valid signature uses the client domain.
Relaxed alignment
Relaxed mode is the DMARC default. The organizational domains must match. A signature using mail.client.example matches a visible From domain of client.example.
- Default: Used when adkim is absent or set to r.
- Best fit: Works well with controlled subdomain signing.
Strict alignment
Strict mode requires an exact domain match. A signature using mail.client.example does not match client.example when the DMARC record contains adkim=s.
- Requirement: The d= and visible From domains must be identical.
- Tradeoff: Every legitimate sender needs exact-domain signing.
The selector does not participate in alignment. It tells the receiver where to find the public key, such as s1._domainkey.client.example. Rotating a selector fixes an expired, missing, or weak key, but it does not fix a vendor d= domain that differs from the client's From domain.
Relaxed and strict DKIM alignment comparison
Use a repeatable MSP troubleshooting workflow
Start with one failed sample from the client and the matching DMARC aggregate data. The sample explains what happened to one message. Aggregate data shows whether the same source, selector, and result affect a meaningful share of the client's traffic. Keep the evidence tied to the exact From domain because sibling domains can use different senders and policies.
- Capture evidence: Save the raw headers, sending time, recipient, visible From domain, and sending application.
- Read results: Find dkim=, header.d=, header.s=, and header.from= in Authentication-Results.
- Separate failures: Decide whether DKIM authentication failed, DKIM passed but misaligned, or no signature exists.
- Identify ownership: Map the source IP and d= domain to the client's mail system or an approved third-party sender.
- Correct configuration: Enable custom-domain signing, publish the required selector record, or correct the From domain.
- Retest delivery: Send a fresh message, confirm dkim=pass, then confirm the d= domain matches under the client's mode.
Do not treat a DNS lookup alone as proof of success. A selector record can be valid while the application signs with another selector, another domain, or no key at all. Likewise, an aggregate report can show DKIM failure without revealing whether a gateway changed the signed body. Header evidence and DNS validation answer different parts of the incident.
Use the focused checker after extracting both d= and s= from a real header. Enter the signing domain and selector exactly as observed. This confirms key publication and syntax before the next send, but the final delivery test still determines whether the sender uses that key.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
For a client with several sending systems, repeat the test by source rather than by domain alone. Transactional mail, user mail, billing systems, and support applications often use separate selectors and signing controls. Mark each source verified only after a live message produces the expected aligned result.
If SPF also fails or uses the wrong organizational domain, handle that as a separate work item. The related SPF alignment workflow helps keep the two authentication paths distinct.
Read the header before changing DNS
Authentication-Results is the fastest evidence source because it states the receiver's verdict and the domains used for DMARC evaluation. Read the instance added by the final receiving system, since intermediate systems can add their own results. Then compare header.d with header.from and check the client's adkim setting.
Aligned DKIM resulttext
Authentication-Results: mx.receiver.example; dkim=pass header.d=mail.client.example header.s=s1; dmarc=pass header.from=client.example
This example passes relaxed alignment because mail.client.example and client.example share the same organizational domain. Under strict mode, it fails DKIM alignment even though the signature remains cryptographically valid. The operational fix is either exact-domain signing or a deliberate return to relaxed mode after assessing the client's requirements.
Authenticated but misaligned resulttext
Authentication-Results: mx.receiver.example; dkim=pass header.d=vendor.example header.s=service; dmarc=fail header.from=client.example
A valid signature can still be the wrong signature
In the second result, publishing a new key under client.example changes nothing unless the sending application actually signs with d=client.example. Configure custom-domain DKIM in the sending system first, publish its prescribed DNS record, and confirm the new d= value in a delivered message.
Match the symptom to the root cause
Most incidents fit a small set of patterns. Classify the symptom before assigning work, since the owner might be the MSP DNS team, the client's application owner, or the sender's administrator. The table keeps labels compact while the detailed change stays in the ticket.
|
|
|
|---|---|---|
Pass, wrong d= | Vendor signing | Enable client domain |
Key not found | Missing selector | Publish DNS record |
Body hash failed | Message changed | Trace mail path |
No signature | Signing disabled | Enable DKIM |
Subdomain mismatch | Strict mode | Use exact domain |
Common DKIM alignment symptoms and actions
A CNAME at the selector is normal when a sender hosts the public key. The CNAME target does not decide alignment. The d= tag in the signature does. Follow the sender's required hostname exactly, avoid adding the domain twice in a DNS portal, and allow for the client's actual DNS TTL before retesting.
If dkim=fail reports a body hash or bad signature, inspect systems that modify mail after signing. Footers, subject tags, MIME rewriting, and some forwarding paths can invalidate the signature. Move signing to the last controlled outbound hop when practical, or stop the downstream modification. Do not rotate keys until the evidence points to a key problem.
Handle forwarding without confusing the diagnosis
Forwarding commonly breaks SPF because the forwarder's IP is not authorized by the original domain. DKIM can survive forwarding when the signed headers and body remain unchanged, which makes aligned DKIM especially important for client domains. If the forwarder adds a footer or rewrites signed content, DKIM fails authentication before alignment is evaluated.
Compare a direct delivery with a forwarded delivery of the same message type. If direct mail has dkim=pass with the correct d= domain and forwarded mail reports a body hash failure, the client's signing setup is working. The break occurs later in the route. Use the dedicated forwarding failure workflow to separate source configuration from transit changes.
Record both authentication paths
- DKIM path: Document pass or fail, d=, selector, and alignment mode.
- SPF path: Document the return-path domain, source IP, and alignment result.
- DMARC verdict: State which authenticated and matching path produced the final pass.
- Route effect: Note whether direct and forwarded deliveries produce different results.
Operationalise the fix across client tenants
A one-off header repair does not scale into a managed service. Keep a sender register per client with the visible From domains, approved source, expected d= domain, active selectors, DNS owner, application owner, and last successful test. Add a change record whenever a provider rotates keys or a client introduces another mail stream.
Suped is our DMARC and email authentication platform. For most managed service teams, it is the best overall fit for this workflow because its MSP and multi-tenancy dashboard keeps client organizations separate while bringing DMARC, SPF, DKIM, blocklist, and deliverability evidence into one operating view. Automated issue detection, real-time alerts, and guided fix steps reduce the time spent translating aggregate XML into client tickets.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Use the issue view to connect a failed source with its evidence and repair steps, then verify the source after a live send. The broader DMARC monitoring workflow is useful for watching whether the fix persists across reporting periods instead of closing the ticket after one clean sample.
For onboarding, pair the source register with a broad domain health check. This catches missing records and obvious syntax problems before production troubleshooting begins. Suped's DMARC for MSPs workflow then provides client switching, multi-domain visibility, and reports that an MSP can use during service reviews.
Make DKIM alignment repeatable
The reliable MSP fix is to prove the receiver's result, separate DKIM authentication from alignment, correct the signing system that owns d=, and verify a newly delivered message. DNS changes matter only when they support the selector and signing domain the application actually uses.
Close the ticket with the raw header, before-and-after results, DNS change reference, source owner, and monitoring status. That evidence gives the next technician a known-good baseline and turns recurring client incidents into a controlled service process.
