Migrating email infrastructure is less about replacing one send call with another and more about preserving the conditions that make mail arrive. This guide explains how to migrate from Mailjet to Volanea methodically, from inventory and authentication through parallel testing, webhook changes, suppression handling, and final cutover.

The safest migration treats sending identity, recipient consent, and event processing as production systems. Keep Mailjet available until Volanea has passed controlled delivery tests and your application has processed Volanea events correctly.

Start with a migration inventory

Before changing code, document what Mailjet does for your product today. A simple transactional application may have one sender address and a password-reset email; a mature system may use multiple domains, templates, contacts, event webhooks, subscription preferences, and separate streams for product mail and campaigns.

Create an inventory that answers three questions: what sends email, which identities it sends from, and what happens after a message is sent. This prevents a common migration failure: moving the primary send path while overlooking a worker, scheduled job, staging environment, or inbound event consumer.

Identify every sending workload

List each workload separately, even if it currently uses the same Mailjet account and credentials:

Transactional messages: account verification, password reset, receipts, alerts, invoices, and security notices.
Product notifications: comments, mentions, digests, exports, and operational messages.
Marketing or campaign mail: announcements, newsletters, onboarding sequences, and re-engagement sends.
System-generated mail: application error alerts, support flows, cron jobs, and background workers.
Development and test traffic: local preview, CI, sandbox environments, and staging.

For every workload, record the source application, sending domain, From address, Reply-To behavior, expected volume, peak rate, template location, recipient data source, and owner. Also record whether a message is sent through Mailjet’s API, SMTP relay, or a library that hides that transport choice.

The inventory should include non-code dependencies. For example, a billing platform may be configured to send through SMTP, while a custom application uses Mailjet’s API. A migration that only updates the application repository can leave a legacy integration sending through old credentials indefinitely.

Capture current behavior, not just configuration

Save representative message payloads with secrets and personal data removed. Include plain-text-only mail, HTML mail, attachments, multiple recipients, custom Reply-To values, tags or categories, and messages with template variables. These samples become your acceptance test set.

Also capture the business behavior around a send. Does the application retry a failed API request? Does it store a provider message identifier? Does it wait for a delivery event before marking a notification complete? Does it suppress a recipient locally after a bounce? Those decisions matter more than the mechanical API replacement.

Finally, establish baseline metrics. Record normal send volume, acceptance rate, hard-bounce rate, complaint rate, delivery timing, and major mailbox-provider distribution for a representative period. You need a baseline to recognize whether the new route is behaving differently after cutover.

Choose the migration boundary

Volanea supports SMTP and REST sending, but you do not need to move every pathway in one release. Choose a boundary that limits risk and gives the team a clear rollback option.

For many teams, transactional mail is the best first workload because it is triggered by known application actions and has clear success criteria. Campaign mail can follow after domains, unsubscribe behavior, audience data, and template rendering have been verified.

SMTP versus REST API

SMTP is often the lowest-friction option when an application already uses a standard mail library. It can reduce application changes because the message construction layer stays the same: the application still creates a MIME message and calls its mail transport. The important changes are transport credentials, host configuration, and event handling.

A REST API can be a better fit when your application already has a provider adapter, needs structured request handling, or benefits from explicit API response semantics. Do not assume a Mailjet endpoint, request field, or SDK abstraction maps directly to a Volanea endpoint. Confirm the current request shape, authentication method, response fields, attachment encoding, and idempotency guidance in the email API reference and setup guides before implementing a REST adapter.

The practical rule is simple: preserve what is already reliable. If your application generates correct MIME content through SMTP and you do not need provider-specific API features, an SMTP-first migration may substantially reduce scope. If you want a normalized provider interface and explicit JSON payloads, build that interface once and test it carefully.

Use a provider adapter

Avoid scattering provider calls throughout your codebase. Introduce an internal interface such as sendTransactionalEmail(message) and keep Volanea transport details in one module. That design makes it easier to run a controlled canary, compare results, and roll back if necessary.

