SMTP2GO to Volanea Migration Guide for Developers

SMTP2GO to Volanea migration is more than swapping an API key or SMTP password. A safe move preserves the sender identity your recipients see, the authentication receivers validate, the suppression decisions that protect reputation, and the application logic that reacts to delivery events.

This guide is for developers migrating transactional email from SMTP2GO to Volanea. It uses a controlled parallel-testing approach: inventory what exists, configure Volanea without disrupting production, verify the first messages end to end, then move traffic in deliberate stages. SMTP2GO supports both SMTP and HTTP API integrations, reporting, templates, and webhooks, so the amount of work depends less on message volume than on which of those features your application uses.

Start with an inventory, not a code change

The temptation in an email-provider migration is to find the send function, replace credentials, deploy, and wait for a receipt email to arrive. That proves only one narrow path works. It does not prove that your return-path alignment survived, that bounced recipients are still blocked, that webhook-driven account state still updates, or that an older service using SMTP was included in the move.

Before creating production credentials in Volanea, document your current SMTP2GO footprint. The result should be a short migration worksheet that lets you compare the old and new behavior rather than reconstruct it after a delivery incident.

What to capture from SMTP2GO

Record the following for every environment: production, staging, preview, and local development where applicable.

• Send paths: API clients, SMTP libraries, background workers, serverless functions, CRMs, devices, and third-party applications that relay through SMTP2GO.
• Sending identities: every From, reply-to, envelope sender or return-path configuration, subdomain, and branded tracking domain in use.
• Message classes: password resets, verification emails, receipts, invoices, alerts, account invitations, lifecycle messages, and campaigns. Separate essential account mail from optional marketing mail.
• Code dependencies: the SMTP2GO SDK package and version, raw API calls, SMTP credentials, template IDs, custom headers, attachments, and inline-image behavior.
• Event consumers: webhook endpoints, queues, data warehouses, CRM updates, alerting jobs, and any code that expects a particular delivery-event payload.
• Suppression sources: hard bounces, complaints, unsubscribe requests, internal blocklists, abuse reports, and product-level preferences.
• Operational controls: rate limits, retry rules, timeout settings, alert thresholds, IP allowlists, and who can rotate credentials.

Keep this inventory in version control or your change-management system. It gives reviewers a concrete definition of done and prevents a common failure mode: transactional messages migrate while an overlooked billing worker, printer, or legacy app continues sending from SMTP2GO.

SMTP2GO’s API can send a standard message through /email/send or send a complete MIME message through /email/mime. That distinction matters. If your application uses standard API fields, you can usually map the sender, recipients, subject, text, HTML, attachments, and headers conceptually. If it constructs raw MIME, you must separately test encoding, boundaries, inline content IDs, custom headers, and the exact behavior of any signed or encrypted messages.

Choose the migration boundary: SMTP, REST, or an adapter

Volanea supports SMTP and REST-based email sending. The least disruptive migration path is not always the best long-term interface, so decide deliberately.

SMTP is the smallest code delta

If your application already uses Nodemailer, a framework mailer, JavaMail, .NET SmtpClient, PHP mail transports, or a device that only speaks SMTP, moving to Volanea SMTP can be mostly configuration work. Your application keeps generating the same MIME message; the relay endpoint and credentials change.

That makes SMTP useful for a phased migration. You can move an existing app without rewriting every notification flow, then assess whether a REST integration offers the observability or feature model you want later.

The tradeoff is that SMTP responses are naturally less expressive than a provider API. You should not assume that a successful SMTP handoff means inbox placement or final delivery. Continue to consume event data and monitor bounces after cutover.

REST is useful when your application owns the sending model

A REST integration is usually the better fit when the application controls message creation, needs structured request/response handling, or wants a provider-neutral sending abstraction. It is also a good moment to make idempotency and retry behavior explicit rather than relying on whichever behavior an SDK happened to expose.

Do not port an endpoint path or JSON field name by analogy. SMTP2GO’s standard sending endpoint is /email/send, but Volanea’s current request schema, authentication method, and available message options should be taken directly from the email API reference and setup guides when you implement the REST sender. Provider APIs often look similar while differing in recipient objects, attachment encoding, scheduling, tag fields, error shapes, and idempotency conventions.

An application-owned adapter reduces future migrations

