Skip to content
Mumara

Content · conditional · rule-based

One block. Many audiences. Branching content inside the email body.

Dynamic Content Tags branch content per recipient. [[pricing-block]] resolves to one block for free-tier, another for pro, another for enterprise. Two modes: saved DCTs with reusable rule sets, and inline [if:field=value]…[endif] conditionals. The branching layer between Spintax (rotation) and Custom Fields (substitution).

Get started See full personalization stack →
  • Saved DCTs — [[tag-name]] with reusable rule sets
  • Inline conditionals — [if:field=value]…[endif] with [elseif:]
  • List-membership — [ifmemberof:"List"]
  • Multi-unit content — first-match or combined return mode
[[pricing-block]]
[[pricing-block]]
3 content units · AND-logic rules
return mode: first match
resolves per recipient
plan_tier = "free" unit 1

Upgrade to Pro and unlock unlimited sends →

plan_tier = "pro" unit 2

You're saving $40/mo on Pro. Refer a friend for credits →

plan_tier = "enterprise" unit 3

Your account manager has a Q3 review for you →

Two modes

Saved tags for reuse. Inline conditionals for quick checks.

DCTs come in two shapes. Saved [[tag]] DCTs are reusable rule sets — define once at Campaigns → Dynamic Content Tags, reference across any campaign. Inline conditionals are written directly in the email body — quick field checks without a separate definition.

Reusable · rule sets · Content Units

Saved DCTs · [[tag-name]]

Created at Campaigns → Dynamic Content Tags → Add New. Pick a tag name (lowercase alphanumeric + hyphens), define Content Units (each unit has its own rule set + content body), set return mode (first match or combined output). Reference as [[tag-name]] from any broadcast or drip. Update the rules once; every campaign using the tag inherits the change. Same lock-the-name immutability as Custom Fields and Spintax.

  • Reusable across campaigns
  • Multiple Content Units per tag
  • First-match or combined return mode
  • AND-logic across multiple rules per unit

Direct · field-level · no definition

Inline conditionals · [if:field=value]…[endif]

Write the condition right into the email body. [if:first_name]Hello %%first_name%%[else]Hello there[endif]. Operators: = (equals), == (equals alt), != (not equal), > (greater), < (less). Chain with [elseif:]. Check list membership with [ifmemberof:"List Name"]…[endif]. No separate tag definition needed — best for quick field checks that don't justify a saved DCT.

  • Inline syntax — no separate definition
  • [elseif:] chaining for sequential checks
  • [ifmemberof:] list-membership checks
  • Field-value operators (=, !=, >, <)

Three powers in one syntax

What [[tag]] can resolve into.

A single saved DCT can serve any of three roles depending on how you configure its Content Units. Pick the right mode for the job, or mix them inside one tag.

Conditional content blocks

The most common use. Define multiple Content Units, each with its own rule set (plan_tier=Pro AND country=US, signup_source=referral, last_purchase>30 days, etc.). At send time the platform evaluates the rules per recipient and returns matching content. One tag, every audience.

RSS feed integration · addon