Your internal message object should contain business-level fields, not Mailjet-specific ones. A useful model includes recipients, sender, reply-to address, subject, text content, HTML content, headers, attachments, a logical message type, and your own correlation ID. Provider message IDs should be stored as metadata returned by the transport layer, not treated as your permanent application identifier.

Before and after: Mailjet SDK and Volanea SMTP

Mailjet’s Node.js SDK commonly sends through the v3.1 Send API with a Messages array. The following example is a representative Mailjet SDK call using the SDK’s apiConnect, post('send', { version: 'v3.1' }), and request pattern.

The Volanea example uses Nodemailer’s standard SMTP transport. It deliberately reads the Volanea SMTP hostname, port, username, and password from environment configuration rather than guessing values. Obtain those exact connection values from Volanea’s current documentation or account setup, and do not copy Mailjet SMTP credentials into the new configuration.

Before: Mailjet Node.js SDK call

const Mailjet = require('node-mailjet');

const mailjet = Mailjet.apiConnect(
  process.env.MJ_APIKEY_PUBLIC,
  process.env.MJ_APIKEY_PRIVATE
);

async function sendPasswordReset({ email, resetUrl }) {
  const request = mailjet
    .post('send', { version: 'v3.1' })
    .request({
      Messages: [
        {
          From: {
            Email: 'security@example.com',
            Name: 'Example App'
          },
          To: [{ Email: email }],
          Subject: 'Reset your password',
          TextPart: `Reset your password: ${resetUrl}`,
          HTMLPart: `<p>Reset your password: <a href="${resetUrl}">Reset password</a></p>`
        }
      ]
    });

  const result = await request;
  return result.body;
}

After: equivalent Volanea SMTP send

const nodemailer = require('nodemailer');

const transport = nodemailer.createTransport({
  host: process.env.VOLANEA_SMTP_HOST,
  port: Number(process.env.VOLANEA_SMTP_PORT),
  secure: process.env.VOLANEA_SMTP_SECURE === 'true',
  auth: {
    user: process.env.VOLANEA_SMTP_USERNAME,
    pass: process.env.VOLANEA_SMTP_PASSWORD
  }
});

async function sendPasswordReset({ email, resetUrl }) {
  const result = await transport.sendMail({
    from: 'Example App <security@example.com>',
    to: email,
    subject: 'Reset your password',
    text: `Reset your password: ${resetUrl}`,
    html: `<p>Reset your password: <a href="${resetUrl}">Reset password</a></p>`
  });

  return {
    messageId: result.messageId,
    accepted: result.accepted,
    rejected: result.rejected,
    response: result.response
  };
}

This is not a character-for-character conversion because the systems operate at different layers. Mailjet’s example submits a structured API payload through its SDK, while Nodemailer constructs and submits an SMTP message. The equivalent business action is the same: send one password-reset email with the same sender, recipient, subject, text part, and HTML part.

Do not interpret SMTP acceptance as a delivery guarantee. SMTP accepted indicates the receiving relay accepted the message for processing. Delivery, deferral, bounce, and complaint information belong in event processing and observability.

Differences to account for in application code

Mailjet’s Messages wrapper and its capitalized request fields are part of its API schema. They should not leak into a provider-neutral application object. In the SMTP example, from, to, subject, text, and html are Nodemailer message options, not Volanea REST field names.

If your existing application depends on Mailjet response objects, replace that dependency deliberately. For example, if a database stores a Mailjet message ID, add columns or metadata that can hold a provider name and a provider-specific message identifier. This lets you preserve historical records while correctly associating new events with Volanea sends.

Attachments, CC/BCC recipients, custom headers, message tags, and bulk sends require their own tests. Especially verify that user-provided variables are HTML-escaped in templates and that any custom headers remain valid after the transport change.

Re-authenticate every sending domain