For most production systems, the strongest design is to isolate the provider behind a small internal interface. Application code should express what it wants to send, while one adapter translates that intent to SMTP or the provider API.

For example, your application can own this stable input shape:

type TransactionalMessage = {
  from: { email: string; name?: string };
  to: Array<{ email: string; name?: string }>;
  replyTo?: { email: string; name?: string };
  subject: string;
  text?: string;
  html?: string;
  headers?: Record<string, string>;
  tags?: string[];
  idempotencyKey: string;
};

Your order service calls sendTransactional(message) and does not know which provider implements it. The adapter logs a provider message identifier, applies retry policy, normalizes failures, and supplies the information required to correlate later webhook events. This is not abstraction for its own sake: it keeps provider-specific objects, template IDs, and error semantics from leaking across your codebase.

Before and after: SMTP2GO SDK call vs Volanea SMTP call

The example below intentionally compares an existing SMTP2GO Node SDK send with an equivalent Volanea SMTP transport. The SMTP2GO side uses the documented smtp2go-nodejs fluent mail builder and api.client().consume() call. The Volanea side uses Nodemailer, so it is a real transport call rather than an invented Volanea SDK method or unverified REST endpoint.

Set VOLANEA_SMTP_HOST, VOLANEA_SMTP_PORT, VOLANEA_SMTP_USERNAME, and VOLANEA_SMTP_PASSWORD from the current Volanea SMTP setup instructions for the environment you are configuring. Keeping those values in environment variables avoids baking a hostname, port, or secret into source code.

Before: SMTP2GO Node SDK

import SMTP2GOApi from 'smtp2go-nodejs';

const api = SMTP2GOApi(process.env.SMTP2GO_API_KEY!);

const mailService = api
  .mail()
  .to({ email: 'customer@example.com', name: 'Avery Customer' })
  .from({ email: 'receipts@example.com', name: 'Northstar' })
  .subject('Your order receipt')
  .html('<h1>Thanks for your order</h1><p>Order #4821 is confirmed.</p>');

const result = await api.client().consume(mailService);
console.log(result);

After: Volanea through SMTP with Nodemailer

import nodemailer from '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,
  },
});

const result = await transport.sendMail({
  from: { address: 'receipts@example.com', name: 'Northstar' },
  to: [{ address: 'customer@example.com', name: 'Avery Customer' }],
  subject: 'Your order receipt',
  html: '<h1>Thanks for your order</h1><p>Order #4821 is confirmed.</p>',
  text: 'Thanks for your order. Order #4821 is confirmed.',
  headers: {
    'X-Application-Message-ID': 'order-4821-receipt-v1',
  },
});

console.log(result.messageId);

The important behavioral difference is not fluent SDK syntax versus a mailer object. It is ownership. In the first example, the SMTP2GO SDK creates and submits the provider request. In the second, Nodemailer constructs the message and sends it through the Volanea SMTP relay. Preserve both HTML and text alternatives, preserve meaningful custom headers, and store the accepted message ID together with your own application message ID.

Do not use X-Application-Message-ID as a substitute for provider-supported idempotency if you move to REST later. It is useful for correlation and debugging, but email receivers may see custom headers and providers may not deduplicate based on them. Your application should still prevent duplicate jobs before retrying a send.

Map message behavior instead of field names

A migration is complete only when the recipient experience and the operational semantics match the intended design. Create a mapping table for your application before changing production traffic.

Sender, reply-to, and envelope behavior

A From address is not just display text. It participates in DMARC alignment, user trust, and reply handling. Keep the same visible sender initially unless you have a separate reason to change branding. A migration is a poor time to simultaneously alter the domain, display name, unsubscribe experience, and email content because it becomes difficult to attribute delivery changes.

Treat reply-to separately. Some messages should route replies to support, while receipts may use a monitored inbox or an explicit no-reply policy. Test a real reply from an external mailbox; do not infer reply behavior from the source code alone.

Text, HTML, and rendering

SMTP2GO can accept standard message components, while a raw MIME path can contain more elaborate structures. When recreating a message through SMTP, rendering differences often come from the generating library rather than the relay. Test responsive HTML, dark-mode appearance, links, preheader text, localization, line wrapping, and plain-text fallback.

