Skip to main content

Error: "400 Bad Request" for Individual Mail Items in Google Workspace Migrations

This article explains how to diagnose and handle the "400 Bad Request" error reported for individual email messages when migrating to Google Workspace.

1. Symptom

During a migration to Google Workspace, you notice that some individual email messages fail to import. You can see these failures by navigating to Progress > Import Failures in the CloudM Migrate interface or by reviewing the Import Failures HTML report after the migration is complete.

The specific error associated with these failed items is 400 Bad Request.

Note: If an entire user's migration fails with a "400 Bad Request" error, this may indicate a different problem (like an API or authentication issue). In that case, please contact CloudM support. This article addresses item-level failures only.

2. Cause

A 400 Bad Request error is a generic error from Google's Gmail API, indicating that the data sent by CloudM Migrate was rejected. Google rejects messages that do not meet its import standards. The most common reasons for this are:

  • Blocked File Attachments: The email contains an attachment type that Google considers a security risk. For a complete list of blocked file types, please see Google's official documentation: Blocked file types in Gmail.

  • Virus Detected: The email or one of its attachments contains a virus. Gmail's security scanners will automatically reject such messages.

  • RFC 822/2822 Non-Compliance: The email's formatting does not adhere to the fundamental internet standards for email messages (RFC 822/2822). This can happen with very old, malformed, or custom-generated emails.

3. Resolution

As this error indicates that Google is actively refusing to accept the specific mail item, there is typically no way to force the item into Gmail. The item must be skipped.

However, you can take the following steps:

  1. Acknowledge and Report: The primary action is to acknowledge that these specific items cannot be migrated due to Google's policies. You can export the list of failed items from the migration reports to inform end-users if necessary.

  2. Attempt a Retry (for potential temporary errors): In very rare cases, this error can be a temporary issue on Google's side. You can attempt to remigrate the failed items for the user. If the error was transient, the item might be accepted on the next attempt. If it fails again with the same error, the cause is likely permanent.

4. Important Considerations

Impact on Migration Speed:

The presence of many 400 Bad Request errors can slow down your overall migration. CloudM Migrate will attempt to retry each failed message based on the settings you have configured.

This setting is found in your project configuration under: Configuration > Destination Settings >  Transfer and Performance Settings > Retry Count

Each retry attempt on an item that Google will never accept adds to the total migration time. If you encounter a large number of these errors, consider reducing the retry count for subsequent users to improve throughput.

Was this article helpful?
2 out of 3 found this helpful