Practical Email Client Support Limits

This is where an email product stops being about perfect rendering everywhere and starts being about choosing a realistic support boundary. Podia used Litmus as a decision tool, not just a bug finder. By pasting compiled HTML into Litmus and checking screenshots across clients, the team could see which breakages were fixable with CSS or table layout changes, and which came from very old clients whose limits were too severe to justify more work.

• The practical cutoff was driven by workflow and economics. Litmus counts each client and device screenshot as a separate preview, and Podia was on a plan with 1,000 previews per month, so testing every obscure environment quickly became expensive. That pushed the team to narrow its target list to modern clients plus key Outlook versions.
  1 sacra 5 litmus 6 litmus
• The technical cutoff was driven by what email clients actually allow. Podia wrote simple HTML and CSS, ran it through Roadie to inline styles, checked support in Can I Email, and downgraded features when needed, for example using PNGs instead of SVGs. Once a client still failed after those concessions, it moved into the unsupported bucket.
  1 sacra 4 caniemail 7 techradar
• This is a common split in the email tools market. Litmus is strongest as a preview and QA layer, while tools like Parcel are built more for composing and iterating on code. Teams often use Litmus for transactional or product emails where broad client testing matters, but avoid chasing full compatibility in fringe clients like Lotus Notes.
  2 sacra 8 sacra 9 sacra 10 sacra

The long term direction is toward narrower support matrices and more standardized components. As creator platforms like Podia bundle email into a broader product, the winning approach is not supporting every inbox on earth. It is making the main templates reliable in the clients customers actually use, then building the editor so every future email inherits those constraints by default.