For each major email type, save a rendered baseline before the migration. Then send the Volanea version to the same controlled inboxes and compare visible content and raw headers. A visual diff catches markup regressions; raw-source inspection catches missing multipart alternatives, altered character sets, or broken attachment boundaries.

Re-authenticate domains without breaking live mail

DNS is where many apparently successful email migrations lose deliverability. SMTP2GO’s domain authentication may use CNAME records for return-path and DKIM configuration, and its setup can avoid requiring an SPF include because SPF alignment is handled through a custom return-path. Do not assume that model transfers to a different provider.

Volanea will provide its own DNS values for the sending domain or subdomain. Publish exactly the record types, names, values, and TTLs displayed in the current Volanea setup flow. Never replace a record merely because its hostname resembles an existing SMTP2GO record. The provider-specific targets, DKIM selectors, and return-path configuration are not interchangeable.

DNS and authentication checklist

Use this checklist before routing production traffic to Volanea:

• List every domain and subdomain used in From addresses, including regional or tenant-branded domains.
• Add each domain or subdomain in Volanea and obtain its exact verification records.
• Publish Volanea’s required SPF, DKIM, return-path, and tracking-domain records exactly as specified.
• Confirm whether an existing TXT SPF record must be edited, merged, or left untouched. A domain must not have multiple independent SPF TXT policies.
• Confirm DKIM selectors do not collide with active SMTP2GO selectors or another sender’s selectors.
• Verify the Volanea domain status only after DNS propagation is visible from public resolvers.
• Send test mail to Gmail, Outlook, and a mailbox you control; inspect Authentication-Results for SPF, DKIM, and DMARC outcomes.
• Confirm the domain in the visible From address aligns with either SPF or DKIM according to your DMARC policy.
• Keep SMTP2GO DNS records in place during parallel testing unless a record name collision makes coexistence impossible.
• Remove SMTP2GO-specific records only after all sending paths have moved and you have observed stable authentication results.

DMARC is especially important if your domain has p=quarantine or p=reject. A message can be accepted by the relay and still fail receiver policy if neither SPF nor DKIM aligns with the visible From domain. Verify the actual result in received headers; a dashboard verification badge is not a substitute for recipient-side authentication results.

Preserve suppression, consent, and unsubscribe intent

A provider migration must never turn a previously suppressed recipient into a valid target. Your internal system should remain the durable source of truth for consent and sending eligibility, while provider suppression tools provide an additional safety layer.

Export or otherwise retrieve the SMTP2GO data you are authorized to move: hard bounces, spam complaints, unsubscribes, manual blocks, and any recipient-level exclusions relevant to your mail program. Normalize these records into a provider-neutral structure before import.

type Suppression = {
  email: string;
  reason: 'hard_bounce' | 'complaint' | 'unsubscribe' | 'manual_block';
  source: 'smtp2go' | 'application' | 'support';
  occurredAt?: string;
  scope: 'all_email' | 'marketing_only' | 'list_or_topic';
};

The scope field matters. An unsubscribe from product marketing may not mean a user opted out of password resets, security alerts, legally required notices, or receipts. Conversely, a complaint or confirmed hard bounce should normally stop all nonessential mail. Preserve the original intent rather than flattening every record into a single generic blocklist.

A safe suppression migration sequence

1. Export the suppression data and record the export time, filters, row count, and source account.
2. Normalize addresses: trim whitespace, lowercase the domain portion, deduplicate, and retain original reason and timestamp where available.
3. Remove obvious invalid rows, but do not delete legitimate historic suppressions merely because a current validation check is inconclusive.
4. Import records into Volanea using its current supported mechanism and retain the import receipt, count, and any rejected-row report.
5. Keep an application-level suppression check active during and after the provider move.
6. Send controlled tests only to addresses that are not suppressed.
7. Confirm that a deliberately suppressed test recipient cannot receive a nonessential message.

Large historical suppression lists are one of the harder parts of this migration. They may contain duplicates, obsolete columns, partial reasons, internationalized addresses, or records that were created by workflows no longer in use. Import limits and available metadata can also differ between systems. Plan a small pilot import first, compare counts and samples, then import the full list with a rollback record.

For addresses you are uncertain about, do not use a production send as a validity test. Use a dedicated address-checking workflow, such as an email address verification tool, where it fits your privacy and consent requirements.

Rebuild webhooks as an event-processing system

