The practical problem is striking a balance between good experience for cooperating receiving party yet not being entirely broken for non-cooperating parties. Remember that emails may be retained for many years, read via multiple programs, and forwarded to other people.
Currently I believe TeX for Gmail does this best — notably it lets you to render plain text formulas like $2^n$ or even (heuristically) 2^n in incoming mail which is great during back-and-forth with a person using other software.
Markdown Here is not as flexible math-wise but also does other markdown formatting and works in many more places.
This form on Murray Bourne's IntMath site requires you to send from it instead of your regular mail client, and uses ASCIIMathML instead of TeX notation (easier but but has the nice feature of letting the recipient view the mail in a browser - and reply there.
On a technical level, the only way to display wide range of formulas to any client (except pure-text ones) seems to be PNG images. Doing it right ought to include:
alt text fallback.- embedding image in mail so it's self-contained and doesn't depend on external servers. data URIs have bad support, multipart with
cid: much better (see comments there).
- using high-resolution image that doesn't look horrible on high-DPI screen.
- setting height, width and vertical-align in
ex units. This should be able to match size and baseline to surrounding text.
Getting all of the above to work accross clients is tricky... For example see Markdown Here's troubles.
There are multiple better ways to render math than PNG. The problem with all of them is how to fall back to image (or even text) when they don't work?
Some simple subset of math can be rendered well with unicode+HTML+CSS. Indeed TeX for Gmail has such a mode. KaTeX raised the bar for high-quality pure CSS rendering, except it relies on webfonts which don't work in almost mail client. MathJax 2.5 has has a "CommonHTML" mode which currently uses CSS+HTML without even webfonts, but it looks ugly (they plan to start using webfonts to make prettier)...
In any case, CSS in email clients is way behind browsers and horrifyingly uneven, so complex math layouts won't work.
MathML is great and semantically the Right Thing and even works in some clients; alas fallback to images seems hard. Of the official fallback mechanisms, even Chrome only got half in 2014 (thanks Fred Wand), so what can one expect from email clients?
OK MathML is complex and niche format, but surely SVG ought to be a no-brainer after ~15 years in existence? Alas, email SVG support is very sad (e.g. gmail recently dropped all support, not even alt text), and the known javascript-free fallback techniques don't work on email. (I don't consider testing for screen resolution == iPhone|iPad an acceptable technique...)
The cleanest fallback techniques rely on clients ignoring tags they don't understand; alas quiet a few (web)mail clients only accept a whitelist of tags and completely drop things like <math>...<img .../>...</math> instead of rendering the img...
As for doing these without fallback, so recipient can't read math at all without the right tool — it's a tough call (compared to PNG which is uglier but works) but maybe acceptable to you.
[Actually there is always the option to include text/plain fallback. Not all receiving clients expose it, and starting the mail with "Can't see math? Look for "Show original" in your email client" would be a lousy experience...
However what the IntMath system does with "click here to read (and reply) as a web page" is very good.]
