DKIM Signature Algorithm Inconsistency Across Gmail Outlook Yahoo

Why Does DKIM Break Randomly in Gmail, Outlook, and Yahoo?

You send a clean, properly signed email. It passes checks everywhere — until it lands in Gmail, and suddenly the DKIM validation fails. You check your DNS. It’s correct. You re-run the test. It passes in Outlook, fails in Yahoo. This isn’t a fluke. It’s the reality of inconsistent DKIM signature algorithm handling across major inbox providers.

DKIM is meant to verify email authenticity. But when Gmail, Outlook, and Yahoo interpret the same signature differently — due to variations in how they process cryptographic algorithms — validation breaks. It’s not your domain misconfiguring things. It’s the clients doing it on their end. And that inconsistency directly harms deliverability, especially at scale.

Key takeaways

• DKIM signature algorithm handling varies between Gmail, Outlook, and Yahoo, causing valid signatures to fail unpredictably.
• These inconsistencies are not due to sender errors but stem from differences in how each provider implements and validates the DKIM standard.
• High-volume senders see higher bounce rates and degraded sender reputation because DKIM failures are often treated as spam indicators, even when messages are legitimate.

What Is the DKIM Signature Algorithm Inconsistency You’re Seeing?

DKIM signatures use cryptographic algorithms—mostly RSA-SHA256 and RSA-SHA1—to verify email authenticity. Even when your signature follows RFC 6376, Gmail, Outlook, and Yahoo may process the algorithm tag differently, leading to inconsistent validation. One provider might accept a valid RSA-SHA1 signature while another rejects it, even if the key and domain are correct.

How Each Email Provider Handles DKIM Algorithms Differently

While RFC 6376 defines the standard, real-world implementation varies. Gmail tends to accept a broader range of algorithm tags, including SHA1, though it prefers SHA256. Outlook, on the other hand, has stricter validation and may reject signatures marked with SHA1, even if they’re technically valid. Yahoo’s behavior sits in between—but it has been known to reject emails with outdated algorithms, especially in recent years.

Let’s say you’re sending from a domain with a properly set up DKIM record using RSA-SHA1. The signature passes validation on a test server. But when it lands in Outlook, it fails. Why? Because Outlook ignores the key's validity if the algorithm tag doesn’t meet its internal criteria—regardless of whether RFC 6376 permits it. This isn’t a bug; it’s a policy. Google, Microsoft, and Yahoo each interpret the standard with their own operational thresholds.

What This Means for Your Deliverability

If your email is being rejected by only one client—not all—check the DKIM algorithm tag in your DNS record. A mismatch here can cause a single client to flag your message as untrusted. Even if your SPF and DMARC pass, an unsupported or improperly formatted algorithm tag can be enough to send the email to spam or a drop.

For example, if your sender domain uses RSA-SHA1 and you're seeing consistent deliverability drops in Outlook, that’s likely the root cause. Switching to RSA-SHA256 removes the risk of algorithm rejection. This isn’t just best practice—it’s increasingly required by email providers upgrading their security thresholds.

You can verify your DKIM configuration at scale using real-world testing. MailTester’s inbox placement tests simulate delivery across Gmail, Yahoo, and Outlook, highlighting issues like algorithm mismatches before they hit your audience. This way, you catch inconsistencies early, not after the damage is done.

How Do Gmail, Outlook, and Yahoo Differ in Handling DKIM Algorithms?

Gmail, Outlook, and Yahoo apply different standards to DKIM signature algorithms. Gmail requires RSA-SHA256 and ignores older signatures unless explicitly permitted by DMARC. Outlook accepts multiple algorithms but rejects those with non-standard or untrusted digests. Yahoo has historically flagged messages with mismatches in selector or key length, especially if not aligned with expected patterns.

Gmail’s Strict Enforcement of RSA-SHA256

Gmail treats DKIM validation as strict. It only accepts RSA-SHA256 signatures by default. If your message uses RSA-SHA1 or another outdated algorithm, Gmail will mark it as invalid unless your DMARC policy explicitly allows it.

Let’s be clear: even if your domain uses DKIM and signs with a valid key, old algorithms will still fail. This is not a bug—it’s policy. Google has standardized on SHA256 because it’s cryptographically sound and widely adopted in modern email systems.

