DKIM Failures from External Sender to MS Outlook Hosted Domains

Stefano Teixeira 0 Reputation points
2026-08-07T17:20:10.79+00:00

Hello Microsoft Community

Recently, we started experiencing delivery failures when sending emails from our domain [Moderator note: personal info removed] to Microsoft consumer domains (outlook.com, outlook.com.br, and hotmail.com).

The bounce messages indicate a DKIM authentication error. However, after thoroughly reviewing our email infrastructure, we confirmed the following:

MTA & DNS Setup: Our DKIM records, SPF, and DMARC policies are properly configured, valid, and alignment is intact.

No Issues Elsewhere: All other major email service providers (Gmail, Yahoo, iCloud, enterprise mail servers, etc.) validate our DKIM signature with no issues and deliver our messages normally.

Scope: The issue is isolated strictly to Microsoft-managed inbound domains (outlook.com, outlook.com.br, hotmail.com).

Bounce message example:

[Not delivered - 08/04/2026 09:32:09 (via TLS 1.3)

-host nam.olc.protection.outlook.com[52.101.8.47] said: 550 5.7.515 Access denied, sending domain [Moderator note: personal info removed] doesn't meet the required authentication level. The sender's domain in the 5322.From address doesn't meet the authentication requirements defined for the sender. To learn how to fix this see: https://go.microsoft.com/fwlink/p/?linkid=2319303 Spf= Pass , Dkim= Fail , DMARC= [Moderator note: personal info removed] (in reply to end of DATA command)]

Since our MTA configuration is compliant and functioning across all other external providers, it appears Microsoft's inbound filters might be misinterpreting our DKIM signature or caching outdated key state.

DKIM Results:

DKIM check details:

Result: pass (matches From: [Moderator note: personal info removed])

ID(s) verified: header.d=[Moderator note: personal info removed]

Canonicalized Headers:

date:Tue,'20'23'20'Jun'20'2026'20'14:02:38'20'-0300'0D''0A'

from:"BENCE'20'-'20'GHC"'20'[Moderator note: personal info removed]'0D''0A'

to:[Moderator note: personal info removed]'0D''0A'

dkim-signature:v=1;'20'a=rsa-sha256;'20'c=relaxed/relaxed;'20'd=[Moderator note: personal info removed];'20's=TM-DKIM-2026052616321;'20't=1782234172;'20'bh=Ramv4IizkPA+nV6OqdytE7hEV5ZhQpFbA7u0RBSqfic=;'20'h=Date:From:To;'20'b=

Has anyone encountered a similar issue recently?

Thank you in advance

Outlook | Web | Outlook on the web for business | Email
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Hendrix 965 Reputation points Independent Advisor
    2026-08-07T18:33:00.2+00:00

    Hi Stefano,

    Thank you for your detailed sharing.

    Based on your information, this is correctly a fail DKIM evaluation error. High-volume senders must have SPF and DKIM both pass, must publish DMARC, and must pass DMARC alignment. However, in your NDR, since it said SPF = Pass, DKIM = Fail, DMARC = Pass, which clearly states that your DKIM didn't pass Microsoft's sender requirement.

    As this is a documented issue, please follow the guidance in this article Fix NDR error "550 5.7.515" in Outlook.com | Microsoft Support to reverify and correct the DNS configuration.

    Hope this information would be useful. If you need any further assistance, please feel free to reach out again in the comments of this post. I'm happy to assist you further.

    Thank you for your patience and understanding. Hope to hear from you soon.

    If the answer is helpful, please click "Yes" and kindly upvote it.

    Note: Please follow the steps in the forum documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

    Was this answer helpful?

  2. AI answer

    2026-08-07T17:20:36.9933333+00:00

    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.
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.