Why are Microsoft Outlook 550 5.7.515 access denied errors occurring due to DKIM failures, and how do message encoding and modification affect them?
Updated on 18 Oct 2026: We corrected the header encoding example and added SMTP transport checks for Outlook 550 5.7.515 DKIM failures.
Microsoft consumer email services return 550 5.7.515 when the domain in the visible 5322.From address does not meet Microsoft's required authentication level. For a domain subject to the high-volume sender rules, SPF and DKIM must both pass, and DMARC must pass through SPF or DKIM with the required domain match. An SPF pass that also makes DMARC pass does not cancel a separate DKIM failure.
The failure often looks message-specific because DKIM protects canonicalized versions of the signed headers and body bytes. Changes to a signed Subject, From display name, Date header, MIME structure, transfer encoding, or body part after signing can make Microsoft's verifier calculate a different hash. Microsoft's 550 5.7.515 guidance explains the authentication requirements. The remaining task is proving whether the failed check comes from DNS, domain alignment, message formation, or a post-signing change.
- Modification check: Determine whether the message Microsoft validates has the same protected content as the message that received the DKIM signature.
- Encoding check: Look for malformed encoded-words, raw non-ASCII on a non-SMTPUTF8 header path, or a MIME change after signing.
- Key symptom: The same sender and From domain deliver some messages while other variants receive an NDR.
- First split: Separate domain setup failures from message-content failures before changing DNS.
Why Outlook rejects mail with 550 5.7.515
A 550 5.7.515 response is an authentication enforcement bounce. Outlook.com and related Microsoft consumer services evaluate the visible From domain, the SPF result, the DKIM result, and whether DMARC passes using a matching domain. For high-volume senders, Microsoft requires valid SPF, DKIM, and DMARC, with both SPF and DKIM checks passing.
Example 550 5.7.515 NDR with authentication resultstext
550 5.7.515 Access denied, sending domain example.com does not meet the required authentication level. Example authentication results reported with the rejection: Spf=Pass, Dkim=Fail, DMARC=Pass
The authentication results are the clue. DMARC can pass through SPF domain alignment while DKIM fails. That does not make the DKIM failure harmless because Microsoft's high-volume sender requirements call for DKIM to pass independently. The results are not contradictory. They report separate checks with different pass conditions.
Read the authentication result literally
- DKIM=Fail: Start with the selector, signing domain, signed headers, body hash, and message transformations.
- SPF=Fail: Check the 5321.MailFrom domain, authorized IPs, forwarding, and SPF lookup limits.
- DMARC=Fail: Confirm whether SPF or DKIM passed with a domain that meets the DMARC matching rules for 5322.From.
- Mixed result: Do not assume one pass result satisfies every Microsoft authentication requirement.
SPF, DKIM, and DMARC checks in Microsoft's Outlook.com 550 5.7.515 authentication decision path.
Who the Microsoft rule applies to
Microsoft's enforcement targets high-volume senders to Outlook.com and related consumer mailbox domains, including Hotmail, Live.com, and MSN. Microsoft's support page defines the threshold as 5,000 or more messages using the same 5322.From domain, while its high-volume sender announcement describes that volume on a per-day basis. Treat 5,000 messages per day to these consumer services as the operational trigger. Once a domain reaches the threshold, Microsoft expects all messages using that From domain to meet the requirements. This consumer-mailbox rule does not describe every rejection at a Microsoft 365 business mailbox.
- SPF: The connecting source must be authorized for the 5321.MailFrom, or return-path, domain and the SPF check must pass.
- DKIM: The message must carry a verifiable signature and the DKIM check must pass.
- DMARC: The 5322.From domain must publish a valid DMARC policy, p=none, p=quarantine, or p=reject, and DMARC must pass.
- Alignment: At least one passing identity, SPF's 5321.MailFrom or DKIM's d= domain, must satisfy the DMARC matching rules for the 5322.From domain.
For a third-party sender, verify the visible 5322.From domain, the return-path domain, the DKIM d= domain, and the actual sending IP. SPF and DKIM still need to pass separately, but DMARC requires only one of those passing identities to match 5322.From under the published alignment mode. Relaxed alignment requires the same organizational domain; strict alignment requires an exact domain match. Check aspf for SPF and adkim for DKIM. Configuring both paths for domain matching provides redundancy, but forwarding can still break SPF and body edits can still break DKIM.
How header encoding breaks DKIM
DKIM does not sign the idea of a subject line or display name. It signs canonicalized bytes. The signer builds a hash over selected headers and the canonicalized body, writes the body hash and signature into the DKIM-Signature header, and the receiver repeats the calculation. If the inputs differ beyond the selected canonicalization rules, validation fails.
Accents and emojis do not inherently break DKIM. Unless the complete delivery path supports SMTPUTF8, non-ASCII text in classic fields such as Subject and a display name normally needs RFC 2047 encoded-word syntax. If a system signs a header containing raw or malformed non-ASCII text, a later component can re-encode that header into a valid form. The displayed text can stay the same while the signed byte sequence changes. Use encoded-words only where the header syntax permits them, such as Subject text and display names, not inside email addresses or List-Unsubscribe URLs.
Valid before signing
- Header bytes: Display names and subjects are encoded before DKIM signing.
- Final content: Tracking, personalization, and unsubscribe headers are added before signing.
- Canonicalization: Relaxed header and body canonicalization absorbs specified whitespace differences.
Fragile after signing
- Bad encoding: Raw non-ASCII on a non-SMTPUTF8 path or broken encoded-words appear in signed headers.
- Late edits: Footers, URLs, or MIME boundaries change after the DKIM signature is added.
- Transit rewrite: A gateway or relay re-encodes a signed header or body part before Microsoft validates it.
Header encoding exampletext
Raw UTF-8, valid only on an SMTPUTF8 path: Subject: Offre spéciale été RFC 2047 encoding for a non-SMTPUTF8 path: Subject: =?UTF-8?Q?Offre_sp=C3=A9ciale_=C3=A9t=C3=A9?=
Both versions display "Offre spéciale été". The RFC 2047 version provides an explicit ASCII byte sequence for a non-SMTPUTF8 path. Generate the chosen version before signing and preserve it during delivery. Relaxed canonicalization can tolerate specified folding and whitespace changes, but it does not treat different encodings of the same displayed text as equivalent.
Check SMTP transport encoding and dot-stuffing
SMTPUTF8 permits internationalized headers and addresses; 8BITMIME permits 8-bit message bodies. An 8bit body does not inherently fail DKIM. If the delivery path requires 7-bit MIME, convert the relevant body parts to quoted-printable or base64 before signing. A later conversion changes the signed bytes even when the displayed text stays the same.
RFC 6376, section 3.7, requires DKIM to hash the encoded MIME body before decoding quoted-printable or base64, and before SMTP dot-stuffing. Finalize CRLF line endings and MIME wrapping before signing. Adding a quoted-printable soft line break afterward changes the hashed body.
SMTP DATA dot-stuffing preserves the original body linetext
Body line before DKIM signing: .example Same line on the SMTP DATA wire: ..example Body line after SMTP unstuffing, before DKIM verification: .example
Under RFC 5321, section 4.5.2, SMTP DATA escapes a leading period and the receiving server removes that escape before DKIM verification. Incorrect or repeated unstuffing changes the body. A Microsoft community report describes a missing period, but does not establish which component caused it. Inspect physical encoded lines, including quoted-printable wrapping, before attributing a body hash mismatch to Microsoft. Correct dot-stuffing preserves DKIM.
Message changes after signing
Encoding is only one way DKIM breaks. A DKIM failure can come from a change to any header selected by h= or to the signed portion of the body. When 550 5.7.515 failures appear suddenly and affect only some message variants, inspect every component that can modify the message after the DKIM signature is attached.
|
|
|
|---|---|---|
Subject rewrite | Header signature mismatch if Subject is signed | Finish Subject encoding before signing |
Footer added | Body hash mismatch | Insert the footer before signing |
URL wrapping | Body hash mismatch | Finish link tracking before signing |
Signed Date rewrite | Header signature mismatch | Set Date before signing |
MIME change | Body hash or header signature mismatch | Finalize MIME serialization before signing |
Transfer-encoding conversion | Body hash mismatch | Choose the final encoding before signing |
Common changes that can break DKIM validation
A small post-signing change can be enough. Re-encoding a body part, changing a MIME boundary, rewriting a signed Subject, or adding a footer changes protected input. Relaxed canonicalization tolerates defined whitespace normalization and empty lines at the end of the body. It does not tolerate semantic header rewrites or added body content.
The pass elsewhere trap
A message can pass DKIM at one mailbox provider and fail at Microsoft because delivery paths can use different relays, gateways, and content-processing steps. A pass elsewhere proves that the key and signature worked on that copy. It does not prove that Microsoft received the same protected content.
How to diagnose 550 5.7.515
Start by proving whether the failure follows the From domain, the sending source, or the message variant. If every message from one domain or selector fails, check DNS and sender configuration first. If only certain subjects, locales, templates, or recipient paths fail, inspect the signed message and post-signing processing. Use Microsoft's receiver-generated Authentication-Results when available; an earlier sending gateway's pass result describes a different validation point. A rejected message does not provide delivered headers, so preserve the full NDR and outgoing source.
- Capture the signed source: Save the exact raw RFC 5322 message immediately after DKIM signing and the final outbound copy after relay processing, preserving CRLF line endings and original MIME encoding.
- Preserve the NDR: Keep the full 550 5.7.515 diagnostic, timestamp, recipient domain, and reported SPF, DKIM, and DMARC results.
- Compare identities: Record smtp.mailfrom, header.from, header.d, the selector, and which identifier supplied DMARC alignment.
- Check signed headers: Record c= and h=, then compare the signed fields and canonicalized body across the saved copies. A delivered control helps identify patterns but is a separate message.
- Verify the selector: Resolve selector._domainkey.signing-domain using s= and d=, following any CNAME, and confirm the public key matches the signing service's private key.
- Retest content: Send controlled variants that change only the Subject, From display name, locale, or MIME construction.
- Move signing last: Apply DKIM after personalization, tracking, MIME generation, unsubscribe headers, and footer insertion.
- Compare outcomes: Match accepted and rejected messages by source, selector, From domain, template, and Microsoft recipient domain.
For the DNS side, use Suped's DKIM checker and run a broader domain health check to catch SPF, DKIM, and DMARC record problems before chasing message encoding. These checks inspect DNS configuration; they do not verify the signature on the rejected message.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
After DNS checks out, reproduce the failure with the smallest possible change. Send one message with the original non-ASCII subject and one with a plain ASCII subject. Repeat the test for the From display name and other fields named in h=. Validate List-Unsubscribe URL syntax separately rather than applying encoded-words to it. Keep the sender, selector, recipient domain, and body constant.
If the diagnostic says the DKIM body hash did not verify, recompute bh= from the raw MIME body using the body mode in c=; do not hash a decoded HTML preview. If c= is absent, its default is simple/simple. Respect l= if a signed body-length limit is present. If that hash differs, investigate body changes or signing/canonicalization defects. If the body hash matches but the overall signature fails, focus on the h= headers, the d= and s= identity, the DNS key, and the b= signature. Inspect each DKIM-Signature separately; one failed signature does not invalidate another passing signature. The same body-failure pattern appears in body hash failures, where link tracking, MIME rewrapping, footers, or transfer-encoding changes occur after signing.
Fixes that stop repeat bounces
The practical fix is to make the message valid and final before it is signed, then prevent later systems from changing protected content. Do not loosen DMARC or rotate DKIM keys unless the evidence points to a policy, DNS, or key problem.
- Encode headers: Encode non-ASCII display names and subjects correctly before DKIM signing unless the complete path uses SMTPUTF8.
- Sign last: Put DKIM signing after template rendering, tracking, MIME creation, and footer logic.
- Use relaxed: Use relaxed header and body canonicalization unless a tested requirement calls for another mode.
- Set core headers: Generate Date, Message-ID, MIME-Version, and Content-Type before signing.
- Limit mutations: Stop relays, security gateways, and sending systems from editing signed content after DKIM.
- Monitor changes: Watch DKIM failure rates by source, selector, receiver, and message stream.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped's DMARC reporting product groups aggregate results by sending source and authentication outcome, then surfaces issues and alerts. For 550 5.7.515, use Suped to identify sources with Microsoft-reported DKIM failures where reports are available. Correlate selectors with raw messages when the report does not include them. Then use the raw-message tests above to locate an encoding or post-signing fault, because aggregate reports do not contain a message's Subject or body.
Suped's DMARC monitoring also helps compare Microsoft-reported DKIM failures with failures at other reporting receivers. That split tells the team whether to inspect a Microsoft-specific route or the sender's general signing configuration first. Reports are delayed and receiver coverage is incomplete, so use NDRs and sending logs to confirm individual rejections.
Other authentication faults behind 550 5.7.515
Do not attribute every 550 5.7.515 NDR to accents or emojis. Encoding is one failure pattern, but the same response can accompany other authentication faults. A selector typo, missing public key, stale DNS answer, SPF failure, a domain mismatch, or incorrect third-party sender configuration requires a different fix. Check the complete enhanced status code: 550 5.1.8 "bad outbound sender" concerns an Exchange Online sender restriction and needs a different investigation.
Message-specific failure
- Pattern: Only certain subjects, locales, templates, or MIME versions fail.
- Evidence: The same sender and source deliver other messages to Microsoft consumer mailboxes.
- Action: Inspect encoding, h= headers, the body hash, and post-signing edits.
Domain setup failure
- Pattern: All or most mail from one From domain, selector, or sending platform fails.
- Evidence: Failures appear across many campaigns, locales, and Microsoft recipients.
- Action: Check selector DNS, SPF authorization, 5321.MailFrom, DKIM d=, and 5322.From alignment.
Microsoft 365 senders have recurring DKIM configuration patterns when CNAME records, key rotation, or third-party senders are mixed. If Microsoft 365 is the failing source, check the setup path for Office 365 DKIM failures before changing campaign templates.
Confirm the fix before resending
If the NDR shows DKIM=Fail, start with the exact message that failed. Validate the selector and public key, then check whether the signed headers contain malformed encoded-words, an unstable Date field, or another field that a later system changes. Compare the 5321.MailFrom, DKIM d=, and 5322.From domains at the same time so a content test does not hide an alignment fault.
After correcting the fault, retest the affected message variants through the same sending route to Microsoft consumer mailboxes. Confirm Microsoft reports SPF=Pass, DKIM=Pass, and DMARC=Pass on accepted control messages. A 550 response is a permanent rejection for that attempt; resending the unchanged message does not repair authentication. Resume the affected stream after the corrected messages pass, and continue monitoring NDRs and authentication results. Authentication success does not guarantee inbox placement.
Frequently asked questions
Yes. DMARC can pass through SPF alignment while DKIM fails. For a high-volume sender, Microsoft requires SPF and DKIM to pass independently, so DMARC=Pass does not override DKIM=Fail.
No. Correctly encoded non-ASCII content works with DKIM. Failure occurs when a field is malformed, signed before final encoding, or rewritten later by a sending system, gateway, or relay.
Usually no. A DMARC policy change does not repair a broken DKIM signature. Fix the signing order, header encoding, selector DNS, key match, or post-signing modification first.
That pattern points to a difference in content or routing, such as Subject encoding, display-name encoding, MIME construction, tracking changes, or a template path that signs too early.
Send the raw message captured immediately after signing, the final outbound copy, the full NDR, the DKIM-Signature field, the selector DNS answer, the sending timestamp, and one accepted control using the same From domain. Preserve original MIME bytes rather than exporting a rendered preview.
It covers domains sending 5,000 or more messages per day using the same 5322.From domain to Microsoft consumer email services such as Outlook.com, Hotmail, Live.com, and MSN. Once the threshold is reached, all messages using that From domain are expected to meet the authentication requirements, including messages sent by individual users.
