Do I have to expect any problems on the recipientsʼ side if I started sending single-part emails as Content-Type: text/markdown; charset=UTF-8; according to RFCs 7763 and 7764? I believe it should fall back safely to the default text/plain.

There are several ways email clients can support Markdown/Commonmark or related languages. I'm talking about transmission and the resulting display here.


  • Convert asterisks, underscores etc. the user inputs with their keyboard to HTML tags (or, in theory, any other rich text format) and send the email as a multipart message with text/plain and text/html.
  • Like above, but also offer GUI buttons or keyboard shortcuts (e.g. foo + CtrlI_foo_) to aid the input of these formats. This is basically a rich text editor that generates a better plain-text fallback than most do currently.

Both of these can use no, inline, side-by-side or before-submission previews of the rendered text.

This is what plugins like Markdown Here can do and some (web)mail clients support natively, e.g. Airmail, Mail Mate, Mailspring, Gmelius, Cypht. Some newsletter, admin, ticket or shop systems that send out emails themselves can also handle markdown input in this way.


  • Send single-part messages as text/markdown instead of the standard text/plain, relying on graceful fallback to the latter. This is what I'm asking about!
  • Send multi-part messages with text/markdown instead of text/html, basically duplicating the text/plain message body.
  • Send multi-part messages with generated text/html and text/markdown instead of the usual text/plain basic version.

Mail Mate and Groups.io may add a header parameter like this:



  • Display received single-part mails that have the appropriate text/markdown header set as plain text, as if it were text/plain. This is the expected graceful fallback.
  • Display received single-part or multi-part mails that have the Content-Type header set with a text/markdown type or markup=markdown parameter as rich text with the formatting characters removed.
  • Display received single-part mails that pass some heuristics to determine they were written according to Markdown or some other LML conventions as rich text with the formatting characters possibly being kept.

Many clients, e.g. Apple Mail, support rich text rendering of a single Markdown feature: block quotations with (possibly nested) > at the beginning of the line.


Markdown has been implemented in various ways and flavors. Wikipedia lists Standard, CommonMark, GFM and Markdown Extra, but each implementation of even the same standard may give different results for the same markdown text (example).

In spite of the new RFCs, there is no official standard type for email, but text/markdown seems to be the most common de facto type. Most browsers and other reasonably sophisticated clients will likely see the text/ part and default to text/plain anyway, so there's not much difference as regarding email.

If you take a look at the Markdown Implementations list, you will see that not even one email client or server is included in it.

There are websites that will convert your markdown to HTML and send the email for you, for example the commercial Gmelius, and PHP also has some markdown modules, but converters is the most you may expect.

According to comments by @grawity, among the email clients he tested, only Thunderbird passed it on as Raw data to be displayed. The others have simply lumped the Markdown inside an attachment. This means that only Thunderbird paid attention to the text/ part in Content-Type, while the others only treated the entire MIME specification, which to them was unknown since they don't understand Markdown.

I don't really think that as things stand today using Markdown is a good idea, as the wave of markdown incorporation has not reached the email clients and may never do. In any case, according to the w3.org link above, no email client handles it correctly, so there's really no point it.

  • Please see the comment by @grawity at my answer. Apparently, most mail clients will not fall back to text mode, but rather show the markdown as attachment. – Berend Sep 26 '18 at 14:46
  • You are actually just stating my concerns: it should fall back gracefully, but does it really? I donʼt (yet) expect (m)any clients to convert the markdown code to rich text formatting. – Crissov Sep 26 '18 at 15:31
  • I have been trying gently to pass on the message that the subject is in evolution, but not recommended at the moment. – harrymc Sep 26 '18 at 15:54
  • 1
    The subject isn't really Markdown -- it's the mail clients' MIME handling in general. If a client supported text/* fallback ("...otherwise will fall back to text mode because of the text/ part"), then it would have supported it regardless of Markdown: it would have done the same with text/rtf, text/enriched, text/futhark. – user1686 Sep 26 '18 at 16:01
  • @grawity: My guess is that a strict email client that only handles known content-types will lump them in an attachment as-is. Thunderbird may be the only client that you tested that intelligently looks at the text/ part and decides the contents can be good enough to display. – harrymc Sep 26 '18 at 17:13

If the mail has to be single-part, then it can't fallback to text/plain, because there is only the markdown part. You'd be entirely dependent on the markdown support of the recipient's mail client. For multipart messages that contain both text/markdown and text/plain, I guess it might work. Have you actually tried this?

I'm not sure what the current support for Markdown is in mail clients, but I have a gut feeling it's not widely accepted yet. Apart from this rather old page, I can't really find anything.

I just tried to open this message in Outlook (saved as an .eml file); it shows as an empty message with a text attachment:

From: John Doe <example@example.com>
MIME-Version: 1.0
Content-Type: text/markdown

# this is the body text
  • 2
    I think the OP meant a different kind of fallback -- not multipart, but simple fallback to showing the contents (source code) without any interpretation when the specific subtype is unrecognized. For example, if a client which doesn't support HTML receives a text/html-only message, it will usually show it anyway (as raw HTML tags). – user1686 Sep 26 '18 at 14:33
  • @grawity Yes that occurred to me too, but we can't be sure. Outlook at least doesn't do this. – Berend Sep 26 '18 at 14:35
  • 1
    (Quick experiment results: Thunderbird is the only program which renders text/markdown as raw source; most other clients show it as an attachment.) – user1686 Sep 26 '18 at 14:42
  • @grawity Yes, this is exactly what I was afraid of. It should fall back gracefully, but in some / many clients it wonʼt. After all, Iʼm composing my pain text emails with markdown formatting already, just send as text/plain. I donʼt want to have them converted to HTML on my side and send as text/html. – Crissov Sep 26 '18 at 15:23

Your Answer

