Build the email once. Reuse it through every send.

It's the email itself — the reusable template that holds subject, body, personalization, attachments, and settings. The send is configured separately. A Scheduled Campaign picks a broadcast and chooses the audience + send time. A Trigger picks a broadcast as its action. A Drip step references a broadcast as its content. One email, many delivery paths.

Whichever fits how you compose. The HTML editor (ships with core) is for developers and marketers comfortable with markup. The Drag & Drop Builder (addon) is for visual designers who'd rather drag blocks than write code. Both render the same email at send time — the editor is a workflow preference, not a capability gate.

It's a chat agent inside both editors. Open the AI sidebar, tell it what you want — 'design a newsletter for my coffee subscription company offering 20% off in October' — and it drafts the email end to end. Ask it to refine: 'add a paragraph about free shipping', 'change the CTA to red', 'make this more urgent'. It edits in place. Three quality tiers (Mumara AI Fast / Mumara AI / Mumara AI Advanced) trade speed for output quality. Credit-based — each chat consumes credits from your account balance.

Yes — that's the headline use case. Give it a prompt, get a complete email back: subject, preheader, body, hero image search tag, CTA, footer. It uses Mumara's personalization tags correctly (%%first_name%%, %%unsubscribelink%%) and won't invent things it can't verify — no fake logos, no made-up prices, no fictional coupon codes. You provide the facts; the AI provides the writing.

Yes, three ways. Merge tags (%%first_name%%) substitute subscriber data. Spintax ({{tag}}) rotates between variants you write for the same broadcast. Dynamic content tags ([[block]]) show or hide entire blocks based on subscriber data — and can also fetch live content from RSS feeds with the RSS Feed addon. Combine them in the same email — the editor has a searchable Variable Picker organized by category.

Yes — via Dynamic Content Tags configured with a feed URL. RSS 2.0, Atom, JSON Feed, and Media RSS are all supported. The tag's HTML template uses ___title#1___, ___link#2___ iteration syntax to render multiple items in one email, with per-variable parameters (char=200, images=none, style=none) for cleanup. RSS-fetching specifically requires the RSS Feed addon; the base DCT mechanism for conditional content is core. See the pricing page for current addon pricing.

Yes — toggle Responsive Email on and Mumara injects viewport tags, CSS resets, dark-mode support, and client-specific fixes for Outlook, Gmail, Yahoo, Apple Mail, and Samsung Mail automatically. No hand-coding per client.

Subject line for spam triggers, content structure, image-to-text balance, compliance elements (unsubscribe link, List-Unsubscribe header, sender authentication), and known trigger words in the body. It runs client-side before send and gives you specific suggestions — not generic warnings — for what to fix. Re-scan after edits to confirm.

Yes. Drag-and-drop attachments into the editor. Mumara warns about size and spam-filter risk — large attachments slow sends and can trigger filters, so linking to hosted files is often the better move. But the option's there for invoices, receipts, calendar invites.

Edits affect future sends only. If the broadcast is used in a scheduled campaign that hasn't run yet, your changes apply when it sends. Past sends are unaffected — what landed in inboxes stays as it was.

Yes — that's the whole point of treating broadcasts as reusable content. The same broadcast can be sent by a scheduled campaign on Monday, a trigger on Tuesday, and a drip step on Wednesday. Update the broadcast once and every future send picks up the change.