Built in public.

Your AI agents can now build, send, and analyze campaigns directly. BLUN · Mailing exposes a full Model Context Protocol server at wss://send.blun.ai/mcp, scoped per workspace via signed bearer keys. Twelve tools are live in the first cut.

• list_lists · create_list · get_list_subscribers
• create_campaign · send_campaign · schedule_send
• get_campaign_analytics · get_deliverability_report
• list_segments · create_segment · preview_render · run_compliance_check

The endpoint is wired for Mnemo Connect out of the box. Drop the keypair into your local Mnemo daemon and your agents pick up the channel with zero glue:

# Pair your agent fleet with the workspace MCP endpoint
mnemo connect mcp:wss://send.blun.ai/mcp \
  --key "pmk_live_a3f9_…" \
  --workspace "anna-leather" \
  --scope "campaigns:rw analytics:r"

# Verify the channel is live
mnemo connect channel-list --filter BLUN · Mailing

Read the full tool reference and scopes table at /docs/mcp. Available now to all Business workspaces; Free and Growth tiers can still drive everything via the REST API.

Until today, the pre-send check verified that DKIM and SPF were both authenticated and aligned with the From-domain. That covered the common cases — but it missed a quieter foot-gun: a published DMARC policy of p=quarantine or p=reject on the organisational domain that the campaign sender silently fails alignment on.

The new check resolves the DMARC record at the org-domain (not the sub-domain), evaluates the policy, and warns before the send commits. Result: 0 wasted bounces from policy errors on workspaces that hit the new banner.

The banner is non-blocking — you can override and proceed — but it's now part of the audit log on every campaign. See /docs/deliverability/dmarc.

After three months of beta-stability across thousands of integrations, the REST API at https://api.send.blun.ai/v1 graduates to stable. From today, every endpoint under /v1 is covered by the public versioning policy: no breaking changes without a new major version, and a minimum 90-day overlap between v1 and any future v2.

One small breaking change ships with the stability promise: every POST request must now include a client-generated Idempotency-Key header. Retries become safe by default, and the platform can return the original response for up to 24 hours of replays without re-running side effects.

# Every POST now requires Idempotency-Key
curl https://api.send.blun.ai/v1/campaigns \
  -H "Authorization: Bearer $PULSE_KEY" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{"list_id":"lst_a1","subject":"Spring drop"}'

Existing clients without the header will receive 400 idempotency_required for the next 30 days, then a hard fail. The official SDKs (Node, Python, Ruby, Go, PHP) auto-generate keys per-request — upgrade to the latest minor and you're covered.

Full versioning policy and migration notes at /docs/api/versioning.

The campaign builder is a fully drag-drop block editor now. Fourteen block types ship in v1: Hero, Text, Heading, Image, Image-pair, Button, Divider, Spacer, Quote, Card, Card-row (2 / 3 / 4 columns), Video-embed, Footer, and the new Stripe block for promotional bars.

Every block that takes an image (Hero Background, Image, Card thumbnail, Image-pair, Stripe) opens the same Library tab. Two sources, one experience:

• Stock — curated, royalty-free, GDPR-compliant photography sourced and EU-cached.
• Your uploads — drag-drop straight into the modal, or paste from clipboard. Files are deduped per workspace and served from the EU CDN edge.

The whole canvas is keyboard-navigable: Tab moves between blocks, Enter opens the inspector, ⌘D duplicates. Every change is autosaved with a 30-version history.

The single biggest contributor to per-message latency in our outbound path was DKIM signing — a synchronous, CPU-bound RSA-2048 sign on every message, with key material loaded from disk into the signer process on cold paths. Profiling showed signing at the p50 was burning 168 ms per message. That's now down to 32 ms.

What changed:

• 8-shard signer pool — workers are pinned to dedicated CPU cores in our DE-NUE region; the message router round-robins by destination domain hash to keep cache locality high.
• Lazy-load DKIM keys — workspace key material is fetched on first use and cached for the life of the worker; the warm path no longer touches disk.
• Cache hit rate of 94% across active workspaces in the first 72 hours, up from a cold reload on every send.

germany and the EU-only mode see the same gains. No action required — every workspace is on the new path.

Hitting the inbox is half the battle. The other half is hitting it at the moment the recipient actually opens email. BLUN AI send-time optimisation looks at every past open and click for an address, models the time-of-day pattern per timezone, and picks the best hour to deliver — per recipient, on every send.

Switch a campaign from "Send now" to "Optimise per recipient" and BLUN · Mailing stages the message in the outbound queue, then releases it inside each recipient's predicted high-engagement window over the following 24 hours.

Early signal from the closed beta is encouraging: +14% open lift on welcome flows across 11 workspaces, with the lift concentrated on previously-engaged recipients (no measurable impact on cold lists, as expected).

Case study — Anna's leather workshop. A small atelier outside EU runs a monthly "what's new in the workshop" newsletter to 4,800 subscribers. After three sends with per-recipient timing, opens climbed from 38% to 47%, and replies (yes, real replies) more than doubled. Anna was the first non-staff to test it; she didn't change a single thing about her copy.

