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 17 Aug 2025
8 min read
Email authentication standards like DKIM are foundational to ensuring your messages reach the inbox. However, it is common for senders to confuse two distinct, yet related, concepts: DKIM authentication and DKIM alignment. While both play a critical role in establishing trust and preventing spoofing, they refer to different aspects of the email verification process.
Understanding this distinction is particularly vital for organizations utilizing email service providers (ESPs) with shared IP addresses, such as Salesforce Marketing Cloud (SFMC). Misinterpreting these concepts can lead to persistent deliverability issues, including email bouncebacks and blocks from major mailbox providers like Hotmail (Outlook.com).
DKIM authentication is the process by which a recipient's mail server verifies that an incoming email has not been altered in transit and that it genuinely originates from the domain it claims. This is achieved through a cryptographic signature attached to the email header. The sending server uses a private key to sign the email, and the receiving server uses a corresponding public key, published in the sender's DNS records, to decrypt and verify the signature.
When a message arrives, the recipient mail server looks at the DKIM-Signature header. This header contains a d= tag, which indicates the signing domain, and an s= tag, which specifies the selector for the public key. The server then queries the DNS for the public key using these values. If the signature successfully decrypts with the public key and the message body matches the original, DKIM authentication passes. This process is one of the pillars of email authentication.
A passing DKIM authentication means the email is cryptographically verified, confirming its integrity and source. However, this alone does not guarantee inbox delivery. It merely confirms that the technical authentication checks were successful, paving the way for further reputation and alignment assessments by the recipient mail server.
DKIM alignment: connecting sender identity
While DKIM authentication confirms the technical validity of the signature, DKIM alignment (also known as DMARC alignment) takes this a step further by verifying the sender's identity from a user-facing perspective. For DKIM alignment to pass, the domain in the d= tag of the DKIM-Signature must match the domain in the visible From header (RFC 5322.From) of the email.
There are two types of DKIM alignment:
Strict alignment: Requires an exact match between the d= domain and the RFC 5322.From domain.
Relaxed alignment: Allows for a subdomain match, for instance, a d= domain of mail.example.com aligning with an RFC 5322.From domain of example.com.
DKIM authentication verifies the cryptographic signature on an email. This confirms the message's integrity and that it hasn't been tampered with since it left the sender's server. It uses a private key on the sending server and a public key published in DNS.
The check involves looking at the DKIM-Signature header, retrieving the public key from the d= and s= tags, and confirming the signature's validity.
Sender identity verification
DKIM alignment verifies that the domain responsible for signing the email (the d= domain) matches the domain visible to the recipient in the From address (RFC 5322.From).
This alignment is crucial for DMARC policy enforcement. If authentication passes but alignment fails, the DMARC check will also fail, potentially leading to deliverability issues. Alignment can be strict or relaxed, depending on whether subdomains are allowed to match.
SFMC shared IPs, bouncebacks, and Hotmail blocks
Many large-scale email senders, including Salesforce Marketing Cloud (SFMC), use shared IP addresses for sending emails. While this can be cost-effective and simplify setup, it introduces a critical dependency: your email reputation is intertwined with that of other senders sharing the same IP. If one sender on a shared IP engages in poor sending practices (e.g., sending spam, high bounce rates), it can negatively impact the deliverability of all other senders on that IP, potentially leading to broad email blocklist (or blacklist) placements and increased bouncebacks.
When you receive a bounce message like "5.7.1 (delivery not authorized) Helo command rejected: Access denied", it might not directly indicate a DKIM authentication or alignment failure, especially if your DNS records are correctly delegated to SFMC. This type of bounce can sometimes be a generic rejection message for various reasons, including general server blocks or reputation issues, rather than a specific authentication protocol problem. The category SFMC assigns to it might also not be perfectly accurate.
Specific to Hotmail (Outlook.com) blocks, you might see bounces stating: "5.7.1 (delivery not authorized) Unfortunately, messages from [IP address] weren't sent. Please contact your Internet service provider since part of their network is on our block list (S3140)." This message is a clear indicator that the shared IP address you are using is listed on Microsoft's internal blacklist (blocklist). This typically occurs due to cumulative sending behavior from that IP, not just your own.
In such cases, while SFMC manages the shared infrastructure, resolving these IP blocklists (blacklists) often requires direct communication with the mailbox provider's postmaster team. Microsoft's postmaster site is the appropriate channel. SFMC (Salesforce Marketing Cloud) may not be able to resolve these issues on your behalf since the problem lies with the content or sending practices impacting the shared IP's reputation, rather than a misconfiguration on SFMC's end.
Resolving Hotmail (Outlook.com) blocklist issues
Receiving a bounce message with an S3140 code from Hotmail (Outlook.com) indicates that the shared IP address you are using is on their internal blocklist (or blacklist). This is typically due to the collective sending reputation of all users on that IP, not necessarily your individual authentication setup.
To resolve this, you generally need to engage directly with the Microsoft Postmaster site. Provide the bounce details and any relevant information about your sending practices. While Salesforce Marketing Cloud manages the shared IPs, the responsibility for your email content and list hygiene ultimately rests with you, and that is what needs to be addressed for delisting.
For Salesforce Marketing Cloud users, proper domain delegation is crucial for email authentication. When setting up your Sender Authentication Package (SAP), you will typically delegate a subdomain (e.g., email.yourcompany.com) to SFMC's nameservers. This delegation enables SFMC to manage all necessary DNS records, including SPF, DKIM, and DMARC, on your behalf.
Example SFMC nameserver delegationDNS
email IN NS ns1.exacttarget.com.
email IN NS ns2.exacttarget.com.
email IN NS ns3.exacttarget.com.
email IN NS ns4.exacttarget.com.
Troubleshooting and best practices
If you are encountering deliverability issues and suspect problems with DKIM authentication or alignment, the first step is to obtain the full email headers from a message sent through SFMC. These headers contain crucial information about the authentication results (SPF, DKIM, DMARC) and will show whether the email passed authentication and alignment checks. You can use various online tools to parse these headers for a clearer understanding.
Sometimes, you might see a "body hash did not verify" error, indicating a transient (temporary) DKIM authentication failure. This can occur due to minor modifications to the email content during transmission or issues with the underlying email template. If this is not a persistent issue, it may resolve itself. However, consistent failures warrant a deeper investigation into your email content and sending platform configuration. It is also important to remember that some online tools that report authentication failures might have bugs or inconsistencies, so always cross-reference with multiple reliable sources and your DMARC reports.
For new senders using SFMC shared IPs, especially if you just started sending, a robust IP warming strategy is essential. Gradually increasing your sending volume to engaged recipients helps build a positive sending reputation with mailbox providers like Hotmail. This practice can mitigate the risk of being affected by other senders on a shared IP and prevent your IP from landing on a blocklist (or blacklist).
Key takeaways for email deliverability
DKIM authentication confirms the email's digital signature and integrity, while DKIM alignment (governed by DMARC) verifies that the signing domain matches the visible sender domain. Both are fundamental to email security and deliverability. Authentication is a technical pass, but alignment ensures your brand's identity is correctly presented and validated by DMARC.
For senders using SFMC shared IPs, understanding this difference is crucial for effective troubleshooting. Issues like Hotmail (Outlook.com) blocks are often reputation-based IP blocklists (or blacklists), not necessarily authentication failures. Proactive monitoring, proper IP warming, and direct engagement with mailbox providers when needed are key strategies to maintain optimal email deliverability, even on shared infrastructures.
Views from the trenches
Best practices
Always verify your DKIM setup using multiple reputable email authentication testing tools to ensure consistency.
Implement a proper IP warming strategy when using shared IPs, especially with new email platforms or increased sending volume.
Focus on maintaining a clean email list to avoid spam traps and high bounce rates, which negatively impact sender reputation.
Common pitfalls
Misinterpreting bounce messages, such as mistaking a 'delivery not authorized' error for a direct authentication problem.
Not actively engaging with postmaster sites (like Microsoft's) for IP-based blocklistings, assuming the ESP will handle everything.
Overlooking that shared IP reputation can heavily impact your deliverability, even when your individual authentication is perfect.
Expert tips
DKIM aligned means that the d= domain is aligned with the domain in the 5322.from address.
DKIM authenticated means the DKIM signature passed.
There's nothing private about a DKIM signature, which can only validate through retrieval of a record that’s published in DNS for all to see.
Expert view
Expert from Email Geeks says: DKIM authenticated refers to whether or not the DKIM-Signature header validated, while DKIM Alignment means that the DKIM signing domain aligned with the visible From domain in the email message.
2024-01-10 - Email Geeks
Expert view
Expert from Email Geeks says: A transient body hash verification issue can occur without anything wrong with the setup, as mail can sometimes change in transit.
Hotmail (Outlook.com).
Salesforce Marketing Cloud (SFMC), use shared IP addresses for sending emails. While this can be cost-effective and simplify setup, it introduces a critical dependency: your email reputation is intertwined with that of other senders sharing the same IP. If one sender on a shared IP engages in poor sending practices (e.g., sending spam, high bounce rates), it can negatively impact the deliverability of all other senders on that IP, potentially leading to broad email blocklist (or blacklist) placements and increased bouncebacks.
Microsoft's postmaster site is the appropriate channel. SFMC (Salesforce Marketing Cloud) may not be able to resolve these issues on your behalf since the problem lies with the content or sending practices impacting the shared IP's reputation, rather than a misconfiguration on SFMC's end.