You can check your current DKIM setup using tools like MxToolbox or by reviewing DNS records through your domain registrar. If you're sending emails at scale, verify your DKIM implementation with a real-time email validation service that tests inbox placement—try inbox placement testing to see how your messages appear across major providers.

Outlook and Yahoo: Less Strict, But Still Picky

Outlook (Microsoft 365) allows a broader range of algorithms, including RSA-SHA1 and others, but still evaluates the digest algorithm and key integrity. If an email uses a digest not recognized as valid or a key outside known trust boundaries, Outlook may treat the message as suspicious or drop it.

Yahoo’s filtering systems have historically been more sensitive to inconsistencies in DKIM setup—especially around selector names and key length. For example, a mismatch between the selector in the DKIM-Signature header and the DNS record, or a poorly structured key, can trigger filtering.

Sending from a domain with outdated or inconsistent DKIM settings can hurt deliverability—even if your SPF and DMARC are correct. This isn’t just theoretical: RFC 6376 (the DKIM specification) defines the expected structure, and large providers like Yahoo and Microsoft use those standards to assess legitimacy.

When you’re managing a large list, testing your setup across providers helps catch subtle errors. Use a service like bulk verification to check a list before sending, and ensure your DKIM records are correctly published and aligned with your sending infrastructure.

How to Test and Diagnose DKIM Algorithm Inconsistencies

Send the same email from your domain to test accounts on Gmail, Outlook, and Yahoo, then inspect the full headers in each inbox. Look for DKIM-Result fields that show ‘fail (algorithm)’ or ‘pass (unknown algorithm)’—these are signs that your domain’s DKIM signature is being processed inconsistently across providers. Use this method to catch problems before they hurt deliverability.

Step-by-Step Testing Process

1. Prepare a test email using your verified domain and standard headers. Avoid attachments or unusual content that might trigger filtering.
2. Send it to controlled test addresses across Gmail, Outlook, and Yahoo. Use dedicated test accounts to avoid noise or cache effects.
3. Retrieve full headers from each inbox. In Gmail, click the three-dot menu and select “Show original.” In Outlook, go to “File” > “Properties” > “Internet headers.” On Yahoo, select “More” > “View message source.”
4. Search for the DKIM-Result field in the headers. Look for values like pass, fail (algorithm), fail (signature), or pass (unknown algorithm).
5. Compare results across providers. A pass in Gmail but a fail (algorithm) in Yahoo suggests one provider doesn’t support your chosen signing algorithm or hash method.

What the Results Mean

When you see fail (algorithm), the receiving server recognized your signature but couldn’t verify it due to an unsupported algorithm—common when using non-RFC-compliant or custom hash methods. pass (unknown algorithm) means the server verified the signature but didn’t recognize the algorithm used, often indicating a newer or non-standard option.

According to the DKIM specification (RFC 6376), only a few hash algorithms (like SHA-256 and SHA-1) are widely supported. Using lesser-known or proprietary variants can lead to inconsistent results across major providers. While SHA-1 is still accepted, it’s deprecated in favor of SHA-256 for new implementations.

Use tools like MailTester’s inbox placement tester to simulate real-world delivery and capture header-level diagnostic signals without manual inspection. This helps catch algorithm mismatches early, especially when scaling outbound campaigns.

For developers, ensure your signing libraries default to SHA-256 and include standard algorithm identifiers in the DKIM-Signature header. This reduces risk of cross-platform inconsistency. If you're troubleshooting, verify that your key size (1024/2048/4096 bits) and algorithm are compatible with the receiving server's expectations.

Why Standard Tools Often Miss These Algorithm Inconsistencies

Most email validation tools only check if a DKIM signature is cryptographically valid — not whether inbox providers like Gmail, Outlook, or Yahoo will actually accept it. These tools don’t simulate the real-world processing of the a= tag in the DKIM signature, which can lead to silent failures in production. You might pass every test, yet still get blocked by a major provider because of algorithm inconsistencies they enforce in practice, not in theory.

What Standard Tools Don’t Tell You

Standard email verification tools focus narrowly on cryptographic validity. They check that the signature matches the public key and that the hash calculations are correct — but they don’t simulate how inbox providers interpret the a= tag, which specifies the hash algorithm used.