Available now on Growth and Business plans. Toggle it per campaign or set it as a workspace default at /docs/sending/send-time-optimisation.

On April 2 at 14:11 UTC, a rolling restart of the rate-limit subsystem caused four minutes of false-positive 429 Too Many Requests responses on roughly 6% of API traffic. Sending was unaffected (the SMTP and queue pipelines never paused) but a subset of REST clients saw spurious throttling on otherwise-healthy keys.

Root cause. The rate-limit cluster came up with two leaderless followers for ~240 seconds during the restart sequence, both with stale token-bucket state. Followers were serving reads against pre-restart counters and rejecting requests that should have passed.

Fix. The rate-limit subsystem now uses an explicit Raft-style leader election on cluster join, with a hard read-after-leader gate. A new follower will not serve traffic until it has successfully syncronised against the elected leader's state.

Full timeline, contributing factors, and the action items already merged in the post-incident review: status.send.blun.ai/incidents/2026-04-02.

Segments could already filter on tags, custom fields, signup source, and consent state — all of them static. The piece nobody could express was anything temporal: "people who opened in the last N days", "people who haven't engaged in 90+ days", "people who clicked any campaign in the last week".

That's now a first-class predicate. The new last_opened_in_days and last_clicked_in_days operators take an integer window and combine with everything else in the segment builder.

Anna's "active in last 30 days" segment now updates itself — no more weekly CSV exports and re-tagging. Available on every plan, evaluated lazily at send-time so segment counts always reflect the freshest engagement data.

The "manage preferences" link in every campaign footer used to land on a single big "Unsubscribe?" button. That's a coin-flip the recipient often loses by default — and the workspace loses the address forever.

Every footer-link now lands at /preferences/<token> — a hosted page where the recipient self-manages exactly what they've signed up for, no login needed:

The page also exposes the recipient's GDPR rights inline — request data, request deletion, export — so workspaces don't need a separate privacy portal.

Early data across the launch cohort: workspaces that swapped to the preferences page see roughly −42% hard unsubscribes month-over-month, replaced by frequency / topic dialling. The recipient stays on the list, you just send less.

For about ten days in early March, a quiet retry-backoff bug was adding up to 3 seconds of jitter to webhook delivery. The bug originated in a regression where the backoff timer's first interval was being applied to the initial attempt instead of the first retry — every webhook was paying retry latency on its very first delivery.

Fixed. The backoff state machine now starts in state=initial with a zero delay, and only enters the exponential ladder after the first non-2xx response.

Post-fix metrics from the last 72 hours:

• p50 webhook delivery: 142 ms (was 1,650 ms during the regression)
• p95 webhook delivery: 780 ms (was 3,180 ms)
• p99 webhook delivery: 1,210 ms (was 4,400 ms)

If you saw event lag on consumer-side automations between Mar 2 and Mar 12, this was almost certainly the cause. No replay required — every event was delivered, just slower than promised.

Importing 50,000 subscribers via POST /api/v1/subscribers one address at a time was the wrong shape for the wrong job — it ate rate-limit budget, was painful to retry, and turned a five-minute migration into a 90-minute one.

The new endpoint accepts a CSV up to 50 MB in a single multipart request, returns a job_id immediately, and processes asynchronously with a per-job status webhook:

curl -X POST https://api.send.blun.ai/v1/subscribers/import \
  -H "Authorization: Bearer $PULSE_KEY" \
  -H "Idempotency-Key: $(uuidgen)" \
  -F "list_id=lst_a1" \
  -F "file=@subscribers.csv" \
  -F "webhook_url=https://you.example/imports"

# → { "job_id": "imp_8f2a", "state": "queued", "rows": 47812 }

The job runs in chunks of 1,000, deduplicates against the workspace's existing subscriber set, and respects every consent-state column you provide. Status webhooks fire on processing, completed, and failed with row-level error reporting.

The 1-by-1 endpoint stays — it's still the right call for transactional flows. For migrations and ETL, switch to /import. Docs at /docs/api/subscribers/import.

The default flow at BLUN · Mailing is already EU-hosted — campaign data, subscriber lists, and the outbound queue all live in Germany. EU-only mode goes one step further: it guarantees that nothing about your campaign — send, delivery, click-tracking, open pixels, image hosting — leaves EU jurisdiction at any point.

What flips with the toggle:

• Outbound MTAs are restricted to EU-hosted germany (DE-NUE) and germany (DE-FSN). No fallback to non-EU regions during incidents.
• Click-tracking and open-pixel domains resolve to EU-only edge nodes; no US CDN fallthrough.
• Image library and uploads are pinned to EU storage, EU-edge cached.
• Webhooks to non-EU endpoints require explicit per-endpoint approval and an audit trail.

Default-on for every new workspace created from today. Existing workspaces can flip it at Settings → Compliance → EU-only mode; the toggle is workspace-scoped and changes apply to the next campaign send. The setting also surfaces in the DPA appendix you can download from the same page.

If you're working with regulated EU customers, this is the easiest single click in the product. If you're not, leaving it off keeps the existing flow with EU defaults but global edge fallback.