Configure a DCT to fetch from an RSS / Atom / JSON Feed / Media RSS source. Use triple-underscore syntax (___title___, ___link#1___, ___content:encoded#2___) to render feed items into the email body. Parameters like {char=300;images=none;style=none} sanitise feed HTML. Requires the RSS Feed addon.

Multi-Unit content sequencing

Set return mode to 'combined output' and a DCT can return SEVERAL matching units stacked together — useful for accumulating per-recipient sections (Pro perks + Referral perks + Q3 review). AND-logic within a unit, OR-logic across units when combining.

Inline conditional patterns

Inline checks. Write them right where you need them.

Inline conditionals are the lightest form of DCT — no separate definition, no Content Units, just a check directly in the email body. The platform supports field-existence, field-equality, comparison, chaining, and list-membership checks. Every pattern below renders inline in any broadcast / drip / dynamic content body.

Field-existence check

If the field has a value, use it. Otherwise, fallback.

# Personalized greeting with fallback
[if:first_name]Hello %%first_name%%[else]Hello there[endif]

# Conditional content only when present
[if:company]You work at %%company%%[endif]

The most common pattern. [if:field] checks whether the field has any value for the recipient. Add [else] for a fallback when empty. Pair with %%field%% inside the block to substitute the value when it exists.

Field-equality check

Branch on a specific field value.

# Region-specific shipping offer
[if:country=Canada]Free shipping across Canada![endif]

# Plan-specific CTA
[if:plan=enterprise]Contact your account manager[else]Visit our pricing page[endif]

# Empty-field check
[if:phone=]Please update your phone number[endif]

Operators: = / == equals, != not-equals, > / < numeric compare. Use field= with empty RHS to test for empty values — useful for data-completion prompts.

Sequential elseif chaining

Three-way (or more) branches inline.

# Tiered membership messaging
[if:membership=gold]Welcome, Gold Member!
[elseif:membership=silver]Welcome, Silver Member!
[else]Join our membership programme!
[endif]

# Loyalty-points cascade
[if:loyalty_points>1000]You're at platinum tier
[elseif:loyalty_points>500]You're at gold tier
[else]Earn more to unlock rewards
[endif]

[elseif:condition] evaluates top-to-bottom; the first matching branch wins. Numeric comparisons (>, <) work with Numeric Custom Fields. Cleaner than nesting multiple [if:] blocks for n-way splits.

List-membership check

Show content only to members of specific lists.

# Single-list check
[ifmemberof:"Newsletter Subscribers"]
  Thank you for subscribing!
[endif]

# Multi-list OR check
[ifmemberof:"VIP Customers","Premium Members"]
  Exclusive offer inside!
[endif]

[ifmemberof:"List Name"] checks whether the recipient is a member of the named list. Pass multiple comma-separated list names for OR-logic membership (any one matches). Useful for shared content across audience cohorts without needing a custom field to encode the cohort.

Content Units + return modes

Why DCTs have units, and what 'first match' vs 'combined' actually means.

A saved DCT isn't one block of content with a rule — it's a list of Content Units, each one a (rules, content) pair. The DCT decides what to return when evaluating against a recipient based on the return mode you configure.

Inside the tag, you add as many Content Units as you need. Each unit has its own rule set (one or more rules combined with AND-logic) and its own content body. A typical pricing-block DCT has three units: one for free-tier, one for pro, one for enterprise — each unit's rule matches the corresponding plan_tier value.

Return mode controls what gets returned when multiple units could match. 'Return content when first unit qualifies' stops at the first match — the recipient sees one block. 'Return combined content of all qualified units' stacks every matching unit — the recipient sees multiple blocks concatenated. Combined mode is useful for accumulating personalization (a VIP who's also in EMEA gets BOTH a VIP block AND a EMEA-specific block in the same email).

Rules within a unit AND together. So a unit with rules "plan_tier = pro" AND "country = US" only matches recipients who satisfy both. To express OR logic, split into multiple units — each with one of the OR-branches as its rule. Combined with return mode, this gives you flexible per-recipient content composition without nested ifs.

The conditional surface

Where DCTs reach. What they branch on.

DCTs work in the same fields as Spintax + Custom Fields, branch on the full set of recipient attributes, and combine cleanly with the other personalization syntaxes. The conditional layer that lives between rotation and substitution.

composable fields
All
composable fields
Subject, From Name, Pre-header, HTML body, Text body. The same surface area as Spintax and merge tags.
rule evaluation
Per-recipient
rule evaluation
Rules evaluate against the recipient record at send time — no batch pre-resolution. Different recipients get different branches in the same broadcast.
stacking
Cross-syntax
stacking
DCT content can contain Spintax tags ({{tag}}) which can contain Custom Field references (%%field%%). Three layers, one template.
syntax modes
Two
syntax modes
Saved [[tag]] DCTs for reusable rule sets, inline [if:field=value]…[endif] conditionals for direct field checks. Combine freely.

The three layers, one email

DCT + Spintax + Custom Fields in the same template.

The three syntaxes layer cleanly because the platform processes them in a fixed order: DCT first (decide which block), Spintax second (rotate within the block), Custom Fields third (substitute values). See the result on the right.

TEMPLATE authored once 
{{greeting}} %%first_name%%,

[if:plan_tier=enterprise]
  Your Q3 review is scheduled with %%account_manager%%.
[elseif:plan_tier=pro]
  {{pro_benefit_callout}} — refer
  a friend for %%referral_credit%% credits.
[else]
  Upgrade to Pro and unlock unlimited sends.
[endif]

{{closing}},
{{sales_guy}}
RENDERED · [email protected] at send time

Hello Sarah,

Your Q3 review is scheduled with Marcus Chen.

Best,
Ayvar Gabidullin

DCT: plan_tier=enterprise → unit 1

Spintax: greeting → Hello · closing → Best · sales_guy → Ayvar

Fields: first_name → Sarah · account_manager → Marcus Chen

What single-template-fits-all costs

Why every campaign needs a branching layer.

Most senders run separate broadcasts per audience cohort — and pay for it in maintenance, copy drift, and missed opportunities to combine cohorts on the same send.

  • Multiple broadcasts per audience is operational debt

    Running a separate broadcast for free / pro / enterprise means 3× the QA, 3× the chance of copy drift, 3× the spots where a typo hides. One DCT-driven broadcast with three Content Units does the same job from one source of truth.

  • Segments + separate sends miss intersection cohorts

    Pro-tier AND EMEA. VIP AND first-time-purchaser. Segments isolate cohorts; combining DCT units in 'combined' return mode stacks per-recipient content for the intersection. The recipient gets BOTH blocks, not one or the other.

  • Per-broadcast personalization can't scale to long drips

    A 12-email drip sequence with 4 audience cohorts would be 48 separate emails to maintain. With DCTs, it's 12 emails — each with one [[tag]] that branches per recipient. Maintenance load drops by an order of magnitude.

  • Fallbacks for missing data shouldn't require a separate broadcast

    Half your list has first_name, half don't. Without inline conditionals, you either send "Hello %%first_name%%," and accept that half the audience sees "Hello ," — or you maintain two broadcasts. [if:first_name]…[else]…[endif] solves it in one line.

“We had been running five separate broadcasts per send — one per plan tier, plus a US vs EU split. Switched the entire stack to DCTs with combined return mode and now we send ONE broadcast that personalises down to plan_tier × region per recipient. Saved hours of QA per send and cut copy drift to zero.”

Verified review

Mumara customer

Trustpilot

Common questions

What buyers usually ask.

What's the difference between [[tag]] and [if:field]?

[[tag-name]] references a SAVED Dynamic Content Tag — defined at Campaigns → Dynamic Content Tags with reusable rule sets and Content Units. [if:field=value]…[endif] is an INLINE conditional written directly in the email body — no separate definition. Use saved DCTs for reusable rule sets referenced across multiple campaigns; use inline conditionals for one-off field checks specific to a single email. Both work in the same fields and resolve at the same processing stage.

How do rules combine within a Content Unit?

AND-logic — every rule in the unit must match for the unit to qualify. So a unit with rules "plan_tier = pro" AND "country = US" only returns for recipients who satisfy both. To express OR logic, split into separate units, each with one of the OR-branches as its rule. Then choose the appropriate return mode (first-match for one block, combined for stacking matches).

What does 'combined' return mode actually do?

Combined return mode stacks the content of every Content Unit whose rules qualify. A DCT with three units (one for VIPs, one for EMEA, one for first-time-purchasers) would return all three blocks concatenated for a recipient who's a VIP, in EMEA, AND a first-time-purchaser. First-match return mode stops at the first qualifying unit and returns only that block. Combined is for accumulating personalization; first-match is for one-of-many branching.

Can I check list membership inline?

Yes — use [ifmemberof:"List Name"]content[endif]. Pass multiple comma-separated list names for OR-logic membership: [ifmemberof:"VIP Customers","Premium Members"]content[endif] renders if the recipient is in EITHER list. Useful for shared content across cohorts without encoding the cohort in a custom field. Pair with [else] for non-member fallback.

Do DCTs work with RSS feeds?

Yes — DCTs are the ONLY way to embed RSS feed content in a Mumara email, BUT this is gated by the separately-purchased [RSS Feed addon](/campaigns/addons/rss-feed/). Configure a DCT with an RSS / Atom / JSON Feed / Media RSS source URL; reference feed item variables with triple-underscore syntax (___title___, ___link#1___, ___content:encoded#2{char=300;images=none}___). Conditional content + multi-unit DCTs work without the addon; RSS-feed-driven DCTs require it.

How does the processing order interact with Spintax and merge tags?

Strict pipeline: DCTs resolve FIRST (decide which block), then Spintax (rotate within that block), then Recipient Fields (substitute values), then System Variables (sender info, links, dates). So a DCT block can contain Spintax tags which can contain %%field%% references — each layer operates on the resolved output of the previous one. See [Personalization Options](/campaigns/features/personalization-options/) for the full processing-order diagram.

Can I nest DCTs inside other DCTs?

Not as a documented pattern. The recommended approach for nested logic is either (a) combine the outer condition into the inner DCT's rule set so the rules express the full check, or (b) use inline [if:] conditionals inside a DCT's Content Unit content body — that resolves at the same stage and avoids the nesting question. For very complex branching, a Content Unit's body can contain its own [if:][elseif:][endif] chain.

What inline conditional operators are supported?

= and == (equals), != (not equals), > (greater than), < (less than) — for field-value comparisons. Plus the field-existence form [if:field] which checks for non-empty value, and the empty-check form [if:field=] which checks for empty. Numeric operators (>, <) work against Numeric Custom Fields. Saved DCTs (via the Add Rule UI) support a richer set of operators — Is/Isn't/Contains/Doesn't contain/Greater than/Lesser than/Between/Older than/Occurred after/For the past/First char/etc. — covering all the type-specific operators that [Custom Fields](/campaigns/features/custom-fields/) support in segments.

What happens if no Content Unit qualifies?

Nothing renders for that recipient — the [[tag]] resolves to empty content. If you want a fallback block for the 'no matches' case, define a final Content Unit with no rules (matches everyone) and rely on first-match return mode to use it only when nothing earlier qualifies. For inline conditionals, use [else] as the explicit fallback branch.

How does this compare to building separate broadcasts per segment?

Separate broadcasts are clearer when audiences are fully disjoint (different language, different brand). DCTs are clearer when audiences share most content but differ on specific blocks (different CTA per plan, different shipping note per region). DCTs cut maintenance: one template instead of N. They also enable intersection cohorts (Pro AND EMEA) without exponentially growing the broadcast count. For most senders, the right answer is BOTH — separate broadcasts for fundamentally different messages, DCTs for variations within a message.

Related

Pages that pair with this one.

Mumara Campaigns · Dynamic Content Tags

One template. Every audience. No copy drift.

Dynamic Content Tags ship with every Mumara Campaigns plan — Self-Hosted and Mumara Machine. Saved [[tag]] DCTs, inline [if:field=value] conditionals, list-membership checks, multi-unit return modes. RSS Feed integration via the addon.

Get started See pricing