How to Troubleshoot DKIM Alignment Failures
A message can have a valid DKIM signature and still fail DMARC. That is the part that catches most domain owners. To troubleshoot DKIM alignment failures, you need to look beyond whether the signature passed and compare the domain that signed the message with the domain your recipient sees in the From field.
This is not usually a mailbox problem. It is a sending-path problem: a website form, CRM, invoice platform, help desk, forwarding service, or old SMTP relay is signing mail with its own domain instead of yours. The message is authenticated, but not authenticated as your domain.
What DKIM alignment actually checks
DKIM adds a cryptographic signature to an outgoing message. The signature includes a signing domain, shown in message headers as `d=example.com`. Receiving servers use DNS to find that domain's public key and verify that the message was not altered after signing.
DMARC adds another test. It checks whether the DKIM signing domain aligns with the visible From domain. If a customer receives mail from `billing@yourcompany.com`, DMARC wants the valid DKIM signature to come from `yourcompany.com` or, under relaxed alignment, a subdomain such as `mail.yourcompany.com`.
A passing DKIM result is therefore not enough. These two results mean very different things:
- `dkim=pass header.d=vendor-mail.com` means the vendor signed the mail successfully.
- `dkim=pass header.d=yourcompany.com` means the vendor signed the mail successfully using your domain.
Only the second result normally satisfies DKIM alignment for a message whose From address is at `yourcompany.com`.
Start with the message headers, not your DNS dashboard
A DMARC report or receiving-server bounce may say that DKIM alignment failed, but it rarely identifies the system responsible. Find a copy of a failed message and inspect its full headers. Most mail clients offer a menu item called Show Original, View Source, or View Message Headers.
Look for the `Authentication-Results` header first. It may contain something like this:
```text dkim=pass header.d=mailer.vendor-example.net dmarc=fail header.from=yourcompany.com ```
Then find the `DKIM-Signature` header. Its `d=` value is the signing domain, and its `s=` value is the selector. The selector tells you which DKIM record the sender used, but the `d=` value is what matters for alignment.
Also check the visible `From:` header. Do not confuse it with `Return-Path`, `Sender`, or the SMTP envelope sender. SPF evaluates the envelope sender. DKIM alignment evaluates the DKIM `d=` domain. DMARC can pass when either SPF or DKIM passes and aligns, depending on your policy and the message.
If `From:` is `name@yourcompany.com` and DKIM uses `d=yourcompany.com`, the domains align. If DKIM uses `d=notifications.yourcompany.com`, they typically align under relaxed mode. If it uses `d=vendor-example.net`, they do not.
Identify which system sent the failing message
The fastest fix comes from identifying the actual sender before changing records. Review the headers for `Received:` lines, mailer identifiers, tracking domains, and provider-specific headers. Compare the failed message with a message sent directly from your mail host. They may be taking completely different routes.
Common sources include website contact forms, ecommerce receipts, calendar tools, accounting platforms, support desks, job boards, and outbound sales tools. A domain can have perfect MX, SPF, DKIM, and DMARC records while one forgotten application continues sending unauthenticated or misaligned mail.
This also happens after a migration. Your primary mail service may now sign as your domain, while an old relay remains configured in a website or application. A new DNS record does not change how that old sender signs messages.
Fix the sender, not just the DMARC policy
The right fix is usually inside the third-party service. Look for settings named custom sending domain, authenticated domain, domain authentication, branded sending, or DKIM setup. The service should provide one or more DNS records, often CNAME records, that let it publish a DKIM key on your domain.
Add exactly the records it provides. Do not edit the selector, concatenate records from different vendors, or replace an existing DKIM record unless you are certain the selector is no longer used. Multiple DKIM selectors can coexist. That is normal and useful when more than one legitimate service sends mail for your domain.
After DNS propagates, return to the vendor dashboard and complete verification. Many platforms will not begin signing with your domain until they confirm the DNS records. Send a new test message after verification. Old messages will not change, and a previously cached result can be misleading.
If the service cannot sign with your domain, you have three practical choices. Use a From address on a domain it can authenticate, route the mail through a provider that supports aligned signing, or stop using that service for mail that must appear to come from your domain. Relaxing DMARC to accommodate a vendor is possible, but it shifts the cost to your domain's spoofing protection.
Check alignment mode before assuming a subdomain is broken
DMARC has two alignment modes: relaxed and strict. Most domains use relaxed alignment, which allows an organizational domain and its subdomains to align. With relaxed DKIM alignment, `d=mail.yourcompany.com` aligns with a From address at `yourcompany.com`.
Strict alignment requires an exact match. Under strict mode, `mail.yourcompany.com` does not align with `yourcompany.com`. This is useful when you have a specific reason to separate subdomains, but it creates more opportunities for legitimate mail to fail.
Check the `adkim` tag in your DMARC record. `adkim=r` is relaxed and is the default if the tag is absent. `adkim=s` is strict. Do not change it reflexively. Strict alignment can be a deliberate security decision, particularly for a domain with tightly controlled senders. But if your organization uses several legitimate subdomain senders, relaxed alignment is often the more workable policy.
Watch for forwarding and mailing-list changes
Forwarding can complicate authentication. Traditional forwarding often breaks SPF because the forwarder is not authorized by the original sender's SPF record. DKIM is more resilient, but it fails if a forwarding service modifies the signed content, such as adding a footer or rewriting the subject line.
If the original sender's DKIM signature remains valid but belongs to the original sender's domain, it will not align with your From domain anyway. If you operate a mailing list or forwarding workflow that rewrites messages, consider whether it needs authenticated rewriting and ARC support. This is an operational design issue, not a DNS typo.
For ordinary personal forwarding, avoid using your custom domain as the visible From address for mail you did not originate. For organizational systems, test real paths: support ticket replies, calendar invitations, invoices, automated alerts, and messages forwarded to external recipients.
Do not treat SPF as a permanent substitute
A DMARC pass through aligned SPF can mask a DKIM alignment problem. That may be acceptable temporarily, but SPF is more fragile when messages are forwarded or relayed. DKIM is generally the better authentication path for mail you send through external services.
Set up both where possible. SPF should authorize legitimate sending infrastructure, while DKIM should sign with an aligned domain. Keep your SPF record under the DNS lookup limit and avoid adding every vendor you have ever tested. Removing an unused sender is better than carrying it forever in your authorization record.
Test after each change and keep a sender inventory
Make one change at a time, then send a fresh message to a mailbox where you can inspect headers. Confirm three things: DKIM passes, the `header.d` value is aligned with the From domain, and DMARC passes. A vendor dashboard saying “verified” is useful, but the recipient-side result is the final test.
Keep a short inventory of every system allowed to send as your domain, the From addresses it uses, its DKIM selector or setup method, and the owner responsible for it. This takes a few minutes and saves hours when a contractor changes a website plugin or a new billing platform starts sending receipts.
FranklyMail's DNS checks can help confirm that the published records exist, but headers still tell you whether a particular message used them correctly. Mail authentication is not a one-time checkbox. It is a record of who is allowed to speak for your domain, and every sender should be able to prove it.