For example, Gmail requires a=rsa-sha256 and rejects a=rsa-sha1, even if the signature is mathematically valid. Outlook and Yahoo have different, evolving thresholds for algorithm handling. A signature that passes a tool’s check might still fail delivery because it uses a deprecated or non-standard algorithm tag.

Why This Matters in Practice

These differences aren’t just theoretical. RFC 6376 (the standard for DKIM) allows multiple algorithms, but real inbox providers implement them selectively — often favoring newer ones like rsa-sha256 or ecdsa-sha256 over older variants.

Without testing across actual inbox environments, you’re guessing. A tool that says "signature valid" doesn’t tell you if the message will end up in the spam folder or be silently dropped.

That’s why it’s better to test delivery in real inboxes, not just validate signatures on paper. You can catch algorithm-level incompatibilities before they damage sender reputation or trigger hard bounces.

For example, use inbox placement testing to see how your messages land in Gmail, Outlook, and Yahoo—before sending to your full list.

As outlined in RFC 6376, the a= tag is part of the signature’s integrity. But real-world inbox filtering doesn’t follow the RFC exactly. Your system might be “correct” by spec — but still rejected for using an outdated algorithm.

Think of it like passing a security scan but being turned away at the gate. You’ve done everything “right,” but the gatekeeper doesn’t recognize your badge. That’s what happens when tools don’t replicate actual inbox logic.

Let’s be honest: you don’t need more validation layers — you need the right ones. Focus on testing real delivery, not just cryptographic correctness.

How MailTester Detects Real-World DKIM Failures Before You Send

You don’t need to guess if your DKIM signature will pass with Gmail, Outlook, or Yahoo. MailTester tests your messages in real inboxes across all three providers, catching algorithm mismatches and signature inconsistencies before they trigger bounces or landing in spam. It’s not just about validity—it’s about how your DKIM handles real-world email infrastructure differences.

Real Inboxes, Real Failures

Most tools check DKIM for basic syntax or DNS alignment. But real email clients vary in how strictly they enforce signature algorithms. Gmail, Outlook, and Yahoo don't all treat the same DKIM signature the same way. A signature that passes one provider might fail silently on another due to algorithm inconsistency—like using RSASSA-PKCS1-v1_5 when one provider expects only SHA-256 with RSA.

MailTester’s inbox placement tests aren’t simulations. They use actual inboxes on Gmail, Outlook, and Yahoo to verify delivery and authentication at scale. If your DKIM signature fails validation on one of these, we flag it. We don’t just say "failed"—we show exactly where it fails and why.

Clear Root Cause Labels for Actionable Fixes

Instead of vague "DKIM error" messages, MailTester provides detailed results, breaking down whether your signature passes or fails per client. If it fails, we label the root cause—like “Algorithm mismatch” or “Signature hash mismatch.” You’ll know immediately if the issue is with the signing method, digest algorithm, or key alignment.

Because DKIM relies on public key cryptography, even small mismatches in signing algorithms between your server and a receiver’s expectation can cause delivery failure. This is why industry-standard RFCs like RFC 6376 and RFC 7258 outline strict verification rules. MailTester respects those rules by testing against real-world implementations, not textbook theory.

Let’s say you’re sending a newsletter. A DKIM mismatch in Outlook might not surface during basic checks, but it’s enough to trip spam filters. With MailTester, you catch that early. No more guesswork. No more surprise bounces. Just a clear report: "DKIM fails on Yahoo due to algorithm inconsistency."

Want to test your next campaign before it goes live? Run an inbox placement test with MailTester. It’s built to spot what the rest miss—right before you send.

Step-by-Step Fix: Aligning DKIM Algorithms for Consistent Delivery

You’re getting inconsistent delivery across Gmail, Outlook, and Yahoo because your DKIM signatures use different algorithms or key lengths. Fix it by auditing your DNS records, ensuring all messages are signed with RSA-SHA256 and 2048-bit keys, and updating your DMARC policy to reject non-SHA256 messages. This alignment prevents rejection during strict validation, especially in high-security email environments.

Diagnose the root issue with full header analysis

Let’s start by finding where things go wrong. Use MailTester’s inbox placement testing to send a test message and analyze the full email headers. This reveals the exact DKIM signature algorithm used and whether it matches the one in your DNS record.

Many providers—including Gmail and Yahoo—have tightened their DKIM validation over time. If your sending server uses SHA1 or an unexpected algorithm, those platforms will flag the message as suspicious, even if the domain is valid. You won’t see this in basic bounce reports—only through header inspection.

