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?
Updated on 20 Oct 2026: We clarified SFMC authentication checks and added Outlook.com high-volume sender requirements to distinguish DKIM failures from shared IP blocks.
DKIM authentication and DKIM alignment answer two different questions. DKIM authentication asks whether the DKIM signature actually validates against the public key in DNS. DKIM alignment asks whether the domain in the DKIM signature, the d= domain, matches the visible From domain closely enough for DMARC.
That distinction matters with SFMC shared IPs because a message can pass DKIM authentication, pass DKIM alignment, and still bounce at Hotmail. A passing signature shows that the holder of the signing domain's private key signed the message and that the signed content validated. It does not prove that Microsoft accepts the sending IP, shared pool, HELO name, campaign, or sender reputation.
If the Hotmail bounce says an IP or network is on a block list, investigate Microsoft's IP reputation policy. That wording does not establish a DKIM failure. A HELO rejection concerns the SMTP greeting, even when SFMC puts it in an "Authentication" category.
DKIM authentication vs DKIM alignment
Separate these checks before changing DNS. DKIM authentication is a cryptographic result. DKIM alignment is a DMARC domain-matching result. They often pass together, but they fail for different reasons and point to different fixes.
|
|
|
|
|---|---|---|---|
DKIM auth | Signature and DNS key | The signature validates | Fix selector, key, or body changes |
DKIM alignment | Signing and From domains | DMARC accepts the domain match | Use a signing domain tied to From |
DMARC pass | SPF or DKIM plus alignment | At least one method passes with domain alignment | Repair SPF or DKIM domain use |
How DKIM authentication, DKIM alignment, and DMARC relate.
Fast rule
- Authentication: The receiver checks the body hash and verifies the signature using the public key.
- Alignment: The signing domain has the right relationship to the visible From domain.
- Deliverability: Mailbox providers still apply reputation, policy, content, and blocklist checks.
DKIM authentication shows that the signed parts of the message validated against the signing domain's key. DKIM alignment connects that signing domain to the visible author domain. DMARC needs either SPF or DKIM to pass authentication with domain alignment. If a message carries multiple DKIM signatures, one passing, aligned signature is enough for the DKIM path to satisfy DMARC.
How DKIM authentication is proven
A receiver verifies DKIM by reading the DKIM-Signature header, extracting the selector from s= and the signing domain from d=, then looking up the public key at selector._domainkey.domain. The name can return the TXT key directly or a CNAME that leads to it. If the body hash and the signature over the signed header fields validate, DKIM authentication passes.
DKIM signature and DNS lookup patterntext
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=email.example.com; s=sfmc1; h=from:subject:date:to; bh=BASE64_BODY_HASH; b=BASE64_SIGNATURE sfmc1._domainkey.email.example.com. TXT "v=DKIM1; k=rsa; p=MIIB..."
When a receiver reports DKIM failure, common causes include a missing selector, the wrong public key, a stale DNS record, a broken key format, or a signed header or body that changed after signing. Pull s= and d= from the raw message header, then use Suped's DKIM checker to inspect that selector and domain. A DNS key check does not verify an individual message; independent verification needs the original headers and body. The c=relaxed/relaxed signature setting controls canonicalization, not DMARC domain matching. RFC 6376 defines these verification steps.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
A common trap is checking the From domain when the actual DKIM signing domain is a delegated SFMC subdomain. The verifier follows the DKIM header. If the header says d=email.example.com, the DNS key must exist under that domain, even if the visible From address uses example.com.
How DKIM alignment is judged by DMARC
DKIM alignment compares the d= domain in the DKIM signature with the visible 5322.From domain. In relaxed mode, a subdomain match is accepted when both domains have the same Organizational Domain. In strict mode, the domains must match exactly. The adkim=r setting selects relaxed DKIM alignment and is the default when omitted; adkim=s requires an exact domain match.
RFC 9989 is the current DMARC protocol standard and obsoletes RFCs 7489 and 9091. It specifies the DMARC Tree Walk to find the Organizational Domain, so relaxed alignment is not a simple last-two-label comparison. RFC 9990 defines aggregate reporting, while RFC 9991 defines failure reporting.
DMARC alignment mode exampledns
_dmarc.example.com. TXT "v=DMARC1; p=none; adkim=r; aspf=r; rua=mailto:dmarc@example.com"
Relaxed DKIM alignment
- From: news@example.com
- Signing: email.example.com
- Result: DKIM alignment passes because both domains share example.com.
Strict DKIM alignment
- From: news@example.com
- Signing: email.example.com
- Result: DKIM alignment fails because the domains are not identical.
Some diagnostics show "DKIM alignment" by only comparing the two domain names. DMARC itself still needs the DKIM signature to pass. If the signing domain matches the From domain but the body hash fails, that message does not get a DKIM-based DMARC pass.
DKIM signature verification and domain comparison for a DMARC pass.
SFMC domain authentication on shared IPs
With Salesforce Marketing Cloud Engagement, a full Sender Authentication Package can cover email authentication and URL branding, while a standalone Private Domain is for authentication only and can keep a Salesforce shared IP assignment. The sending domain can use DNS delegated to Salesforce or DNS that your organization self-hosts. These choices are separate from whether a message-level DKIM signature validates. See Salesforce's domain configuration instructions.
Salesforce Marketing Cloud Engagement sending domain and DKIM authentication settings.
Typical SFMC subdomain delegationdns
email.example.com. NS ns1.exacttarget.com. email.example.com. NS ns2.exacttarget.com. email.example.com. NS ns3.exacttarget.com. email.example.com. NS ns4.exacttarget.com.
Use the name servers shown for the account rather than copying an example blindly. Salesforce documents exacttarget.com name servers for standard Engagement delegation and ums-dns-salesforce.com name servers for Hyperforce. Delegation assigns DNS management to Salesforce; it does not prove DKIM works. A delivered message shows which domain SFMC actually used in d= and whether the receiver accepted the signature. Check Salesforce's delegation instructions for your environment.
|
|
|
|---|---|---|
No DKIM key | Delegation or selector | Confirm s= and DNS |
Body hash fail | Message changed | Compare original and received message |
Domain mismatch | Sender profile | Compare From and d= |
Hotmail block | Authentication or IP policy | Review bounce code |
SFMC checks that map to the actual failure point.
SPF checks the envelope-sender domain, usually visible in the delivered Return-Path, rather than the visible From domain. With SFMC, a bounce domain under a different Organizational Domain can pass SPF without SPF alignment. A passing, aligned DKIM signature still satisfies DMARC. If SPF alignment is also needed across authenticated domains, ask Salesforce whether Multi-Bounce Domain support fits the account. See Salesforce's DMARC requirements.
Do not change DNS blindly
If SFMC owns the delegated subdomain, adding random DKIM records at the parent domain does not fix the signature SFMC is using. Pull the raw header first, identify the selector and signing domain, then test that exact pair.
Diagnose Hotmail bouncebacks by SMTP response
The bounce text matters more than the bounce category shown inside a sending platform. "Delivery not authorized" is SMTP language for not allowed or not permitted. It does not automatically mean the message failed DKIM, SPF, or DMARC.
Two bounce patterns that get misreadtext
554 5.7.1 delivery not authorized: <aku11.mta.exacttarget.com>: Helo command rejected: Access denied 550 5.7.1 delivery not authorized: messages from [128.245.242.10] weren't sent. part of their network is on our block list (S3140)
A rejection at HELO/EHLO happens before the receiver receives the message headers or body, so it is not a DKIM verification result for that attempt. Ask SFMC to check the greeting hostname, forward and reverse DNS, and receiver policy for the sending IP. A valid hostname alone does not identify which policy caused the rejection. RFC 5321 defines the SMTP command sequence.
The Hotmail S3140-style message is more direct. It identifies a Microsoft-controlled blocklist decision for the sending IP or part of its network, even when public blacklist checks show no listing. The exact NDR still controls the response path because Outlook.com consumer addresses and Microsoft 365 business recipients use different mitigation routes. If the error specifically names DKIM at Outlook.com or Hotmail, compare it with Hotmail DKIM failures.
How to read the bounce evidence
The bounce wording tells you whether to debug authentication or sending reputation.
Direct auth failure
Debug DNS and headers
The bounce identifies DKIM, SPF, DMARC, or error 5.7.515.
Authorization language
Read the next clause
The bounce says not authorized, access denied, or not permitted.
HELO rejection
Check hostname, DNS, and policy
The bounce rejects the sending host name or SMTP greeting.
Blocklist wording
Handle reputation
The bounce says the IP or network is on a block list.
Authentication issue
- Evidence: Receiver identifies failed DKIM, SPF, DMARC, or error 5.7.515.
- Data: Raw headers and DMARC aggregate results show failures.
- Fix: Repair signing, DNS, sender domain use, or SPF path.
Reputation or policy issue
- Evidence: Receiver names an IP blocklist or rejects the SMTP greeting.
- Data: Comparable delivered messages pass authentication; a HELO rejection provides no message-level result.
- Fix: Ask SFMC to review the hostname and IP policy, then address complaints and list quality.
Outlook.com's high-volume requirements and error 5.7.515
Outlook.com applies high-volume authentication requirements to domains sending more than 5,000 messages per day to its consumer services, including Hotmail. Using an SFMC shared IP does not exempt the sending domain. See Microsoft's sender requirements.
- SPF authentication must pass for the actual envelope-sender domain.
- DKIM authentication must pass for a message signature.
- The From domain must have a valid DMARC policy, with p=none accepted as the minimum.
- DMARC must pass through at least one authenticated method with domain alignment.
Outlook.com authentication requirement rejectiontext
550 5.7.515 Access denied, sending domain <domain> does not meet the required authentication level.
A 550 5.7.515 rejection points to authentication compliance. Check SPF even when DKIM provides a DMARC pass. This differs from the IP or network blocklist wording in S3140. Microsoft's 5.7.515 guidance explains the required checks.
How to troubleshoot SFMC DKIM and Hotmail blocks
Start with a real delivered message, not only a platform status screen. Send a campaign-style test through the same SFMC business unit, sender profile, From domain, and IP pool used for production. Then compare the raw header result with aggregate DMARC data and the exact bounce text. Treat a delivered test as comparison evidence: shared-pool routing can use a different IP, and a rejection before message transfer provides no DKIM result.
- Pull: Copy the DKIM-Signature header and note s=, d=, and the receiver-added Authentication-Results line; compare header.d, smtp.mailfrom, and header.from.
- Validate: Check the selector record that matches the header, not the domain you expected.
- Compare: Compare source IPs, authentication results, and domain alignment in available Microsoft DMARC aggregate reports. Missing reports do not prove delivery or authentication success.
- Classify: Separate 5.7.515 authentication failures from HELO rejections and IP blocklist wording. A temporary 4xx response is a deferral; a 5xx response rejects that attempt.
- Escalate: Give SFMC the full SMTP response, affected recipient domain, source IP, UTC timestamp, job ID, and message sample. Coordinate Microsoft escalation through SFMC for its shared infrastructure.
Suped's DMARC reporting and email authentication product groups aggregate results by sending source and shows SPF and DKIM results with domain alignment. Compare SFMC source IPs and Microsoft report results with the bounce logs. Public blocklist alerts do not establish whether Microsoft's internal blacklist has blocked a shared IP.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
For a one-off check, use Suped's domain health check to inspect public DNS. Suped's DMARC monitoring tracks reported authentication results over time; combine those reports with SFMC bounce logs to investigate rejected attempts.
Shared IPs change the Hotmail diagnosis
On a shared SFMC IP, your mail shares IP reputation with other senders in that pool. Your domain reputation still matters. Salesforce does not guarantee that each send uses the same shared IP, so record the actual source IP for each rejection. See Salesforce's shared IP policy.
What the Hotmail block means
A Hotmail rejection that says the sending IP or network is on a blocklist (blacklist) points to IP reputation policy. DKIM still needs to be correct, but a DNS change alone does not remove that block.
Keep authentication correct, increase your own sending volume gradually, and reduce complaint risk. A shared pool is already in use; ask SFMC to review pool health rather than assuming you must warm the shared IP yourself. SFMC needs the exact IP, bounce code, timestamp, account details, and sample message because it controls the shared infrastructure.
|
|
|
|---|---|---|
Pool reputation | Neighbors affect the same IP | Ask SFMC to review pool health |
New sending | Hotmail lacks history | Warm volume in stages |
List quality | Complaints damage reputation | Suppress risky segments |
Bounce code | Tells you the block type | Track each code separately |
Shared IP diagnosis for Hotmail blocks.
A dedicated IP gives more direct control over IP reputation, but it also puts the whole warming burden on you. Salesforce currently positions shared IPs for accounts sending fewer than 100,000 emails per month, recommends a dedicated IP above 100,000, and requires one above 250,000. The decision should still come after you know whether the current block is tied to your domain, mail stream, shared pool, or a specific Microsoft policy response.
Views from the trenches
Best practices
Pull the raw DKIM-Signature header first, then test the exact selector and domain.
Keep SFMC delegation checks separate from message-level DKIM verification results.
Use exact bounce codes and timestamps when escalating Hotmail blocks with support.
Common pitfalls
Treating every 5.7.1 bounce as an authentication failure hides reputation blocks.
Testing the visible From domain instead of the DKIM signing domain creates false alarms.
Assuming shared IP reputation is clean because domain authentication passes is risky.
Expert tips
Compare a real mailbox header with DMARC aggregate data before changing DNS records.
Check whether the body hash failure repeats before blaming the SFMC domain setup.
Track Hotmail blocks apart from Gmail or Yahoo results because each provider differs.
Marketer view
Marketer from Email Geeks says DKIM authentication means the signature passed, while DKIM alignment checks whether the signing domain matches the visible From domain.
2024-01-11 - Email Geeks
Marketer view
Marketer from Email Geeks says a matching signing domain is not enough when the body hash fails, because DMARC needs a passing DKIM result.
2024-01-11 - Email Geeks
Frequently asked questions
Yes. The signature can validate while the signing domain does not match the visible From domain closely enough for DMARC.
Not for a DKIM-based DMARC pass. Some diagnostics show the domains match, but DMARC still needs a valid DKIM signature.
No. S3140-style wording points to a Microsoft-controlled IP or network blocklist decision. DKIM can pass and that bounce can still happen.
Ask for the signing domain, selector, sending IP, shared pool details, bounce classification notes, and confirmation that the delegated or self-hosted subdomain is healthy.
Base the decision on your sending volume, ability to warm a dedicated IP, and SFMC's diagnosis of the block. A dedicated IP does not repair an authentication failure or a domain-level policy problem. Salesforce recommends one above 100,000 emails per month and requires one above 250,000.
SPF validates the envelope-sender domain, usually shown in the Return-Path. If that domain and the visible From domain do not meet the DMARC domain-matching rule, SPF alignment fails. DMARC still passes when a DKIM signature both validates and has domain alignment.
