Why does a DKIM signature fail when images are embedded in multipart/alternative emails?

You send an email with a logo embedded in the HTML part using a cid: reference. It arrives fine in some inboxes, but others flag it as unsigned or altered. You’re not sure why — you’ve set up DKIM properly. The same email, seemingly unchanged, fails validation across different providers.

Here’s the issue: DKIM signs the body of an email based on its canonical form. When you embed images via cid: in a multipart/alternative message, the signing process sees a different body than what the receiving server evaluates. Subtle differences in whitespace, header order, or how embedded content is parsed during signing can break the digital signature.

Even when you use the exact same email content, mismatched canonicalization between signing and verification systems can invalidate the signature — not because the email is malicious, but because the signed content wasn’t preserved as expected.

Key takeaways

  • Different canonicalization methods during DKIM signing and verification can invalidate signatures, even with identical content.
  • Embedded images using cid: references alter the email body’s structure, increasing the risk of canonicalization mismatch.
  • Consistent header ordering, whitespace handling, and body rendering between signing and receiving systems is critical for DKIM validation success.

How does multipart/alternative structure affect DKIM signature validation?

DKIM signs the entire body of a multipart/alternative email, which includes both plain text and HTML versions. If the receiving server can't reconstruct the exact same body format—including line endings, encoding, and character sets—during verification, the signature fails, even if the visible content is identical. This is especially critical when images are embedded in the HTML part via Content-ID, because mismatched normalization during canonicalization breaks the signature.

Canonicalization is everything

DKIM relies on a strict process called canonicalization to compare the signed content with the received content. The signing tool must apply the same rules—like folding long lines, normalizing whitespace, and preserving encoding—as the receiving server. Even a single carriage return difference or a mismatched charset can invalidate the signature.

Let’s say you sign an email with a newline format of CRLF, but the receiving server expects LF. The body looks the same to you, but the hash won’t match. That’s why consistent canonicalization across systems is non-negotiable.

Content-ID and embedded images break the chain

When you embed an image using a Content-ID (like <img src="cid:[email protected]">), the full body—including the header line with the Content-ID—must be included and normalized identically in both signing and verification. If the signing tool doesn’t treat the Content-ID header exactly like the receiving server does—say, by folding or capitalizing differently—the signature fails.

This often happens when tools or systems don’t follow the same RFC 2822 and RFC 6376 rules for header processing. Even small differences in how line breaks are folded or how quoted-printable encoding is applied can cause the hash to differ.

For verification at scale, you need to validate not just whether an address exists, but whether the email’s structure will survive DKIM checks. You’re not just checking an address—you’re testing deliverability readiness.

Use a real-time verification API to test if your emails will pass DKIM checks before sending. It’s not enough to assume they will. Tools like MailTester’s API check validity, syntax, and common deliverability blockers—including those tied to structured content and cryptographic signing.

What is canonicalization in DKIM, and why does it matter?

Canonicalization in DKIM defines how email headers and body content are normalized—stripping extra whitespace, standardizing line breaks, and ordering headers—before signing and verification. If the sender and receiver apply different rules during this process, the signature fails, even if the email is otherwise valid. This is especially common with embedded images in multipart/alternative emails, where body canonicalization can differ between systems.

How header and body canonicalization differ

DKIM uses two levels: header and body. Header canonicalization is usually consistent—headers are folded and normalized by removing extra spaces. But body canonicalization is less predictable. The default 'relaxed' mode allows variation: some systems normalize multiple spaces into one, others don’t. When a sender’s mail server does this, but the receiving server doesn’t, the signed body doesn’t match—and the signature fails.

Even though relaxed mode is supposed to be forgiving, the exact handling of line breaks, spaces, and embedded content still matters. For example, if an image is embedded in a text/html part and wrapped in multiple newlines or spaces, the body can change during transit or when passed through a content filter. Unless both ends use the same canonicalization logic, the signature will appear invalid.

Why embedded content causes problems

Embedded images, especially when base64-encoded inline, create long strings of data that are sensitive to whitespace. Even small differences in how line breaks or trailing spaces are handled can alter the body content enough to invalidate the DKIM signature. This is common when using email tools that reformat content automatically or when email clients preprocess HTML.

