MIME headers checker: Content-Type, boundary and encoding
In short: Paste a test email, headers and body. The tool checks MIME-Version, Content-Type and its boundary, the transfer encoding, and the order and closing line of a multipart/alternative body. Limit: It checks the top-level headers and the first level of parts, not nested multipart bodies.
Paste the whole test email, headers and body. The tool checks MIME-Version: 1.0, the Content-Type and its multipart boundary (1 to 70 allowed characters), the Content-Transfer-Encoding, non-ASCII text in a 7bit body, lines over 998 octets, the order of the parts in multipart/alternative and the closing boundary line, against RFC 2045 and RFC 2046.
Price: this tool is free. Checking a whole email list is from $9/mo, and the first 100 checks are free with Google, no card. Check your list free nowSee pricing
Sample result
The example message has two parts, plain text first and HTML second, closed by its boundary.
- Problems
- 0
- Content-Type
- multipart/alternative
- Parts found
- 2
What this means for you
That is the order RFC 2046 expects in multipart/alternative.
- MIME-Version: 1.0
- Boundary length and characters
- 7bit and line length
- Part order and closing line
- MIME
- RFC 2045
- Boundary
By SimpleVerifier Team · Last updated · Runs in your browser; nothing you paste is sent to us
A well-formed message still needs a clean list.
- When the message structure is right, clean the list you are about to send to.
- Upload or paste it at /verify. Every address gets a live mailbox check, and the first 100 email checks are free with a Google sign-in, no card.
How do I check an email's MIME structure?
- Send a test email to a mailbox you own and open it as raw source (in Gmail, Show original).
- Paste the whole message in, headers and body. Headers alone also work, with fewer checks.
- Read the Content-Type, the encoding and the list of parts the tool found.
- Fix the template or sending settings behind any problem, such as an HTML part placed before the plain-text part or a missing closing boundary.
Example
- You enter
- A message with MIME-Version: 1.0 and multipart/alternative with boundary sv-boundary-1, a text/plain part, then a text/html part.
- You get
- Content-Type multipart/alternative, 2 parts found and closed by --sv-boundary-1--, no problems. The plain-text part comes before the HTML part, the order RFC 2046 expects.
- Limits
- Runs in your browser; nothing is uploaded.
What must the MIME headers contain?
RFC 2045 says a message using MIME carries MIME-Version: 1.0 at the top level. Without a Content-Type, readers assume text/plain with charset us-ascii. Content-Transfer-Encoding is 7bit, 8bit, binary, quoted-printable, base64 or an extension token, and defaults to 7bit. Multipart and message types may only use 7bit, 8bit or binary at their own level; encoding goes on the parts inside.
What are the boundary rules?
RFC 2046 says a multipart boundary is 1 to 70 characters from a limited set (letters, digits and ' ( ) + _ , - . / : = ? and space) and does not end in a space. Each part starts with a line of two hyphens and the boundary, and the last line adds two more hyphens after it. A body that never writes that closing line is malformed.
Why does the order of parts matter?
In multipart/alternative the parts are the same content in different formats, listed in increasing order of preference, so the preferred format comes last. Putting the HTML part before the plain-text part means a reader that follows the standard shows the plain text. The tool warns when the order is reversed. The quoted-printable decoder reads the encoded parts.
Who uses this tool, and for what?
- Cold email senders
- Check that a plain-text and HTML version are in the order readers expect.
- Deliverability consultants
- Find a broken boundary or wrong encoding in a client's template.
- Sales ops
- Confirm accented names survive in a message built by a mail merge.
What can’t this tool tell you?
- It checks the top-level headers and the first level of parts, not nested multipart bodies.
- It checks the standards; it does not predict how a mailbox provider treats a message.
- A body pasted through a form may lose its original line endings.
- The tool follows RFC 2045 and RFC 2046 as written; later updates are not included.
Common questions
- Do I need to paste the body?
- No. Headers alone are checked, but the parts, their order and the closing boundary need the body.
- Why is non-ASCII text in a 7bit body an error?
- RFC 2045 says 7bit data has no octets above 127. Use quoted-printable, base64 or 8bit for accented text.
- What line length is allowed?
- RFC 2045 describes 7bit data as lines of 998 octets or less, and the tool flags longer lines in 7bit and 8bit bodies.
- Can a multipart message be base64 encoded?
- No. RFC 2045 allows only 7bit, 8bit or binary for multipart and message types; encode the parts inside.
- Does it read nested multipart messages?
- It checks the top level and lists its parts, but it does not open parts that are themselves multipart.
- Is my email sent anywhere?
- No. It is read in your browser.
Sources
A tidy list can still be full of dead addresses.
Extracting, deduplicating and syntax checks all work on the text of an address. None of them can tell whether the mailbox exists. Only the server that hosts it can answer that, through an SMTP check, and that is what the paid product does.
- Upload the cleaned file as it is: CSVs up to 100,000 rows
- A real SMTP mailbox check on every row, with catch-all detection
- Small list? Starter at $9/mo covers 2,500 emails a month, cancel anytime
Plans from $9 a month, cancel anytime, no contract. Sign in with Google and your first 100 email checks are free, no card. The free tools stay free either way.