SMTP2GO webhooks can notify your web service when email or SMS events occur. Your Volanea webhook integration should be treated as a new event source, not as a URL replacement. Event names, payload schemas, retry schedules, signatures, and message identifiers may differ even where the business meaning is similar.

Build a mapping document that relates each current event consumer to a desired outcome:

Webhook implementation rules

Your endpoint should first authenticate the request according to the current Volanea documentation, then persist the event or enqueue it, then return success quickly. Do not make a slow CRM call, render a report, or perform a network-heavy lookup before acknowledging a webhook delivery.

Make processing idempotent. A provider can retry when your endpoint times out, and event streams can contain duplicates or out-of-order notifications. Use a provider event ID when supplied; otherwise derive a durable deduplication key from the provider message ID, event type, and event timestamp with careful collision handling.

Keep the original payload for a defined retention period, with appropriate access controls. Normalized event fields make application queries easier, but raw payloads are invaluable when you need to investigate why a recipient was suppressed or why a delivery status changed.

Before production cutover, exercise the endpoint with a test delivery and a test failure scenario. Confirm signature validation, expected status code, queue persistence, duplicate handling, logs, alerts, and the internal state changes that follow.

Templates, campaigns, and SMTP2GO-specific features

SMTP2GO provides dashboard templates and API template capabilities. If your application currently uses template IDs and template variables, expect this to be a design migration rather than a credential change. Template systems can differ in variable delimiters, escaping, conditional logic, loops, defaults, layout inheritance, preview behavior, and whether a missing variable is rendered as blank or rejected.

The honest approach is to treat template translation as content engineering:

• Export or copy the HTML, text version, subject, preview text, and variable contract for each live template.
• Identify dynamic variables and their data types: strings, currencies, dates, URLs, arrays, and optional values.
• Rebuild the template in Volanea or render it in your application, depending on your preferred ownership model.
• Create fixture data for normal, missing, long, localized, and malicious-looking values.
• Compare the output against SMTP2GO’s current production rendering before switching.

Template syntax differences are among the hardest elements to migrate cleanly. A variable that looked harmless in an old template can become an escaped string, unescaped HTML, blank output, or a runtime error in a new rendering system. Avoid copying a production template and immediately sending a campaign. Render first, review links and merge fields, and have someone other than the author inspect the result.

Also inventory features that may not map one to one: SMS capabilities, dashboard-managed templates, specific report views, SMTP2GO API endpoints for administration, proprietary recipient groups, campaign workflows, tracking-domain behavior, usage alerts, or account-level sending controls. Volanea may offer a different implementation or may require an application-owned alternative. The right outcome is not necessarily a feature-for-feature clone; it is preserving the business and operational behavior you actually need.

Test delivery, not just acceptance

Use a small, representative test matrix before any broad cutover. Include major mailbox providers, company domains with stricter filtering, and a seed inbox where you can inspect raw source.

For each message type, verify:

• API or SMTP acceptance and the stored provider message ID.
• Correct visible sender, reply-to, subject, content, links, and attachment behavior.
• SPF, DKIM, and DMARC pass results in received headers.
• Webhook receipt and correct internal event processing.
• Bounce and complaint handling where safely testable.
• Suppression enforcement for a deliberately blocked non-production address.
• Retry behavior after a simulated transient application or network failure.
• Duplicate prevention when the same job is retried.

Do not judge success by open rates during a short migration window. Privacy features, image blocking, and mailbox-provider behavior make open data incomplete. Stronger migration signals are authentication pass rates, accepted-versus-delivered reconciliation, hard-bounce and complaint trends, webhook processing health, and support tickets related to missing mail.

Roll out in stages and keep rollback simple

A staged rollout limits the blast radius of an unexpected DNS, template, or event-processing error. Start with internal messages or a low-risk transactional class, then expand only after the metrics and logs are healthy.

A practical sequence is:

1. Configure Volanea domains, credentials, webhook endpoint, and suppressions without changing production routing.
2. Send authenticated test messages to controlled inboxes and verify raw headers.
3. Move a small, low-risk message class, such as internal alerts or a noncritical notification, to Volanea.
4. Observe acceptance, webhooks, bounces, and support feedback for a defined period.
5. Move higher-value mail such as receipts, account verification, and password resets after the relevant tests pass.
6. Migrate templates and campaigns separately from essential transactional mail when possible.
7. Keep SMTP2GO credentials and DNS configuration available for rollback until every sender path and worker has moved.
8. Revoke or disable old credentials only after a final inventory review confirms they are unused.