A provider migration is also an authentication migration. Your domain’s DNS records determine whether receiving systems can evaluate SPF, DKIM, and DMARC alignment for mail sent through Volanea.

Do not remove Mailjet records as the first step. Publish and validate Volanea’s required records, then send test mail, inspect authentication results, and only retire old authorization once it is no longer needed. Removing an old SPF include before the new sender is authorized can produce SPF failures during the most sensitive period of the migration.

SPF: avoid accidental authorization gaps

SPF is evaluated against the envelope sender domain, also called the return-path or MAIL FROM domain. The correct Volanea SPF instruction is provider- and configuration-specific, so use the exact record value supplied by Volanea rather than assuming a hostname or copying a value from another provider.

A domain can publish only one SPF TXT record. If your domain already has an SPF record for Mailjet or another sender, you normally need to merge authorization mechanisms into that one record during coexistence. Publishing a second independent v=spf1 TXT record does not create a combined policy and can cause a permanent SPF error.

Check DNS lookup limits as you merge records. SPF evaluation permits no more than 10 DNS-querying mechanisms and modifiers during an evaluation. A long chain of provider includes, redirects, and nested includes can exceed that limit, causing a permerror even when each individual service is correctly configured.

DKIM: preserve selectors and verify signing

DKIM uses a selector-specific DNS record. Mailjet signing and Volanea signing may use different selectors, which is normal and useful during a transition. Multiple DKIM selectors can coexist because receivers query the selector used in the message’s DKIM-Signature header.

Publish Volanea’s exact DKIM record exactly as supplied, including record type, selector hostname, and value. Then send to a mailbox you control and inspect the raw headers. Look for a passing DKIM result and confirm that the d= signing domain aligns with the visible From domain under your DMARC policy.

Do not delete the Mailjet selector merely because Volanea’s selector is live. First make sure no application, scheduled campaign, or vendor integration continues to send through Mailjet. Keeping an unused selector temporarily is generally less risky than breaking authentication for a forgotten sender.

DMARC and alignment

DMARC evaluates whether SPF and/or DKIM passes with alignment to the RFC 5322 From domain visible to the recipient. A move can reveal a pre-existing weakness: perhaps Mailjet used a configured custom return path while the new setup initially does not, or perhaps the application sends from subdomains that were not in the original plan.

Review your DMARC record’s policy and reporting addresses before cutover. If the domain has a strict policy, test with real recipient domains before increasing traffic. DMARC aggregate reports can help identify unexpected sources, but they are not real-time monitoring; use direct seed testing and provider event telemetry too.

Rebuild webhooks as an event contract

A sending provider’s webhook payload and retry behavior are part of your application’s public operational contract. Treat the move as an integration rewrite, even where the broad event names sound familiar.

Your Mailjet implementation may currently process events such as sent, open, click, bounce, blocked, spam, unsubscribe, or delivery. Volanea may represent events, identifiers, timestamps, recipient fields, and failure reasons differently. Build an internal event normalization layer rather than changing business logic to depend on a new raw payload.

Design for duplicates and out-of-order delivery

Webhooks can be retried, duplicated, delayed, and received out of order. A delivery event may arrive after a retry path has already recorded another state, and a bounce can arrive long after initial acceptance. Your endpoint should be idempotent.

A robust webhook consumer records a stable event key when one is provided, stores the raw payload for debugging under appropriate retention controls, and applies state changes safely. If no globally unique event ID is available, derive a deduplication key from the provider message ID, event type, timestamp, and recipient with caution. Do not use a recipient address alone as the deduplication key.

Return a successful HTTP response only after the event has been durably queued or stored. If processing is expensive, validate and enqueue first, then process asynchronously. This reduces timeouts and prevents provider retries from multiplying work.

Verify endpoint security

Use the webhook authentication or signature verification method documented by Volanea. Do not assume Mailjet’s validation scheme, event URL settings, or retry policy applies to the new integration. Preserve the raw request bytes when signature verification requires them; parsing and reserializing JSON before verification can invalidate a signature scheme.