1. Audit existing DKIM records using MailTester’s full header analysis. Run your message through MailTester’s inbox tester to extract the full header, including the DKIM-Signature field. Look for the a= tag to identify the algorithm used. If it shows a=rsa-sha1 or a=rsa-sha256, you’re on the right track—just verify consistency.
2. Ensure your signing server uses only RSA-SHA256. If your mail server or third-party service (like SendGrid, Mailchimp, or your own MTA) supports multiple algorithms, disable SHA1 and any legacy options. Only allow RSA-SHA256—this is the standard required by modern recipients.
3. Re-sign messages with consistent key length (2048-bit minimum). Even if the algorithm is correct, using 1024-bit keys increases the risk of rejection. Gmail, for example, explicitly favors keys of 2048 bits or higher. Use tools like RFC 6376 to verify that your signing implementation meets current standards.
4. Validate across all three providers. After re-signing, test again through MailTester’s inbox tester to confirm the same signature appears in all three environments. Consistency here means your message will pass alignment checks in DMARC and won’t be flagged as forged.

Enforce compliance with DMARC policy updates

Now that signatures are consistent, lock it in. Update your DMARC policy to include asp=strict and sp=reject if you want to block anything that doesn’t meet the standard. A strict policy ensures only messages that pass both SPF and DKIM with SHA256 are delivered.

If you’re seeing unexpected rejections, your current policy might be too permissive. Use DMARC.org as a reference to configure your policy, and monitor quarantine and reject reports to confirm enforcement is working.

Alignment isn’t a formality. It’s the foundation of sender trust. If your DKIM algorithm or key size varies, even slightly, you’re inviting failure.

Email Verification to Prevent DKIM-Based Bounce Loops

Even if your email is correctly signed with DKIM, it can still be bounced or rejected if it lands in a misconfigured inbox, a catch-all setup, or a role account with aggressive filtering. DKIM validation doesn’t guarantee delivery—only trust in the inbox’s handling policies does. MailTester’s bulk verification checks real-world inbox behavior, catching invalid, disposable, or high-risk addresses before you send.

DKIM Works, But Inboxes Don’t Always Trust It

DKIM signatures are a standard part of email authentication, but they’re only one piece of the puzzle. An email with a valid DKIM signature can still be rejected if the receiving server’s rules block certain domains, roles, or catch-all setups. This isn’t about the signature—this is about the inbox’s configuration. Gmail and Outlook, for example, apply different filtering logic depending on how the domain is set up.

Some organizations use catch-all addresses that accept all emails regardless of recipient. These often trigger automated rejections or bounce loops. Role accounts like admin@, support@, or sales@ are also commonly blocked or filtered—even if they’re valid—because they’re widely used for spam. Disposal domains, which exist only temporarily, never accept mail long-term. Verifying these isn’t optional; it’s critical to prevent wasted sends and reputation damage.

Verify Before You Send—Real Inbox Behavior, Not Just Syntax

Let’s say you send an email to a list that includes a catch-all address. The email passes DKIM, SPF, and DMARC checks. The sender’s reputation is solid. But the receiving server rejects it anyway—because the inbox isn’t designed to handle messages that arrive without a specific recipient. No bounce is returned; instead, the message disappears into a vacuum. This creates a silent failure that kills deliverability over time.

MailTester’s bulk verification simulates real inbox behavior. It checks whether an address will accept your message, not just if it follows syntax rules. It flags catch-alls, role accounts, disposable domains, and mismatched MX records—often the culprits behind DKIM-based rejection patterns. The result? Fewer bounces, lower spam complaints, and a healthier sender reputation.

Use MailTester’s bulk verification to clean your list before sending. It’s not just about syntax—it’s about real inbox response. With 98.9% accuracy, it identifies addresses that would fail delivery even with perfect DKIM signing. This level of insight isn’t available through basic syntax checks.

And because no credit expires, you can verify large volumes, test campaigns, or integrate with Mailchimp, HubSpot, Klaviyo, or SendGrid—without worrying about credit deadlines. For a real-world test of your message's journey, try inbox placement testing to see how your email lands across real inboxes.

Real-World Impact: How Algorithm Inconsistencies Hurt Deliverability

