What is the difference between DKIM alignment and DKIM authentication and how do they relate to email bouncebacks and Hotmail blocks when using SFMC shared IPs?
Michael Ko
Co-founder & CEO, Suped
Published 10 May 2025
Updated 25 May 2026
11 min read
Summarize with
DKIM authentication and DKIM alignment are related, but they answer different questions. DKIM authentication asks, "Did the cryptographic signature validate?" DKIM alignment asks, "Does the domain that signed the message match the visible From domain closely enough for DMARC?" A message can be DKIM aligned but not DKIM authenticated, DKIM authenticated but not aligned, both, or neither.
For an SFMC sender using a delegated SAP domain, the practical test is the d= domain and s= selector in the DKIM-Signature header. If the public key exists, the signature validates, and the d= domain aligns with the visible From domain, DKIM is doing what DMARC needs. If Hotmail still blocks the mail, that usually points to reputation, shared IP pool quality, HELO/EHLO policy, or Microsoft filtering, not a DKIM alignment problem.
Authentication: The receiving server verifies the DKIM signature against the public key in DNS.
Alignment: The DKIM signing domain aligns with the visible From domain used by the recipient.
Hotmail blocks: A blocklist or blacklist-style rejection can happen even when DKIM and DMARC pass.
SFMC shared IPs: Your mail can inherit pool reputation, so authentication is only one part of the diagnosis.
The direct difference
DKIM authentication is a pass or fail result for a specific signature. The recipient takes the DKIM-Signature header, reads the selector and signing domain, looks up the public key in DNS, and checks whether the message still matches the signed headers and body. If the signature verifies, DKIM authentication passes.
DKIM alignment is a DMARC concept. DMARC does not only care that any domain signed the email. It checks whether the signing domain is the same as, or organizationally related to, the domain in the visible From address. That visible From address is the domain the recipient sees in the email client.
DKIM authentication
Question: Did this DKIM signature validate?
Checked value: The cryptographic signature, public key, signed headers, and body hash.
Common failure: Missing key, broken key, changed body, changed signed header, or invalid signature.
DKIM alignment
Question: Does the signing domain match the visible From domain?
Checked value: The DKIM d= domain against the header From domain.
Common failure: A vendor signs with its own domain instead of your domain.
The most confusing case is this: the d= domain can match your From domain, but the DKIM signature can still fail validation. Alignment does not prove the signature was mathematically valid. It only proves the domain relationship was acceptable if the signature passes.
DMARC passes when SPF or DKIM passes and aligns. That "and aligns" part matters. A vendor can produce a valid DKIM signature using a vendor domain, but DMARC will not count that signature for your brand unless the signing domain aligns with the visible From domain.
For a custom SFMC SAP setup, I expect DKIM to sign with a domain under the sender's delegated sending domain, such as a subdomain of the brand domain. If the visible From address is news@example.com and the DKIM signature uses d=email.example.com, relaxed DKIM alignment usually passes because both share the same organizational domain. Strict DKIM alignment would require an exact domain match.
DKIM result
Alignment
DMARC impact
What it means
Pass
Pass
Counts
DKIM can satisfy DMARC.
Pass
Fail
Ignored
Signature is valid, but not for your From domain.
Fail
Pass
Ignored
Domain matches, but the signature broke.
Fail
Fail
Ignored
DKIM gives DMARC no help.
Compact examples of DKIM authentication and alignment outcomes.
If you want the deeper reason behind the From-domain requirement, this related page on DKIM alignment explains why DMARC ties the signature to the domain users can see.
A four-part infographic showing Visible From, DKIM d=, Signature pass, and DMARC result.
Why SFMC can look wrong when it is right
With SFMC SAP, a delegated subdomain can move key DNS management to SFMC. The root DNS zone usually delegates a sending subdomain to ExactTarget nameservers using NS records. That lets SFMC publish the DKIM selector records, bounce domain records, and related entries under the delegated zone.
Typical SFMC delegated subdomain patterndns
email IN NS ns1.exacttarget.com.
email IN NS ns2.exacttarget.com.
email IN NS ns3.exacttarget.com.
email IN NS ns4.exacttarget.com.
Salesforce Marketing Cloud Email Studio bounce details screen with SMTP codes and bounce categories.
That delegation pattern does not itself prove DKIM is valid. The receiving server still needs the DKIM selector record that matches the message. The useful header values are s= and d=. Together, they form the DNS lookup name: selector, then _domainkey, then the signing domain.
DKIM key lookup patterntext
s=sfmc1
d=email.example.com
DNS TXT lookup:
sfmc1._domainkey.email.example.com
Do not stop at one checker
Some one-off checkers report DKIM failures when the actual message is fine, especially if the test method does not preserve the exact message received by the mailbox. I treat the delivered message headers and real recipient authentication results as the source of truth.
The body hash can fail if something changes the message after signing. Link wrapping, footer injection, encoding changes, tracking rewrites, security gateways, and template output changes can all break DKIM if they modify signed content. A transient failure means the setup can be correct, but one message path or one message version changed enough to break the signature.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
For DNS-level validation, a focused DKIM checker is useful for confirming the selector record, key syntax, and lookup path. It does not replace a real delivered-message test because it cannot prove that a specific email body arrived unchanged.
How bouncebacks fit in
The phrase "delivery not authorized" causes a lot of confusion. It often means "not allowed" or "not permitted" by the receiving system. It does not automatically mean "not authenticated." The bounce text matters more than the category label inside an email platform.
For example, a bounce saying Helo command rejected: Access denied is about the SMTP HELO/EHLO conversation or a policy tied to that sending host. It does not say DKIM failed. It can happen because the receiving system blocks the platform's HELO string, dislikes the sending host, or applies a local access rule.
Bounce clue
Likely area
Next check
DKIM fail
Authentication
Message headers
DMARC reject
Policy
SPF or DKIM
HELO rejected
SMTP access
Host policy
S3140
Microsoft block
IP reputation
Bounce text clues that help separate authentication from blocking.
Read the bounce before the category
An ESP category called "Authentication" can be a broad bucket. I would not treat that label as proof of a DKIM, SPF, or DMARC failure unless the bounce text or headers say so directly.
When the bounce says an IP is on a Microsoft block list, that is a reputation and policy issue. In ordinary language, it is a blocklist or blacklist problem. DKIM can be perfect and the message can still bounce because Microsoft does not want traffic from that IP, pool, sender pattern, or current complaint profile.
If the bounce text names a specific IP, capture that IP, the SMTP code, the timestamp, the recipient domain, and the campaign. Those details let you separate one mailbox provider issue from a global authentication issue.
Why Hotmail blocks SFMC shared IP mail
Hotmail, Outlook.com, and Microsoft consumer mail filtering are sensitive to sender reputation. With SFMC shared IPs, your mail is not judged only by your domain. The shared IP pool also matters. If other senders in that pool have poor list hygiene, high complaint rates, spamtrap hits, or sudden volume spikes, your mail can be affected.
That is why a new sender can launch yesterday, pass DKIM, pass DMARC, and still see Hotmail blocks today. Microsoft does not need to claim your DKIM is broken to reject the connection. It can reject because the IP reputation is weak, the pool has bad history, your sending pattern is too new, or the recipient-side signals are poor.
What contributes to a shared IP block
A simple way to think about Hotmail blocking when authentication already passes.
Your domain
IP pool
Message signals
The hard part is accountability. The shared IP provider controls the pool, but the mailbox provider often evaluates your traffic and the IP together. In practice, you still need to gather your own evidence: exact bounce text, headers, message samples, complaint patterns, and Microsoft-specific rejection codes.
A six-step flowchart for diagnosing Hotmail blocks on SFMC shared IP mail.
If you are seeing intermittent authentication noise as well, this page on Microsoft sender requirements gives more context on enforcement-style bounces and how they can be misread.
The checks I would run
I would work through this in a fixed order. The goal is to prove whether authentication is actually failing before spending time on reputation and blocklist (blacklist) remediation.
Capture headers: Send a real SFMC message to a mailbox you control, then copy the full headers from the delivered message.
Find DKIM values: Read the DKIM-Signature header and record the s= selector and d= domain.
Verify authentication: Confirm the recipient's Authentication-Results header says DKIM passed for that signature.
Verify alignment: Compare the DKIM d= domain with the visible From domain under your DMARC alignment mode.
Read bounces: Use the exact SMTP code and text, not only the SFMC bounce category.
Separate Microsoft: Treat Hotmail and Outlook.com blocks as mailbox-provider reputation issues once authentication passes.
Domain health checker sample results showing DMARC, SPF, DKIM scorecards and detailed validation checks
For a broader pass over the domain, use a domain health check to catch obvious SPF, DKIM, and DMARC DNS problems before you inspect message-specific headers.
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Suped is useful here because the workflow should not end at a green or red DNS result. Suped's product ties DMARC monitoring, SPF and DKIM diagnostics, blocklist monitoring, and issue steps together, so you can see whether a source is genuinely failing authentication or whether you are dealing with Microsoft-specific blocking on a shared pool.
If DMARC aggregate reports show SFMC passing DKIM and DMARC for most mail, but Hotmail continues to reject a subset with IP block text, I would stop treating it as a DNS setup issue. At that point the work becomes list quality, volume ramping, complaint reduction, pool escalation, and sender reputation evidence.
What to send to SFMC or Microsoft
When you open a support case, keep it factual. The strongest cases include enough detail for the provider to reproduce the decision path without guessing. A vague "we are blocked" case gets slower handling than a case with exact SMTP responses and timestamps.
Evidence packet
Bounce text: Include the full SMTP code, enhanced status code, and rejection phrase.
Sending IP: Include each IP seen in the affected bounces and the relevant send times.
Headers: Attach full headers for delivered samples from the same campaign and send source.
Authentication: Show DKIM, SPF, and DMARC results from real recipient headers.
For SFMC, ask whether the affected sends used shared or dedicated IPs, whether the IPs have active Microsoft mitigation, whether the HELO/EHLO string is expected, and whether other customers on the same pool have Microsoft deferrals or blocks. For Microsoft-facing remediation, focus on your sender behavior and the IPs in the rejection text.
If you find that SPF passes but DMARC still fails because the return-path domain does not match, that is a separate issue. This related SFMC page on SPF failure covers that path.
Ongoing DMARC monitoring turns this into a trend instead of a single-message argument. That matters because support teams respond better when you can show a pattern by source, result, and receiving domain.
Views from the trenches
Best practices
Check real headers first, then use DNS tools to confirm the selector and signing domain.
Store exact bounce text, sending IPs, timestamps, and recipient domains for every block.
Separate authentication defects from reputation blocks before changing DNS or templates.
Common pitfalls
Do not assume an ESP category proves DKIM failed when the bounce says access denied.
Do not judge SFMC SAP only by delegation records; inspect the real DKIM signature.
Do not treat a shared IP blocklist or blacklist issue as a DMARC policy failure.
Expert tips
Use delivered-message Authentication-Results as the main proof for DKIM and DMARC.
Escalate Hotmail blocks with evidence about the exact IP, code, and sender pattern.
Keep campaign HTML under clipping thresholds when diagnosing unrelated delivery noise.
Expert from Email Geeks says DKIM authenticated means the DKIM signature passed, while DKIM aligned means the signing domain matches the visible From domain closely enough for DMARC.
2024-01-11 - Email Geeks
Expert from Email Geeks says the selector and signing domain from the DKIM-Signature header are enough to look up the public key and test whether the DNS side is correct.
2024-01-11 - Email Geeks
What I would conclude
DKIM alignment and DKIM authentication are not interchangeable. Authentication proves the DKIM signature validated. Alignment proves the signing domain is close enough to the visible From domain for DMARC. DMARC needs a passing and aligned SPF or DKIM result.
For SFMC shared IP Hotmail blocks, do not assume the word "authorized" means authentication failed. A 5.7.1 access denial, HELO rejection, or Microsoft S3140-style block usually points to policy or reputation once the headers show DKIM and DMARC passing. Prove authentication first, then work the block as a Microsoft and shared IP reputation problem.
Suped is the best overall practical fit for most teams here because the product keeps authentication evidence, source breakdown, blocklist monitoring, and fix steps in one place. That makes the difference between "SFMC says authentication" and "the header proves DKIM passed, but Microsoft blocked this IP" much easier to show.
Frequently asked questions
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
What is the difference between DKIM alignment and DKIM authentication and how do they relate to email bouncebacks and Hotmail blocks when using SFMC shared IPs? - Suped