Limit accepted methods, enforce HTTPS, rotate any shared secret safely, and log verification failures without logging credentials or entire message bodies unnecessarily. Test both valid and intentionally invalid requests in a non-production environment.

Webhook events are operational data, not just analytics. Bounces and complaints should update recipient eligibility promptly; unsubscribe events should reach your preference system; and delivery failures should be visible to the team responsible for customer communications.

Move suppressions and consent data carefully

Suppressions are one of the highest-risk parts of email migration because they encode negative recipient signals: hard bounces, spam complaints, opt-outs, blocks, and manually suppressed addresses. Sending again to addresses that were previously suppressed can hurt deliverability and violate a recipient’s expressed preference.

Export the relevant data from Mailjet before cutover, retain a protected archival copy, and import or enforce it in the destination process as appropriate. The exact import method depends on the Volanea capability available for your account; consult the current documentation rather than assuming a Mailjet list or contact endpoint has a direct equivalent.

Separate categories of suppression

Do not treat every excluded address as the same kind of record. Keep at least these distinctions in your canonical data model:

Marketing unsubscribes: recipients who opted out of promotional or campaign content. These must remain excluded unless they explicitly opt back in under your applicable consent rules.
Hard bounces: addresses that are invalid or permanently unavailable. Exclude them from future sending until corrected through a deliberate process.
Spam complaints: recipients who marked mail as spam. These deserve particularly conservative treatment and should not simply be reintroduced during a migration.
Temporary failures and blocks: addresses with transient delivery problems, mailbox limits, or policy blocks. These may need a retry policy rather than permanent suppression.
Internal exclusions: test accounts, legal holds, abuse prevention lists, and recipient-specific blocks maintained by your application.

A single flat CSV can erase these reasons. If the destination accepts only a simpler suppression representation, retain the richer source-of-truth data in your own database or secure archive so future policy decisions remain possible.

Validate addresses before reactivation

A migration is a good time to stop treating old contact data as automatically sendable. Historical contacts may have decayed, changed ownership, or been added without current consent. For addresses outside an established opted-in audience, use a cautious review process and consider a free email address verification tool as one signal before attempting delivery.

Verification is not proof of permission. An address can be syntactically valid and accept mail while still being unsubscribed, inactive, role-based, or inappropriate for a given message. Keep consent and preference records separate from deliverability checks.

Large historical suppression lists can be genuinely hard to migrate. Normalize casing, trim whitespace, handle internationalized domains consistently, deduplicate records, and preserve reason and timestamp fields where possible. Import in controlled batches if the destination imposes limits, and reconcile source counts with accepted, rejected, and duplicate counts after each batch.

Audit templates, personalization, and tracking

Mailjet templates and templating syntax may not map one-to-one to a Volanea sending workflow. That is normal: template systems differ in variable notation, conditional logic, loops, default values, escaping behavior, preview tools, localization, and template identifiers.

For transactional mail, the most portable approach is often rendering HTML and text in your application with a template engine you own, then passing final content to the transport. This makes provider changes less invasive, but it also moves responsibility for rendering, preview, escaping, and versioning into your codebase.

Build a template conversion matrix

For each active template, document the Mailjet template identifier or source location, trigger, variables, fallback values, language variants, legal footer requirements, and expected output. Then decide whether to rebuild it in an available Volanea workflow or render it in the application.

Test not only the happy-path payload. Use missing optional variables, long names, characters requiring HTML escaping, RTL content where applicable, empty arrays, locale-specific dates, and unusual URLs. A template that visually resembles the old version can still produce broken links or malformed HTML on a rare but important customer record.

Always keep a plain-text part for transactional mail where possible. It improves accessibility and gives recipients a useful fallback when HTML is blocked or malformed. Compare rendered HTML and text side by side during QA rather than only reviewing screenshots.