DKIM signature algorithm inconsistencies across Gmail, Outlook, and Yahoo aren’t just technical quirks—they directly damage your sender reputation. A single failed DKIM signature in Gmail can trigger a reputation penalty over time, increasing the odds your messages get filtered. Outlook may push your email to the junk folder if it doesn’t recognize the algorithm, even if SPF and DMARC pass. Yahoo might silently drop the message if the signature doesn’t match its internal parsing rules, with no feedback to you. These differences mean your email can fail without any clear indication, leading to undelivered messages and degraded inbox placement.

How Gmail's Strictness Amplifies the Risk

Gmail doesn’t just check for a valid DKIM signature—it scrutinizes the exact algorithm used. If the signing algorithm doesn’t match expectations, Gmail logs a failure. Even a single such failure, especially in a high-volume sending context, can reduce your sender reputation score over time. This reputation impact accumulates across multiple messages and is harder to recover from than a temporary bounce. Let’s say you use a nonstandard algorithm like SHA-256 with a complex key—Gmail may still reject it due to internal configuration policies, even if technically correct.

Outlook and Yahoo: Silent Failures with No Feedback

Outlook’s behavior is more unpredictable. It may let a message through with a warning in the header but still place it in the junk folder if it sees a DKIM signature using an unfamiliar algorithm. No bounce report. No alert. Just lower engagement and poor deliverability. Yahoo takes it further: it may silently discard messages that don’t conform to its internal signature parsing rules, even when all other checks pass. This means you might think your email delivered—only to find zero opens, no replies, and no trace of it.

The real problem? These inconsistencies are baked into the platforms’ delivery logic. They’re not bugs; they’re design choices based on internal risk assessment. You can’t override them. What you can do is catch the problems early. Use a verification service like MailTester’s bulk verification tool to test your sender setup before sending, and check how your messages land in real inboxes with tools like inbox placement tests. The goal isn’t perfection—it’s consistency. A single misconfigured signature can cost you visibility. Stay ahead by validating signatures across real-world endpoints.

Integrate MailTester to Stay Ahead of Client-Specific DKIM Rules

DKIM signatures vary subtly across Gmail, Outlook, and Yahoo—not because they’re broken, but because their validation logic differs on how strictly they enforce signature alignment, key length, and algorithm use. You can’t rely on a one-size-fits-all approach. The only way to ensure inbox placement across these clients is to validate each address in real time, test deliverability with their actual filtering rules, and clean lists based on actual inbox results—not just syntax or basic validity.

Use the Real-Time API to Validate Before Every Send

• Check individual email addresses with the MailTester API before adding them to a campaign—this catches invalid, catch-all, and risky addresses early.
• Don’t rely only on syntax checks; use real-time validation to catch issues like temporary server blocks, role accounts, or domains with inconsistent DKIM implementation.
• Automate validation on receipt capture: when a new lead signs up, run a quick verification call to ensure they’re safe to send to.

Run Scheduled Bulk Checks Based on Inbox Placement, Not Just Syntax

• Use MailTester’s bulk verification to process entire lists and flag addresses that fail deliverability—especially those that pass syntax but fail DKIM checks on Gmail, Outlook, or Yahoo.
• Set up recurring runs to clean your list based on inbox placement success, not just basic validity. Addresses that consistently land in the spam folder despite being technically valid should be removed.
• Test your sends with inbox placement testing to see how your emails are treated across the three dominant platforms, including how DKIM signature alignment affects delivery.

Integrate Directly with Your Marketing Stack

• Link MailTester with Mailchimp, Klaviyo, HubSpot, or SendGrid to automatically verify emails before each campaign—no manual export, import, or cleanup.
• Let the system auto-reject invalid or high-risk addresses during segmentation, so only deliverable, inbox-ready emails go out.
• Reducing bounce rates and spam complaints directly improves sender reputation, which impacts DKIM acceptance across all major providers.

DKIM inconsistencies aren’t bugs—they’re guardrails. Gmail, Outlook, and Yahoo use them to prevent spoofing, but they’re not always consistent in how they apply them. The best defense isn’t a perfect signature—it’s knowing which addresses actually get delivered. That’s what MailTester delivers: real validation based on actual inbox behavior, not assumptions.

“Even a valid DKIM signature doesn’t guarantee inbox delivery—it’s the consistency of behavior across systems that matters.”

