Convert Email to XML: Turn Messages Into Structured XML Data

Last updated July 2026

Most people who search for a way to convert email to XML are not trying to archive a mailbox. They have a system on the other end, often an ERP, an EDI gateway, or something written before JSON won, and it expects an XML document with a defined structure. The email is just the delivery mechanism for an order, an invoice, or a notification. This guide covers what "convert email to XML" actually means, how to do it reliably, and where teams get burned.

How do I convert an email to XML?

Convert an email to XML in two steps: extract the values you care about into named fields, then serialize those fields into an XML document that matches your target schema. Do not try to convert the raw .eml file directly. An .eml is a MIME envelope full of headers, encodings, and nested parts, so a mechanical conversion gives you XML that is technically valid and practically useless.

What does "email to XML" really mean?

There are two very different jobs hiding behind the same phrase, and picking the wrong one wastes a day.

If a downstream system is going to read the file, you want the second job. Almost everyone does.

Why convert email to XML instead of JSON or CSV?

Because something downstream demands it. XML still runs a lot of business plumbing: purchase order and invoice exchange formats like cXML and UBL, EDI translators, older ERP and WMS connectors, government and healthcare filings, and any integration built before roughly 2012. XML carries namespaces, attributes, and schema validation, which those systems rely on. If nothing on your side needs those, JSON is the easier target.

Step by step: from inbox to XML

1. Decide the target structure first. Get the XSD or a sample document from whoever receives the file. Building the extraction before you know the schema means renaming everything later.

2. Name the fields you need. Not "the body", but order_number, po_number, vendor, line_total, currency, ship_date. Each becomes an element.

3. Parse the email, including attachments. A lot of order and invoice detail lives in a PDF or CSV attachment rather than the message body, so the parser has to read inside those too, along with any HTML table.

4. Serialize to XML and validate. Take the structured output and write it into your schema, then validate against the XSD before you send anything.

Does MailParse export XML directly?

No. MailParse exports Excel, CSV, and JSON. That is an honest limitation and, for this job, a small one, because the difficult work is extraction rather than serialization. Once you have typed fields as JSON, producing XML in the exact shape a partner requires is a short, testable function you control, and you keep control of namespaces and element ordering that a generic exporter would guess at.

Here is the whole conversion, using the email parser API output as the input:

import xml.etree.ElementTree as ET

parsed = {
    "order_number": "SO-44127",
    "po_number": "PO-9931",
    "vendor": "Acme Supply Co",
    "ship_date": "2026-08-14",
    "total": "1284.50",
    "currency": "USD",
}

root = ET.Element("PurchaseOrder", {"version": "1.0"})
for key, value in parsed.items():
    ET.SubElement(root, key).text = value

ET.ElementTree(root).write("order.xml", encoding="utf-8", xml_declaration=True)

That produces a clean document with a declaration, UTF-8 encoding, and one element per named field. Swap the element names to match your schema and you are done. Teams that exchange a high volume of these documents usually stop hand rolling the mapping and move to a proper purchase order management system that speaks the format natively, but for a handful of trading partners the script above is genuinely enough.

What XML structure should I use?

Whatever the receiving system publishes. Do not invent one. If you are exchanging purchase orders, cXML and UBL are the two common standards and both are well documented. If you are feeding an in house system, ask for a sample file and copy it exactly, including whether values live in elements or attributes. Getting this from the receiver up front saves a rejection cycle.

Common pitfalls when converting email to XML

Unescaped characters break the document. An ampersand or an angle bracket in a company name will produce invalid XML if you are concatenating strings. Use a real XML library, which escapes for you, rather than string formatting.

Encoding mismatches mangle names. Email arrives in all sorts of encodings. Normalize everything to UTF-8 at the parse step and declare it in the XML header, or accented characters in customer names come out as noise.

Repeating rows get flattened. An order email with five line items should produce five child elements, not one cell of concatenated text. This is the single most common failure, and it is why parsing HTML tables into separate rows matters more than it sounds.

Numbers and dates arrive as prose. "$1,284.50" and "August 14th" are strings. Decide the canonical types once, at extraction, and format on output, or downstream validation will reject the file.

Can I convert an .eml file to XML?

You can, but ask why first. A raw .eml holds MIME headers, transfer encodings, and nested parts, so a direct conversion yields a large document that describes an email rather than the order inside it. If the goal is archival, that is fine. If the goal is loading data into a system, extract the fields and serialize those instead. The same logic applies when converting an EML file to CSV.

Where to go next

Start by getting clean structured output from your email, then serialize it. See email to JSON for the format most teams settle on, the email parser API for calling it from your own code, and extract order data from email if purchase orders and confirmations are what you are converting.