DKIM Failures from External Sender to MS Outlook Hosted Domains

The failure pattern points to a Microsoft consumer sender-authentication enforcement issue, not a generic mail flow problem.

Supported facts from the error and the documented checks:

1. 550 5.7.515 is triggered when a domain sending to Microsoft consumer mailboxes is required to meet Microsoft’s authentication requirements.
2. For high-volume senders, Microsoft expects:
   • SPF and DKIM records to be published and to pass.
   • A DMARC record to be published.
   • DMARC validation to pass with at least one aligned result.
3. A message can still be rejected when spf=pass and dmarc=pass if Microsoft sees dkim=fail and the domain is under this enforcement.

Based on the documented troubleshooting paths, the next checks are:

1. Check the full message headers for the failing message.
   • Verify the Authentication-Results values for SPF, DKIM, and DMARC.
   • Verify the 5321.MailFrom domain aligns with the 5322.From domain.
   • If SPF is the mechanism making DMARC pass, confirm that alignment is actually with ghc.com.br and not only with a third-party sender domain.
2. Verify DKIM DNS for the exact selector used in the signature.
   • A documented DKIM failure of no key for signature means the receiver could not find a matching public key in DNS, or the key did not match the signature.
   • Confirm the selector record for TM-DKIM-2026052616321._domainkey.ghc.com.br publishes the correct public key and is reachable publicly.
   • If the key is published, verify DNS reliability and set TTL to at least one hour to reduce timeout-related lookup failures.
3. Check whether the message is being modified after signing.
   • Microsoft documents DKIM failures where the signature is valid originally, but a signed header is changed in transit.
   • In the sample shown, the DKIM h= list includes Date:From:To. If any intermediary changes one of those headers after signing, DKIM fails at the recipient.
   • Review any relay, gateway, mailing service, forwarding service, or security appliance between the signer and final delivery.
4. If a third-party sending service is involved, verify alignment on that service.
   • The service must send using the domain in the 5322.From address.
   • DKIM must sign with ghc.com.br.
   • SPF for ghc.com.br must include the service’s sending sources.
   • DMARC validation must use the organization’s domain, not only the provider’s domain.
5. If a gateway or relay modifies messages, use the documented remediation order:
   • Configure ARC on the gateway.
   • Or configure the gateway to DKIM-sign after modification.
   • Or add the gateway to Enhanced Filtering for Connectors.
6. If both SPF and DKIM are not consistently aligned, fix in this order:
   • SPF source authorization and alignment first.
   • DKIM signing and DNS second.
   • DMARC alignment verification after that.

What the current evidence does and does not support:

• It supports investigating DKIM lookup, DKIM alignment, and post-signing modification.
• It does not support concluding that Microsoft is misinterpreting the signature or caching an outdated key state.

A practical end-to-end validation path is:

1. Capture one failed message header from Outlook.com.
2. Confirm whether the DKIM failure is no key for signature, signature didn't verify, or body hash did not verify.
3. If no key for signature, verify the selector DNS record and DNS TTL.
4. If signature didn't verify, check whether Date, From, or To changed after signing.
5. If a gateway or relay is in path, test a direct send that bypasses it.
6. Confirm the domain used in DKIM d= exactly aligns with the From domain ghc.com.br.
7. Confirm the 5321.MailFrom domain also aligns if SPF is expected to satisfy DMARC.

• Fix NDR error "550 5.7.515" in Outlook.com
• Security Operations guide for email authentication in Microsoft 365
• Troubleshoot email authentication in Microsoft 365
• Set up DKIM to sign mail from your cloud domain