Foundation for Emails
Responsive email framework with Inky markup and Sass tooling.
Foundation for Emails is a ZURB responsive HTML email framework. It provides a grid, common email UI patterns, Inky markup, Sass variables, templates, and an inliner workflow for teams that want production-ready HTML without hand-writing every table.
The question here is which one a backend engineer would rather operate. That means SDK depth in the language already in use, whether a retry can safely be replayed, how much the event log tells you when a customer says the email never arrived, and whether the pricing curve stays sane as volume grows.
Against password resets, receipts, and magic links shipped from application code, Foundation for Emails covers developer experience, and does not cover SDK breadth, idempotency keys, event stream, and webhook coverage. Whether that gap matters depends on how central those are to the build.
- DX score: 7/10
- SDKs: None
- Idempotency keys: No
- Operating since: Not published
- Event stream: No
- Best published rate per 1,000: Tiers not published in comparable form
- Webhooks: No
- Deliverability: Not applicable; template framework only.
- Free tier: Free, MIT-licensed
Not applicable; template framework only.
Teams that want a mature, vendor-neutral responsive email framework.
React teams that want templates to share app component conventions.
- › Email-specific grid, components, templates, and inlining workflow
- › Designed for Outlook and major email-client compatibility
- › MIT-licensed and vendor-neutral
- › Older workflow assumes Node and Sass build tooling
- › Inky syntax is another template layer to learn
- › Less fashionable than React Email or Tailwind-based Maizzle in modern web teams
Features at a glance
| API | No |
| SMTP | No |
| SDKs | None |
| Webhooks | No |
| Templates | rich |
| React Email | No |
| Batch send | No |
| Scheduled send | No |
| Suppressions | No |
| Multi-tenant | No |
| Inbound parsing | No |
| Event stream | No |
| Idempotency keys | No |
| Dedicated IP | No |