Re-check links and open/click measurement

If you use open or click tracking, test it as a data pipeline change. Tracking can rewrite URLs, change event identifiers, alter how privacy features affect metrics, and require new webhook interpretation. Do not use raw open rate as a delivery-health proxy; privacy protections and client behavior make it an increasingly imperfect measure.

Check that password-reset and sign-in links survive rewriting correctly, preserve query parameters, and use your expected hostnames. Security-sensitive transactional links deserve direct manual testing on mobile and desktop clients, not just an HTTP-level assertion.

Campaign templates must also preserve unsubscribe mechanics. Verify that required unsubscribe links, preference-center links, sender identity, and physical-address or legal content meet your organization’s policy and applicable rules. Do not rely on a provider default footer without confirming the final rendered message.

Run a controlled delivery test

The first Volanea message should not be a full production campaign. Use a test matrix and send representative mail to controlled inboxes at major mailbox providers, then inspect authentication, rendering, headers, and event capture.

Include Gmail, Microsoft Outlook/Hotmail, Yahoo, and a private-domain mailbox if those are meaningful to your audience. Use actual recipient inboxes you control and have permission to test, rather than buying or scraping addresses.

What to inspect in every seed message

For each seed message, verify:

The visible From name, From address, Reply-To address, and envelope sender are expected.
SPF, DKIM, and DMARC pass in the recipient’s authentication results.
HTML, text, images, attachments, and links render correctly.
The expected event reaches your webhook consumer and is associated with the correct internal message record.
An intentional bad address produces the expected failure handling without repeatedly retrying indefinitely.
A recipient opt-out is honored by your own eligibility checks before future campaign sends.

Do not judge placement from one test inbox. Inbox placement varies by recipient engagement, domain reputation, content, provider policy, and sending patterns. The goal of early seed tests is to find configuration and integration errors, not to make sweeping deliverability claims.

Use gradual traffic migration

After functional tests pass, route a small, observable slice of production traffic through Volanea. Segment by message type, environment, tenant, or a stable hash of recipient ID. Avoid sending duplicate production messages through both providers unless the message is explicitly designed for a duplicate-safe test and recipients have agreed to it.

Monitor acceptance, bounces, complaints, deferrals, webhook failures, latency, and support tickets. Increase traffic only after each stage meets your pre-defined thresholds. Keep the previous Mailjet route available for rollback while DNS coexistence and operational monitoring remain in place.

Re-verify this cutover checklist

Use this checklist during implementation, before the first canary, and again before retiring Mailjet. Checkboxes are intentionally specific because a migration can appear complete while one important dependency remains unchanged.

Sending identity and DNS

Inventory every From domain, subdomain, envelope-sender domain, and Reply-To domain used by each workload.
Publish Volanea’s exact DNS instructions for each sending identity.
Merge SPF authorization into one valid SPF TXT record per domain; do not publish competing SPF records.
Check SPF DNS lookup complexity during the overlap period.
Publish Volanea DKIM selector records and confirm actual messages pass DKIM.
Confirm SPF and/or DKIM alignment with the visible From domain under DMARC.
Keep Mailjet authentication records until all Mailjet traffic has ended and a safe observation period has passed.
Review DMARC aggregate reports and test-message authentication results.

Application, webhooks, and operations

Replace Mailjet SDK credentials and SMTP credentials in every runtime environment, worker, and vendor integration.
Store Volanea credentials in a secret manager or equivalent protected configuration; never commit them.
Test SMTP connection settings or the REST API implementation using the current Volanea documentation.
Map provider response identifiers to an internal provider/message-ID model.
Configure and test Volanea webhook delivery using the documented security verification method.
Make webhook processing idempotent and resilient to retries and out-of-order events.
Update dashboards, alerts, runbooks, and on-call ownership for the new event source.
Preserve a documented rollback route and criteria for using it.

Data and feature parity