For more on how email validation reduces deliverability risk, see RFC 6376, which defines DKIM’s core framework. It explains how variations in signature algorithms and key use can affect acceptance—making real-world testing essential.

Final Takeaway: DKIM Is Only as Strong as the Weak Email Client

DKIM alignment isn’t optional — it’s required. But even a perfectly signed message can fail if one major client’s implementation differs from the others.

Gmail, Outlook, and Yahoo each apply DKIM validation with subtle, hidden differences. A signature that passes one client may fail silently in another. You can’t rely on standards alone when enforcement varies in practice.

Why Testing in Real Inboxes Matters

Standard tools and simulators don’t catch real-world algorithm mismatches. Only testing against actual inboxes reveals how your DKIM signatures hold up across client environments.

Missing this step means sending to campaigns that appear in junk folders or get dropped entirely — without a clear error code or failure reason.

MailTester Delivers What You Can’t See

MailTester’s inbox placement tests simulate real delivery to Gmail, Outlook, and Yahoo, identifying DKIM inconsistencies before they harm your sender reputation.

With 98.9% accuracy, it gives you concrete, actionable results — not assumptions, not theoretical best practices.

Sources

• Since May 5, 2025, Microsoft Outlook requires SPF, DKIM, and DMARC from domains sending 5,000+ emails per day, rejecting non-compliant mail outright at the SMTP level with error 550 5.7.515. — Microsoft Outlook requirements (via MailOver bulk-sender requirements guide) (2025)
• DMARC adoption among top domains surged 75% between 2023 and 2025 — from 27.2% to 47.7% — in the wake of Google and Yahoo's bulk-sender authentication requirements. — EasyDMARC 2025 DMARC Adoption Report (2025)

Keep reading

• Email authentication: SPF, DKIM, DMARC, BIMI and MTA-STS (complete guide)
• Why Does SPF Validation Fail When DNS TTL Is Too Low?
• How DNS Resolution Time Affects DKIM Signature Verification Success
• Best Practices for Short DKIM Selector Length to Avoid DNS Limits
• How DNS SPF Record Parsing Fails When Include Directive Is Unquoted

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What does 'DKIM signature algorithm inconsistency' mean?

It means the same email may be accepted by one inbox provider but rejected by another due to differences in how each handles the cryptographic algorithm used in the signature.

Why does Gmail reject DKIM even when it looks valid?

Gmail may reject non-SHA256 signatures or those using outdated standards, even if the signature passes cryptographic verification.

Can I fix DKIM algorithm mismatches without reconfiguring my email server?

Not reliably. You must ensure your server signs emails using RSA-SHA256 with a standard key size — this requires server-side configuration changes.

Do all email providers handle DKIM the same way?

No. Gmail, Outlook, and Yahoo each apply different policies and validation logic to DKIM signatures, leading to inconsistent delivery outcomes.

How does MailTester catch DKIM issues other tools miss?

It tests delivery in actual inboxes across Gmail, Outlook, and Yahoo, identifying algorithm mismatches and filtering behavior that synthetic checks won’t detect.

Is DKIM verification enough to ensure inbox placement?

No. Even if DKIM is valid, delivery can fail due to algorithm inconsistencies, sender reputation, or content filtering — requiring full inbox placement testing.

What percentage of delivery issues are caused by DKIM algorithm mismatches?

There is no published industry-wide statistic, but algorithm mismatches are a known contributor to inconsistent delivery, especially at scale.

Does MailTester support DMARC testing?

Yes — MailTester includes DMARC policy evaluation and reporting as part of its inbox-placement and deliverability analysis.

Can I verify my DKIM setup with a free test?

Yes — MailTester provides 100 free verifications to test your domains, messages, and inbox placement across real providers without cost.

How often should I test for DKIM algorithm issues?

After any change to your signing infrastructure, or monthly if you maintain a high-volume sending list. Use MailTester’s API or bulk verification to automate checks.

Do disposable domains pass DKIM verification?

Yes — many disposable domains publish valid DKIM records, but MailTester can identify them as risky sources that often lead to bounces or low engagement.

What’s the difference between DKIM pass and inbox placement success?

DKIM pass means cryptographic validation succeeded. Inbox placement success means the message reached the inbox — not spam, not blocked, and delivered reliably.