Most DKIM failures due to embedded content are not about the image itself, but about how the email body was processed before signing. If your email uses a library that alters spacing or rewrites line breaks in the HTML body, and the signing engine doesn’t match that behavior, your signature will fail.

For testing, you can use tools that validate DKIM signatures with real-world headers and body content. MailTester's inbox-placement tester checks how emails land in real mailboxes and verifies DKIM correctness across common inboxes, including those with strict filtering.

The solution isn’t just adjusting your email client’s formatting—it’s ensuring that the signing process matches how receivers normalize the body. Using a trusted verification service to test email delivery and DKIM integrity helps catch these issues before they hit your audience.

DKIM can fail on embedded images in multipart/alternative emails when the signature doesn’t cover the correct MIME parts or when canonicalization alters the content-ID references. To debug, validate the full email structure—especially how embedded images are referenced via Content-ID and included in the signing scope. Tools that examine the full MIME tree, including embedded content, are essential. Once confirmed, test with and without embedded images to isolate the issue.

Start with structural validation

  • Use a tool like MailTester’s inbox placement tester to send a sample email and validate how the full MIME structure is interpreted by receivers—this includes embedded images and their Content-ID references.
  • Verify that the signing process includes all relevant MIME parts, particularly the image/* parts within the multipart/alternative container.
  • Confirm that your signing algorithm uses the same canonicalization (relaxed or simple) as the receiving server expects—some servers use strict rules that reject signatures if whitespace or line-endings differ.

Test and isolate the failure

  • Reconstruct the email without any embedded images and re-sign it. If DKIM now passes, the problem lies in how the image data or its references affect the signed content.
  • Compare the signed parts in both versions—use a MIME parser to check that every part, especially the image content-ID and its location in the email body, is preserved during signing.
  • Check that images are referenced using cid:[email protected] (or similar) and that the corresponding Content-ID header is present in the MIME part. Missing or mismatched headers break the signature.
  • Ensure no third-party services are altering the email body or headers after signing—this includes content filters, email gateways, or auto-optimizers that rewrite inline images.
  • Refer to the official DKIM specification to confirm that all required headers (including Content-ID) are included in the signature and that their values are properly normalized.
Even a single missing or misformatted Content-ID can cause DKIM to fail, especially in multipart/alternative messages where the signing scope must be exact.

Real-time verification: The only way to test DKIM with real email clients

Static DNS checks and tool-based scans miss what actually happens in real inboxes. When you embed images in a multipart/alternative email, the DKIM signature can break during rendering—even if SPF and DMARC pass. Only live testing with actual clients like Gmail, Outlook, and Yahoo reveals whether your DKIM signature survives image embedding in real-world conditions. This is where real-time, inbox-placement testing becomes essential.

Why static checks fall short

DKIM validation happens after the message is processed by an email client. A DNS lookup or syntax checker can confirm your public key is published, but it can't tell you whether the signature breaks when the email is rendered with an embedded image. Many tools assume alignment; they don’t simulate how a client parses MIME boundaries, handles image embedding, or validates signed content across multiple parts.

Even correct SPF and DMARC don’t guarantee DKIM will work. If the embedded image alters the canonicalized body—by changing whitespace, line breaks, or attachment order—the DKIM signature becomes invalid. This kind of break isn’t detectable in a lab environment or with automated syntax checks.

Live testing exposes the real failure

MailTester’s inbox-placement testing sends your email through actual providers, including Gmail, Outlook, and Yahoo, using real inbox environments. This means DKIM is evaluated in context—with images rendered, headers processed, and MIME structures intact. The result? You see if the signature fails due to image embedding, even when all other technical checks pass.

This approach matches what industry standards like RFC 6376 (DKIM) and RFC 5322 (email structure) expect: a signature must remain valid through the full rendering pipeline. Tools that don’t send through live email providers miss these edge cases. According to industry benchmarks, email clients often reject messages with broken DKIM, even if the sender is otherwise compliant.

With MailTester’s inbox placement tool, you can test entire campaigns—and see exactly how they land in real inboxes. It’s not just about syntax; it’s about how your email behaves under real client rules. Test your email live before sending to catch DKIM failures caused by embedded content.

What does MailTester’s real-time verification show about DKIM and embedded images?

MailTester detects DKIM signature failures caused by embedded images in multipart/alternative emails by validating the full message structure—headers, MIME boundaries, Content-ID usage, and body canonicalization—exactly as a real mail server would. Even if an email address is valid and the domain passes basic checks, embedded content can break DKIM unless canonicalized correctly. With 98.9% accuracy, MailTester surfaces these edge cases before they trigger bounces or spam filtering.

How DKIM and embedded content interact in real-world emails

When you embed an image using a Content-ID (like cid:[email protected]) in a multipart/alternative email, the receiving server must reconstruct the message exactly as sent—including how the body is normalized. DKIM signs the entire body after applying canonicalization rules. If the image’s Content-ID is referenced with inconsistent case, malformed CID, or embedded in the wrong part of the MIME tree, the signature won't verify.

Many tools only check if the address is syntactically valid or if the domain has mail servers. They miss how content affects signature validation. MailTester goes further: it parses the full MIME structure and tests whether the DKIM signature remains valid after processing. The signature only passes if both the headers and the body content are replicated exactly—no deviations allowed.

Why most email testers fail to catch this

Tools that skip full-body parsing or don’t simulate canonicalization often report “valid” emails even when embedded images break DKIM. This happens because they don’t verify the signed payload as it’s actually processed. According to RFC 6376, DKIM’s canonicalization process is strict: line folding, whitespace, and encoding must match exactly. A single mismatch invalidates the signature, even if the address is real.

MailTester’s real-time API and bulk verification system apply the same logic. It checks how a message would be treated by a receiving server—down to the byte-level canonicalization—before marking it as valid. That’s why 98.9% of its results align with server-side outcomes in independent testing. RFC 6376 outlines the standard, and MailTester follows it exactly.

Use the bulk email verification tool to catch DKIM issues in high-volume mailing lists, or test a specific message using the inbox placement tester, which simulates real delivery behavior and signals signature mismatches before you send.

How to test your email before sending to avoid DKIM failures

You can catch DKIM signature failures on embedded images in multipart/alternative emails by sending test messages through MailTester’s real-time API. This simulates delivery to Gmail, Outlook, and other major providers, showing you DKIM status, SPF alignment, DMARC policy, and inbox placement — all before you send to your list. Use the full delivery report and the in-app AI assistant to find if embedded images are breaking the signature.

Test your email across real inbox environments

  1. Send a test email using MailTester’s real-time API. This sends your message through the actual email delivery paths used by Gmail, Outlook, and others — not a simulated or sandboxed version. You’re testing what inbox providers see, not what you assume.
  2. Check the DKIM status in the delivery report. If your DKIM signature fails only when images are embedded, it’s likely due to how the MIME structure is processed. Some providers reformat content, especially with images, which can invalidate the DKIM signature if the body hash doesn’t match after rendering.
  3. Verify SPF alignment and DMARC policy. A failing DKIM doesn’t always mean misconfiguration — if SPF alignment fails or DMARC rejects the email, the entire message may be dropped or marked as unverified. These signals are visible in the report.
  4. Check inbox placement. Even if DKIM passes, the email might land in spam. MailTester shows whether your test message reached the inbox, spam, or was blocked — giving you a real-world signal.
  5. Use the in-app AI assistant to scan logs. Paste the full delivery log into the assistant. It will highlight if embedded image handling — such as inline base64 encoding — triggers a DKIM mismatch. The AI helps you isolate whether the issue is in the structure, the content, or the signature itself.

Fix the root cause, not just the symptoms

Embedded images in multipart/alternative emails can cause DKIM issues if they alter the message body in a way that changes the canonicalized content. This is why some tools only report success with text-only versions. Check RFC 6376 for how DKIM signing works on multipart content. The signature validates the body *as sent* — any addition or reordering during delivery breaks it.

MailTester’s Inbox Tester (available via https://mailtester.com/inbox-tester/) is designed to expose these edge cases. You can send a test email with inline images while tracking how each provider renders and signs it. The data helps you decide whether to host images externally, use CID references, or adjust your MIME structure.

Use external image hosting with public URLs instead of embedding images inline via cid: references. This avoids DKIM signature breaks caused by body alterations during delivery. Sign your email with relaxed canonicalization and verify with tools like MailTester to confirm the signature remains valid after rendering.

Core architecture principles

  • Host all images on a CDN or public web server, never embed them as inline base64 or cid: content
  • Reference images using standard <img src='https://your-cdn.com/image.jpg'> tags in the HTML part of your email
  • Ensure the email body structure remains unchanged after transport—no rewrites, no MIME alterations
  • Use relaxed canonicalization (relaxed/relaxed) or no canonicalization in DKIM signing tools to allow body changes during delivery
  • Test your emails across real inboxes using MailTester’s inbox placement tool to verify signature validity and delivery consistency confirm delivery in real inboxes

When inline images are unavoidable

  • If you must embed images inline, configure your signing tool to use relaxed canonicalization and handle cid: content carefully
  • Validate the signed email with a real-world validator like MXToolbox’s DKIM Validator or similar
  • Test every variant of your email before sending—especially multipart/alternative bodies with different MIME structures
  • Use MailTester’s real-time verification API to detect invalid or risky addresses before they trigger delivery issues verify addresses at scale
DKIM signatures are broken when the body is altered—inline images with cid: references are often rewritten or removed during transport, invalidating the signature.

Even minor header or body modifications can break DKIM. The safest path is to avoid inline image embedding entirely. If you need to preserve image integrity, test early, verify often, and ensure signing tools are configured for the real world, not just ideal conditions. Use tools that simulate actual inbox delivery chains—don’t rely on internal test servers.

Common misconfigurations that break DKIM with embedded content

DKIM fails on embedded images in multipart/alternative emails when the signing process doesn’t match how the recipient’s server normalizes the content. If you embed images via Content-ID and base64 encoding without ensuring consistent body normalization across signing and verification, the signature won’t validate. This often happens when the email body is altered during processing—like re-encoding or compressing images after signing—breaking the cryptographic hash. The core issue isn’t the image itself, but how the email body is treated during the signing step. Let’s look at the most common pitfalls.

Signing only the HTML part, ignoring plain text

DKIM signing should apply to the entire message body as it’s received, not just the HTML portion. When you sign only the HTML part of a multipart/alternative message, the verifier sees a mismatch—especially if the plain text part is present in the final delivery. This breaks the alignment required by DKIM. While some older systems tolerate this, modern filters and receivers expect consistent signing across all parts of a multi-part email. For a more reliable and compliant setup, ensure the entire body (including plain text) is signed as a single normalized stream.

Image processing before signing

Many senders use tools to compress or re-encode images before embedding them. But if you sign the email before doing this, the signed content doesn’t match the delivered version. Even small changes to encoding—like base64 padding or whitespace in image data—alter the hash used in the DKIM signature. The signature only validates if the exact body used during signing is preserved through delivery. If your workflow alters image data after signing, the DKIM check fails. RFC 6376 (the DKIM standard) specifies that signing must happen before any content normalization or transformation that affects the message body.

Another frequent oversight is using both Content-ID and inline base64 encoding without aligning how the content is normalized. The receiving server may resolve these differently if the encoding rules aren’t consistent—leading to a mismatch. For example, if one part of an email uses Content-ID with a URL reference and another uses embedded base64, the order of processing can change the final body. Your signing tool must account for this. Testing your full email pipeline—especially before and after image handling—is essential.

You can use tools like inbox placement testing to simulate how your emails are received and processed. This helps catch DKIM validation issues before they affect deliverability. For developers, validating your signing logic against real-world email receivers is critical.

Why relying only on DNS or SPF checks won’t catch this issue

You can pass SPF and DNS checks while still having a DKIM signature fail on embedded images in multipart/alternative emails—because SPF only validates sender identity, not message content. A clean DNS lookup or passing SPF doesn’t guarantee that the DKIM signature properly covers the full MIME structure, especially when images are embedded in the HTML part and the signature is misaligned. You need real inbox testing to catch this.

SPF Doesn’t Look at Content or Structure

SPF checks the envelope sender (Return-Path) against the sending server’s IP. It says nothing about how the email body is formatted or whether embedded images are correctly signed. A legitimate sender with valid SPF can still send a message where the DKIM signature fails because the signer did not include the HTML part with the image in the signature scope.

DKIM Is Independent—And Easily Misconfigured

DKIM, unlike SPF, signs parts of the email body and headers. But it’s not automatically enforced by SPF or DMARC. Even if your DMARC policy is set to "fail" and your SPF is valid, a missing or incorrect DKIM signature on the embedded image can still let the email through—only to get rejected later by receiving mail servers.

According to the IETF’s RFC 6376, DKIM signing must cover the entire content that should be trusted. If an image is embedded in the HTML part but not included in the signature scope, the signature is effectively broken. This is common in poorly configured email templates or when tools insert media without updating the signature.

Testing your email in real inboxes—before sending to your entire list—is the only way to catch these structural failures. Automated tools that only check DNS or SPF miss the full MIME context. That’s why MailTester’s inbox placement testing includes real-world validation of how your email renders across providers like Gmail, Outlook, and Apple Mail, ensuring the DKIM signature holds across all parts of the message.

Run a test to see how your email performs in actual inboxes: test your email’s deliverability and DKIM integrity in live environments.

Final takeaway: DKIM fails not because of the image, but because of how it’s handled

Embedded images in multipart/alternative emails don’t inherently break DKIM. The failure stems from differences in how the email body is normalized during signing versus verification.

Even with correct SPF, DKIM, and DMARC configurations, a signed email can fail validation if the signing tool and receiving server apply different normalization rules—especially around line endings, whitespace, or encoding of content.

Why full-email testing matters

  • DKIM verification must be tested across multiple receivers, not just one.
  • Only real-world inbox placement testing reveals whether the signature survives routing and server transformations.
  • Verifying the full content flow—including embedded images—ensures your email remains valid, even when servers modify the message in transit.

Sources

Keep reading

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

Frequently asked questions

Can DKIM fail if I embed an image in my email?

Yes, if the signing process and the receiver's verification disagree on the canonical form of the body, even small changes like embedded images can invalidate the signature.

Does using cid: references break DKIM?

Not inherently. But if the signing tool and receiving server apply different canonicalization rules, the signature may fail despite correct setup.

How can I test if my DKIM signature works with embedded images?

Use a real-time inbox-placement testing service like MailTester to send a test email with embedded images and review DKIM status in actual inbox providers.

What’s the difference between embedded images and linked images in DKIM signing?

Embedded images (cid:) require the signing tool to account for MIME structure. Linked images (via URL) are less likely to disrupt body canonicalization.

Does using a CDN help avoid DKIM failures?

Yes, serving images externally reduces reliance on MIME body integrity and helps maintain consistent DKIM signatures.

Can MailTester detect DKIM failures caused by image embedding?

Yes, MailTester’s real-time inbox testing simulates actual delivery and flags DKIM mismatches caused by embedded image handling.

Why does DKIM pass in testing tools but fail in Gmail?

Testing tools often simulate only DNS or basic header checks. They don’t reproduce how Gmail re-canonicalizes content, especially with embedded images.

Does using multipart/alternative affect DKIM signing?

Yes — DKIM signs the body after canonicalization, which must be consistent across all parts. Discrepancies in how the parts are processed can break the signature.

What are common DKIM canonicalization settings?

The two main modes are 'simple' and 'relaxed'. Relaxed mode normalizes whitespace and line breaks, but differences in implementation can lead to failures.

Do role accounts or disposable domains affect DKIM validity?

No, DKIM validity depends on domain setup and content canonicalization — not on the recipient’s email type.

What happens if DKIM fails due to embedded images?

The email may be marked as unverified or rejected by receiving servers. It can reduce inbox placement and damage sender reputation.

How often should I test my DKIM setup with embedded content?

Test every major email launch or change to email templates, especially when embedding images or modifying MIME structure.