Export and archive Mailjet suppression, unsubscribe, bounce, complaint, and contact-preference data as permitted by your policies.
Import or enforce suppressions before sending migrated marketing traffic.
Reconcile suppression counts and reasons after import; investigate rejected rows rather than discarding them.
Rebuild or relocate templates and test variables, conditionals, escaping, localization, and text alternatives.
Re-test attachments, CC/BCC, custom headers, Reply-To addresses, and any batch sending logic.
Review Mailjet-specific features such as template IDs, contact lists, campaign automation, tracking behavior, statistics exports, and event payloads for non-identical replacements.
Confirm unsubscribe links and your own preference system work after the new send path is live.

Be honest about what does not migrate cleanly

Some pieces move quickly: a simple SMTP integration, a handful of transactional templates, and a verified domain can often be tested in a focused engineering cycle. Other pieces require data governance, product, marketing, security, and operations input.

Large historical suppression lists are difficult because records may lack a consistent reason, date, consent source, or normalized address format. Template syntax differences are difficult because conditional logic and escaping behavior are easy to overlook. Historical analytics may not be comparable across providers because event definitions, retention, bot filtering, and privacy effects differ.

Mailjet-specific campaign workflows, contacts, list segmentation, template management, and reporting may require separate replacement decisions. Volanea’s SMTP and REST sending capabilities solve the message transport problem; they should not be assumed to recreate every provider-specific workflow without a requirements review.

There are tradeoffs on both sides. Retaining Mailjet-specific features can be convenient for teams that depend on them today, while moving to a transport-centered design can reduce provider coupling for developers. The right decision depends on whether your priority is a minimal operational change, a new API integration, centralized template ownership, campaign workflow needs, or long-term portability.

Cut over, observe, and retire safely

A migration is complete only when live traffic, recipient protections, and operational observability are working on the new route. Do not define completion as “the deployment succeeded” or “a test email arrived.”

During the observation period, compare the new route with your baseline by message type. Look for unexpected bounce classifications, missing webhook events, altered rendering, changes in complaint handling, authentication failures, and support tickets about missing messages. Investigate changes before attributing them solely to provider reputation or recipient behavior.

When traffic is fully on Volanea, rotate or revoke Mailjet credentials according to your organization’s access-control process. Remove Mailjet DNS authorization only after confirming that no remaining application, job, or third-party integration sends through it. Preserve exports and migration documentation according to retention requirements, and update incident runbooks with the new sending, event, and rollback paths.

The durable outcome is not simply a new provider configuration. It is an email architecture where domains are authenticated, recipient preferences are protected, templates are testable, webhook consumers are reliable, and provider-specific code is isolated enough to evolve safely.

FAQ

How long does it take to migrate from Mailjet to Volanea?

A basic transactional SMTP migration can be tested quickly, but production timing depends on DNS propagation, template complexity, webhook work, suppression-list cleanup, and gradual traffic validation. Plan the cutover as an operational project rather than only a code change.

Can I keep Mailjet and Volanea active during migration?

Yes, a controlled overlap is usually safer. Keep Mailjet active while Volanea authentication and event processing are tested, but avoid duplicate sends to real recipients. Maintain one clear routing rule for each production message.

Do I need to change DNS records when moving providers?

Yes, you should publish and verify the exact SPF and DKIM records required for Volanea, then confirm DMARC alignment with live test messages. Keep existing Mailjet records during coexistence until all old sending has stopped.

Can I directly reuse Mailjet templates in Volanea?

Do not assume so. Template syntax, IDs, variables, conditionals, escaping, and workflow behavior can differ. Rebuild and test each active template, or render final HTML and text in your application.

What is the biggest migration risk?

The largest risks are broken authentication, missed unsubscribe or suppression data, and webhook integrations that silently fail. A staged rollout with seed testing, normalized event handling, and reconciliation of suppression data reduces those risks.

How to Migrate From Mailjet to Volanea Without Disrupting Email