Your rollback plan should be a configuration switch, not a hurried code rewrite. For SMTP, that often means keeping the previous transport configuration securely available behind a feature flag. For REST, it means retaining the old adapter implementation until the new one has proved stable. Do not run full production traffic through both providers indefinitely unless you have intentionally designed message-level routing and deduplication; otherwise duplicate emails become likely.

What is harder to migrate, and what may be easier

SMTP2GO is a mature option for SMTP and API-based sending, with templates, reporting, and webhook capabilities. If those existing workflows match your application well, migration has a real cost: teams must rebuild integration details, re-establish operational baselines, and learn a new delivery workflow. That is not a reason to rush or to assume an alternative is automatically better.

The migration tends to be easiest when your application already owns message templates, suppression decisions, recipient consent, and event normalization. In that case, SMTP2GO primarily functions as a delivery provider, and Volanea can be introduced behind a focused adapter.

It tends to be harder when the SMTP2GO dashboard is the operational system of record. Large historical suppression lists can need cleanup and scoped mapping. Dashboard templates can need a syntax rewrite and visual QA. Reports may not be directly comparable across providers. Webhook consumers can rely on undocumented payload assumptions. Devices or third-party apps using old SMTP credentials can be missed unless your initial inventory is thorough.

The practical tradeoff is clear: a careful migration takes more upfront engineering than a password swap, but it creates a cleaner provider boundary, explicit deliverability checks, and a documented sending system that is easier to operate later.

Final SMTP2GO to Volanea migration checklist

Use this as the release gate for production cutover.

• All SMTP2GO API, SMTP, template, webhook, and campaign dependencies are inventoried.
• Volanea credentials are stored in a secret manager and separated by environment.
• All active sending domains or subdomains are verified in Volanea.
• SPF, DKIM, return-path, tracking, and DMARC alignment have been checked using actual received message headers.
• The sender, reply-to, text, HTML, attachments, inline images, and custom headers match expected behavior.
• Application message IDs and provider message IDs are stored for reconciliation.
• Suppression, complaint, bounce, unsubscribe, and manual block data has been migrated or is enforced internally.
• A suppressed test address has been confirmed not to receive nonessential email.
• Webhook authentication, persistence, retries, ordering tolerance, and idempotency have been tested.
• Template output has been rendered and approved with representative data.
• Delivery tests cover Gmail, Outlook, and at least one mailbox or domain relevant to your customers.
• Observability dashboards and alerts distinguish accepted, deferred, bounced, complained-about, and delivered messages where data is available.
• A feature-flagged rollback route exists and the on-call team knows how to use it.
• Old SMTP2GO credentials remain available only for the defined rollback window, then are revoked.

FAQ

Can I migrate from SMTP2GO to Volanea by changing only SMTP credentials?

Sometimes, if every application sends through a standard SMTP library and does not depend on SMTP2GO templates, webhooks, reporting, or provider-specific settings. Even then, re-verify domain authentication, message rendering, suppression behavior, and delivery events before moving all production traffic.

Should I remove SMTP2GO DNS records as soon as Volanea verifies my domain?

No. Keep SMTP2GO records during parallel testing and the rollback period unless a specific DNS name collision requires a coordinated change. Remove old provider records only after every sender path has moved and authentication results are stable.

Can I import every historical bounce as a Volanea suppression?

Usually, that is the safer default for permanent failures and complaints, but preserve the reason and scope where possible. Review marketing-only unsubscribes separately from hard bounces and security-related transactional mail so you do not accidentally override consent or legal-notice requirements.

Do SMTP2GO templates transfer directly to Volanea?

Not necessarily. HTML and text content can be reused, but template variable syntax, escaping, logic, preview behavior, and template identifiers may differ. Rebuild and render each template with representative fixtures before enabling production sends.

How long should I keep SMTP2GO available after cutover?

Keep it available for the documented rollback period and until you have confirmed that scheduled jobs, background workers, third-party systems, and webhook consumers are all operating correctly. Then revoke old credentials and remove unused DNS records in a planned cleanup change.