Native Ads — In-Context Email Advertising

Native ads in MailAdx render as a composite PNG at open time — assembled from the advertiser's headline, body copy, thumbnail, and your publisher brand settings. No JavaScript. No third-party pixels. Just a real ad that looks like it belongs in your newsletter.

How native ads work

When a subscriber opens an email containing a native ad tag, MailAdx's ad server runs the waterfall and selects a winning native creative. It then renders a composite PNG in real time using Java2D — combining the advertiser's assets with the publisher's configured style (colors, fonts, layout). The resulting image is streamed back to the subscriber's email client in under 150ms.

No JavaScript executes in the inbox. No third-party CDN URL is exposed to Gmail Image Proxy. The subscriber sees a polished in-context ad that blends with the editorial content around it.

Layout options

The layout is part of each native ad unit's configuration. Three layouts are available:

  • CARD — Thumbnail above, headline and body below. Best for editorial newsletters with wide column layouts.
  • SPLIT — Thumbnail on the left, headline and body on the right. Best for compact placements or mid-article slots.
  • TEXT_ONLY — Headline and body only, no thumbnail. Best for text-first newsletters where images would break the visual style.

Setting up native ad units (Publishers)

  1. Navigate to Publisher Portal → Ad Units → New Ad Unit
  2. Set Format = NATIVE
  3. Choose a Layout: CARD, SPLIT, or TEXT_ONLY
  4. Configure style: background color, text color, headline font size, border radius
  5. Set a Floor CPM (minimum bid to win this placement)
  6. Toggle Journey Ads on/off for this unit
  7. Click Preview to see a live render with dummy assets
  8. Copy the generated ad tag and paste it into your ESP template

The ad tag format:

<img src="https://mailadx.com/api/v1/serving/native/{pubId}/{placementKey}/{'{'}{'{'EMAIL_SHA256{'}'}{'}'}" width="600" alt=""/>

Replace {{EMAIL_SHA256}} with your ESP's merge tag for the subscriber's SHA-256 email hash: 64 lowercase hex characters of the lower-cased address. The native endpoint accepts only a SHA-256 hash. Unlike the display tag, it does not hash a raw email address for you, and MD5 or subscriber IDs get no ad.

Creating native creatives (Advertisers)

  1. Navigate to Advertisers → [your advertiser] → Creatives → New Creative
  2. Select Type = NATIVE
  3. Fill in the native assets:
    • Headline — max 60 characters
    • Body — max 120 characters
    • Sponsored-by label — your brand name
    • Thumbnail — recommended 300×200 px, JPG or PNG
    • Click-through URL — the destination when subscribers click
  4. Click Preview to see how it renders in the publisher's layout
  5. Save and attach to a line item

AdChoices and branding

By default, MailAdx appends small static branding elements to native ad units: an "Ad" badge, a "Powered by MailAdx" credit, and an AdChoices icon. These serve from /api/v1/serving/static as separate image requests and only appear when a real ad fills.

Publishers who want to suppress these branding elements (for white-label or editorial-consistency reasons) can ask MailAdx to turn off Show Native Branding Banner. It is a publisher-level setting (showNativeBrandingBanner, applied to all the publisher's native units) — when off, all three static images return a 1×1 transparent pixel. The “Sponsored” disclosure drawn inside the ad image itself always stays.

Technical notes

  • Composite PNG rendering runs in the adserver JVM via Java2D — no external render service
  • Thumbnail images are fetched and cached in memory (thread-safe LRU cache) to avoid repeated CDN fetches
  • No-fill response is a 1×1 transparent PNG — email layout is never broken
  • Gmail Image Proxy: the first request redirects to the same URL with a fresh per-open value and no-cache headers, so Gmail re-fetches on every open and each open gets a fresh decision. The native endpoint needs a real SHA-256 hash in the URL — unlike the display tag, it does not accept a plain email address.
  • Apple MPP: pre-fetches are recognised by User-Agent and labelled AppleMPP in reports; they are counted as opens (not excluded from billing)