SMTP.com to Volanea Migration Guide for Developers

SMTP.com to Volanea migration is best handled as an email-infrastructure cutover, not a simple credential swap. Your application can often send a test message quickly, but a safe production move requires preserving domain authentication, bounce handling, recipient suppression, templates, tracking expectations, and operational monitoring.

This guide is written for developers moving a transactional or mixed transactional-and-campaign workload from SMTP.com to Volanea. It takes a staged approach: inventory the existing system, build the new integration in parallel, verify the delivery controls that matter, send controlled traffic, then retire the old path only after you have evidence that the new one behaves as intended.

Start with the right migration goal

The goal is not merely to make an API request return success. A successful SMTP.com to Volanea migration means that the application continues to send the right message to the right recipient, from an authenticated identity, while your team can still detect bounces, complaints, deliveries, and failures quickly enough to act on them.

That distinction matters because email has several independent layers:

• Submission: your application hands a message to the provider through SMTP or HTTPS.
• Authentication: SPF, DKIM, and usually DMARC alignment establish that the sender is authorized.
• Message construction: sender identity, recipients, HTML, text, attachments, headers, tags, and reply handling must remain correct.
• Delivery operations: queues, transient failures, hard bounces, complaints, and suppressions have to affect future sending.
• Observability: logs and event notifications must let your application and on-call team understand what happened after submission.

SMTP.com supports both an SMTP relay and a REST API, with API v4 using JSON and several documented authentication options. Its sender/channel model can also be part of an existing application’s configuration, especially where separate credentials or reporting paths are used for different sending streams. Volanea supports transactional sending through SMTP and REST-oriented email infrastructure, so you should decide whether the first cutover preserves your current SMTP transport or moves the application to an HTTP API at the same time.

For most teams, changing one major variable at a time is safer. If your existing code uses SMTP.com through Nodemailer, JavaMail, Laravel Mail, Django SMTP settings, or a similar transport abstraction, start by moving the transport. Once the sending path is stable, consider an API-oriented refactor if it gives your application better request tracing, structured errors, or provider-specific capabilities.

Inventory your SMTP.com implementation before changing code

Do not begin with a search-and-replace of environment variables. Start with an inventory that tells you what SMTP.com is actually doing in production today. The result should be a short migration document or spreadsheet that an engineer can review during the cutover.

Find every sending path

Many systems have more email entry points than expected. Password resets may use one service, receipts another, background jobs a third, and a legacy application may still send directly through SMTP.

Search for the following in repositories, deployment configuration, secret managers, task queues, and third-party automation:

• SMTP hostnames, SMTP usernames, and SMTP.com sender credentials.
• SMTP.com API keys and references to api.smtp.com.
• Mail libraries such as Nodemailer, PHPMailer, JavaMail, Python smtplib, Rails Action Mailer, or framework mail adapters.
• Templates stored in source control, a CMS, a provider account, or a database.
• Bounce, complaint, open, click, unsubscribe, and delivery webhook consumers.
• Scheduled jobs that export statistics, delivery logs, or reports.
• Data jobs that add addresses to a local denylist after SMTP.com events.
• Separate transactional, marketing, support, and internal-notification streams.

Treat each stream as an independent mini-migration. A password-reset email has a different risk profile from a weekly product update. The former needs fast, dependable delivery after a user action; the latter may rely on segmentation, unsubscribe behavior, and campaign reporting. Avoid sending both streams through one untested replacement path on day one.

Record the message contract, not just credentials

For each email type, record the inputs and outputs your application depends on. The message contract should include the sender address and display name, recipient fields, subject, plain-text body, HTML body, attachments, custom headers, reply-to behavior, and correlation identifiers.

Also write down what the calling code expects after a send attempt. For example, does it expect a queued response, a provider message ID, a synchronous exception, or a background job result? Does the application retry on timeouts? Does it accidentally retry all 4xx and 5xx responses? Does it store an idempotency key? These details determine whether a cutover causes silent drops or accidental duplicate mail.

A useful inventory row looks like this:

This work seems administrative, but it exposes hidden dependencies early. A provider switch is much easier when the team discovers a callback-driven suppression process before, rather than after, a campaign reaches addresses that previously bounced.

Choose a cutover shape: SMTP first or API first

Volanea offers both SMTP and REST sending, so you can choose the migration path that produces the least application risk. The right choice depends on your present architecture rather than on a blanket claim that one protocol is always better.

Option 1: Preserve SMTP for the first release

If SMTP.com is already behind a mature mail library, an SMTP-first migration minimizes code changes. Your messages can keep the same RFC-style fields: from, to, cc, bcc, subject, text, html, attachments, and headers. The immediate application change is typically a new host, credentials, and TLS configuration supplied by the new account.

This is especially useful for older applications, platforms with built-in SMTP configuration, and shared mail helpers used by many services. It also gives your team a clean way to compare message output before and after the provider switch because the application-level message object stays largely unchanged.

The tradeoff is that SMTP responses are less naturally structured than a purpose-built HTTP API. You may retain less provider-specific metadata at submission time unless your application already adds an internal correlation ID in a header or metadata field.

Option 2: Move to a REST API during migration

An HTTP API can be a good fit when you are already rewriting a mail service, centralizing email behind an internal service, or need clearer request logging. An API integration can make it easier to associate an application event ID with a provider response and handle ordinary HTTP retry semantics deliberately.

The tradeoff is a wider migration surface. You are changing both provider behavior and your application’s transport contract. Payload names, recipient object formats, attachment encoding, custom-header support, batch behavior, and response formats may differ. Do not combine this with a template rewrite, a new queue, and a sender-domain change unless you have enough test capacity to isolate failures.

Use the Volanea API reference and setup guides to confirm the current request schema, authentication header, endpoints, webhook signing behavior, and test-mode behavior before implementing the REST path. Those details should come from the current documentation, not from copied snippets designed for a different provider.

Side-by-side code comparison: SMTP.com transport to Volanea transport

SMTP.com does not require an official Node-specific SDK for SMTP submission; many Node applications use Nodemailer as the transport SDK. The comparison below deliberately keeps Nodemailer on both sides. That makes the code change concrete and avoids pretending that a provider-specific SDK method exists where your application is actually using standard SMTP.

The SMTP.com examples and setup material identify SMTP credentials as sender login/password credentials and document send.smtp.com as the relay hostname in integration guidance. SMTP.com also documents that sending credentials are tied to sender configuration. For Volanea, use the SMTP host, port, encryption mode, username, and password shown for your account in the current setup documentation rather than guessing a hostname or port.

Before: Nodemailer sending through SMTP.com

import nodemailer from "nodemailer";

const smtpComTransport = nodemailer.createTransport({
  host: "send.smtp.com",
  port: 2525,
  secure: false,
  auth: {
    user: process.env.SMTPCOM_USERNAME,
    pass: process.env.SMTPCOM_PASSWORD,
  },
});

export async function sendPasswordReset({ recipient, resetUrl }) {
  const result = await smtpComTransport.sendMail({
    from: 'Acme Accounts <accounts@example.com>',
    to: recipient,
    subject: "Reset your password",
    text: `Reset your password: ${resetUrl}`,
    html: `<p>Reset your password: <a href="${resetUrl}">Reset password</a></p>`,
    headers: {
      "X-App-Message-Type": "password-reset",
    },
  });

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

After: equivalent Nodemailer call through Volanea SMTP

import nodemailer from "nodemailer";

const volaneaTransport = 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,
  },
});

export async function sendPasswordReset({ recipient, resetUrl }) {
  const result = await volaneaTransport.sendMail({
    from: 'Acme Accounts <accounts@example.com>',
    to: recipient,
    subject: "Reset your password",
    text: `Reset your password: ${resetUrl}`,
    html: `<p>Reset your password: <a href="${resetUrl}">Reset password</a></p>`,
    headers: {
      "X-App-Message-Type": "password-reset",
    },
  });

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

The important point is not that the code is identical; it is that the application-level message stays identical while the relay configuration changes. Keep from, replyTo, headers, attachment handling, and message construction stable during the first production cutover. Every additional message change makes it harder to diagnose whether a result is caused by provider configuration, rendering, authentication, or business logic.

Do not copy the SMTP.com port into the Volanea configuration by assumption. Set VOLANEA_SMTP_HOST, VOLANEA_SMTP_PORT, and VOLANEA_SMTP_SECURE from Volanea’s documented connection details. For example, a submission port using STARTTLS should generally not be modeled as the same thing as an implicit TLS connection; confirm the required transport configuration in the current docs and test it in a non-production environment.

Add an internal correlation header

While you are touching this code, make email traceability explicit. Generate an internal message or notification ID before submission and place it in a header that your own systems can search later.

const notificationId = crypto.randomUUID();

const result = await volaneaTransport.sendMail({
  from: 'Acme Accounts <accounts@example.com>',
  to: recipient,
  subject: "Reset your password",
  text: `Reset your password: ${resetUrl}`,
  html: `<p>Reset your password: <a href="${resetUrl}">Reset password</a></p>`,
  headers: {
    "X-App-Notification-ID": notificationId,
    "X-App-Message-Type": "password-reset",
  },
});

logger.info({ notificationId, providerMessageId: result.messageId }, "email accepted by transport");

This header is not a replacement for provider-side IDs or event data. It is an application-controlled join key that helps answer a practical incident question: “Did notification 8d7… leave our queue, and what did the provider subsequently report?”

Re-authenticate your sending domain carefully

Domain authentication is the part of an email move that is easy to underestimate. Your application may successfully authenticate to an SMTP server while mailbox providers still see a broken or misaligned sender identity. Treat DNS as a deliberate migration workstream with its own review and rollback plan.

SPF: do not create a second SPF record

A domain should publish one SPF TXT record for a given hostname. If SMTP.com is currently included in that record and Volanea requires an additional include mechanism or authorization value, merge the authorized mechanisms into the existing policy according to Volanea’s exact DNS instructions.

Publishing two independent SPF TXT records at the same hostname can cause SPF evaluation problems. Do not remove SMTP.com’s authorization until all traffic that relies on it is gone, unless you have verified that no remaining application, device, plugin, or vendor sends through SMTP.com using that domain.

Also review the envelope sender or return-path domain if your implementation has one. The visible From address is not the only identity used in authentication and bounce processing. A move can appear correct in a test inbox while DMARC alignment differs in production because the envelope identity changed.

DKIM: add the new key before removing the old key

Volanea will provide DKIM DNS values for your sending domain. Publish the exact record name and value it supplies, then wait for the domain to show as verified before routing live traffic. Do not reuse an SMTP.com DKIM selector or overwrite its record unless the current provider instructions explicitly say to do so.

Keeping the prior DKIM record during the transition is usually the safer approach. Messages already in queues, messages sent by a missed legacy system, and DNS resolver caching can all create a short period where both providers may need valid authorization. Once SMTP.com traffic is conclusively retired, remove no-longer-needed records as part of the cleanup ticket rather than during the first send test.

DMARC: preserve alignment and reporting

DMARC is a policy and reporting layer that evaluates whether SPF and/or DKIM align with the visible From domain. Do not weaken a working DMARC policy solely to make a migration appear easier. Instead, verify that Volanea’s authenticated sending configuration aligns with the From domains you actually use.

If you receive DMARC aggregate reports, continue reviewing them through the transition. They can reveal an overlooked sender, such as a support platform, WordPress site, appliance, or old worker still using SMTP.com. If the sending domain has strict alignment requirements, test the exact production From address and subdomain rather than using an unrelated sandbox domain.

Rebuild events and webhooks as an application contract

SMTP.com supports callbacks and exposes delivery-oriented data such as delivery logs, bounces, queue status, and complaint-related metrics through its platform. A migration should preserve what your application does with those signals, not simply recreate a URL in a new provider account.

Map events by business outcome

Start with the business outcomes, then map provider event names to them. Your application usually needs concepts such as:

1. Accepted or queued: the provider accepted the submission attempt.
2. Delivered: the recipient server accepted the message.
3. Transient failure or deferred: delivery may still succeed later.
4. Permanent failure or hard bounce: stop sending to that address unless the address is corrected.
5. Complaint: suppress immediately and investigate the sending context.
6. Unsubscribe: update the relevant communication preference.
7. Engagement events: opens and clicks, if you use tracking and understand its limitations.

Do not assume that an event with a familiar name has identical timing or semantics. “Delivered” normally means acceptance by the recipient mail system, not proof that a person saw or read the email. Open tracking is particularly imperfect because image loading can be blocked, proxied, cached, or triggered by automated privacy and security systems.

Make the webhook consumer idempotent

Providers can retry callbacks, callbacks can arrive late, and event ordering may not match the order your application expects. A production webhook endpoint should authenticate the request using the verification mechanism in Volanea’s current documentation, store a durable event record, and make state changes idempotently.

A robust workflow looks like this:

• Verify the request before trusting its payload.
• Store the provider event ID or a stable hash of the event payload.
• Reject or safely ignore duplicates.
• Match the event to your own notification ID, provider message ID, recipient, or both.
• Apply a state transition only when it makes sense for that event.
• Return a successful response only after the durable work has completed or been queued safely.

For example, a hard-bounce event may add an address to a global delivery suppression list. An unsubscribe event should normally alter the appropriate marketing preference, not automatically disable security notifications or legally required receipts. Keep those policies explicit in your own data model.

Before moving live traffic, send representative test messages and exercise each webhook path you can safely produce. Confirm that a valid event is received, signature verification succeeds, the record is stored, duplicate delivery does not create duplicate side effects, and alerts fire if the endpoint begins failing.

Export and reconcile suppression data before cutover

Suppression lists are a safety control, not a convenience feature. If SMTP.com has historical hard bounces, complaints, or unsubscribes that your application relies on, moving without a reconciliation process can expose recipients to unwanted mail and expose your sender reputation to preventable bounces.

Separate delivery suppressions from preferences

Not every “do not send” record means the same thing. Keep at least these categories separate where your data model allows it:

• Hard bounces: addresses that are invalid or permanently undeliverable.
• Spam complaints: recipients who marked messages as spam.
• Provider-level blocks: addresses or domains blocked by policy or reputation controls.
• Marketing unsubscribes: people who opted out of promotional or non-essential mail.
• Account-level preferences: users who disabled a particular product notification.
• Legal or privacy deletion requests: records that may need separate governance.

A one-column CSV containing email addresses loses the reason, source, date, scope, and evidence for suppression. Preserve as much provenance as practical: normalized address, event type, source provider, event timestamp, scope, reason, and import timestamp. This lets you explain why a recipient was excluded and helps avoid applying a marketing preference to an essential transactional message incorrectly.

Reconcile rather than blindly import

Export the data you are permitted to export from SMTP.com, normalize it, remove malformed addresses, deduplicate case-insensitively where appropriate, and count rows by category. Import only through a documented Volanea workflow or API capability that matches the intended scope. If a direct import is not available for a particular category, retain the local suppression check in your application until an equivalent control is confirmed.

Then compare three numbers: the source export count, the successfully imported count, and the count recognized by the new platform or your local suppression service. Investigate discrepancies before the main production cutover. A few invalid rows are normal; an order-of-magnitude mismatch is not.

Large historical suppression lists are one of the harder migration areas. They may contain many years of duplicate records, differing reason codes, outdated addresses, and provider-specific classifications. Moving them safely can require batching, normalization, rate-limit handling, privacy review, and a decision about how long the historical data should be retained. Plan this work separately from the basic “send one email” integration.

Treat templates as a content migration, not a file copy

If your application renders HTML itself, provider migration may leave templates untouched. If messages rely on SMTP.com-linked workflows, provider-managed templates, merge fields, tracking configuration, or provider-specific substitutions, the template layer needs dedicated testing.

What may not map one-to-one

Template engines often differ in variable syntax, conditional blocks, loops, escaping rules, helper functions, partials, default values, and how missing data is handled. A template that renders {{first_name}} in one environment may require a different data shape or syntax elsewhere. Even when two systems use similar delimiters, the behavior for absent fields or HTML escaping may differ.

Links and images also deserve attention. If a previous provider rewrote links for click tracking or hosted assets through a particular domain, rendering and tracking behavior can change. Do not test only the HTML source; inspect the received message in real inboxes and check plain-text alternatives, mobile layouts, dark-mode behavior, replies, and URLs.

Build a golden-message test set

Create a controlled fixture for each high-value email type. Include ordinary data and edge cases: long names, apostrophes, non-Latin characters, blank optional fields, unusually long order lines, multiple recipients if supported, and attachments where relevant.

For each fixture, render and send the SMTP.com version and the Volanea version to seed inboxes or internal test mailboxes. Compare:

• From, Reply-To, and subject values.
• HTML and plain-text content.
• Links, UTM parameters, and tracking behavior.
• Attachments, inline images, and MIME formatting.
• Display across major mailbox clients used by your team or customers.
• Event generation and correlation IDs.

Template syntax differences are another honest migration cost. A simple email can be moved quickly, but a large library of provider-hosted templates with conditionals and personalization may require reimplementation and regression testing. Do not promise a byte-for-byte template migration unless you have verified the source and target rendering models.

What does not map one-to-one from SMTP.com

A fair migration guide should acknowledge that providers package operational features differently. SMTP.com offers SMTP relay, REST API access, channels or senders, reporting, callbacks, and deliverability-focused capabilities. Volanea’s model may organize equivalent functions differently across sending domains, API or SMTP credentials, templates, campaigns, contacts, workflows, and webhook configuration.

Review each SMTP.com-specific dependency and decide whether it should be recreated, replaced in your own application, or retired:

• Channel-level credentials and quotas: If applications use separate SMTP.com channels, decide whether Volanea credentials, domains, tags, or internal service configuration will preserve the needed separation.
• SMTP.com reporting and periodic reports: Rebuild dashboards or scheduled exports against Volanea’s available events and logs, or move key metrics into your own observability stack.
• Callbacks: Re-map event payloads and authentication behavior. Do not point an existing parser at a new provider without a translation layer or tests.
• Reputation Defender or other list-health workflows: Understand whether the behavior is provider-managed, application-managed, or requires a separate validation process after the move.
• Provider-hosted templates and substitutions: Rebuild and render-test them rather than assuming syntax compatibility.
• Legacy plugins and integrations: A WordPress plugin, CRM connector, or automation scenario may have SMTP.com-specific settings. It may be safer to configure that integration via standard SMTP than to force an API rewrite.
• Statistics definitions: Delivery rates, bounce classifications, and engagement calculations can be defined differently. Preserve the trendline, but do not assume exact numerical continuity.

This is not a negative judgment about either service. SMTP.com can be a good fit for teams that value its established relay model, deliverability-oriented offering, and support for existing SMTP-based systems. Volanea can be a good fit when you want transactional sending and campaign-oriented capabilities in a unified email platform. The practical question is whether the new operational model supports your actual message types and controls.

Run a staged production cutover

Once DNS, code, templates, events, and suppression behavior are ready, avoid a big-bang switch. Route controlled traffic through Volanea first and expand only when the evidence supports it.

A practical rollout sequence

1. Use non-production credentials or test mode where available. Confirm that no test email can accidentally reach customers.
2. Verify the sending domain. Publish and validate the exact SPF and DKIM records required for Volanea; review DMARC alignment for production From domains.
3. Deploy dual-ready code. Keep SMTP.com configuration available behind a feature flag or routing rule while Volanea is introduced.
4. Send internal seed traffic. Test representative emails to several mailbox providers and inspect headers, content, authentication results, and event logs.
5. Start with low-risk production traffic. Use a small, observable stream with a clear rollback path, such as internal alerts or a carefully selected fraction of a notification type.
6. Monitor delivery and failures. Watch submission failures, bounce rate, complaint rate, webhook error rate, queue latency, and support tickets.
7. Increase traffic gradually. Expand by message type, region, tenant, or a deterministic percentage of traffic.
8. Retain the old configuration temporarily. Do not immediately delete SMTP.com DNS authorizations or credentials; keep a bounded rollback window.
9. Close the migration deliberately. Once all senders are confirmed on Volanea, export final records you need, remove stale secrets, and clean up old DNS entries only after confirming no source still sends through SMTP.com.

A feature flag should decide the provider before a message is built or queued, not after multiple send attempts. Store the chosen provider with the notification record. If a user reports a missing receipt, your team should be able to answer which provider was selected, which message ID was returned, whether a webhook was received, and whether a retry happened.

Avoid duplicate delivery during fallback

The most common cutover mistake is retrying an ambiguous timeout through the other provider. If SMTP.com accepted a message but your application timed out before receiving the response, immediately re-sending through Volanea can produce a duplicate password reset, receipt, or alert.

Design retries around idempotency. Give each logical notification a stable internal ID, record the attempt before network submission, and inspect the provider result or subsequent events before retrying through a second path. For urgent messages, a duplicate may sometimes be preferable to a missed notification, but make that a conscious per-message-type policy rather than an accidental side effect of generic retry code.

Migration checklist: what to re-verify

Use this checklist at least twice: once before controlled traffic and again before full cutover.

DNS and sender identity

• Every production From domain is added and verified in Volanea.
• SPF has one valid record per hostname and includes all still-active senders.
• Volanea’s required DKIM records are published exactly as provided.
• Existing SMTP.com SPF/DKIM authorization remains until no traffic uses it.
• DMARC alignment is tested with the exact production From domains and subdomains.
• Reply-To addresses, envelope/return-path assumptions, and bounce processing are understood.
• DNS TTLs and propagation time are accounted for in the launch plan.

Application and message construction

• New secrets are stored server-side in the secret manager, never in browser code or repositories.
• SMTP host, port, TLS mode, and credentials come from current Volanea documentation.
• Message IDs and application correlation IDs are logged.
• Sender names, From addresses, Reply-To values, headers, and attachments match intended behavior.
• HTML and plain-text versions are rendered and tested.
• Retry rules distinguish configuration errors, permanent rejections, and transient transport failures.
• Fallback logic cannot silently create duplicate messages.

Webhooks and operations

• Volanea webhook endpoint URLs are configured and reachable from the public internet as required.
• Signature or request verification follows the current Volanea documentation.
• Webhook processing is idempotent and durable.
• Bounces, complaints, and unsubscribes update the correct internal data stores.
• Alerting exists for webhook delivery failures, unusual bounce spikes, and elevated send failures.
• Delivery monitoring distinguishes accepted, delivered, deferred, bounced, and complained states.

Suppressions, templates, and provider-specific features

• SMTP.com hard-bounce, complaint, and unsubscribe data is exported where appropriate and permitted.
• Imported suppression counts reconcile with source counts.
• Local suppression logic remains active until the new control is validated.
• Provider-hosted templates are rebuilt or revalidated; merge fields and conditionals are tested.
• SMTP.com-specific reporting, channels, callbacks, plugins, and list-health features have a documented replacement or retirement decision.
• Historical metrics are annotated so a provider change is not mistaken for a sudden deliverability change.

Measure success after the switch

A migration is not done at the moment the last environment variable changes. Keep a focused observation period after the full cutover, particularly for high-volume or business-critical notification types.

Track the send funnel at each stage: application requested a notification, queue accepted it, provider accepted it, provider reported delivery or a terminal event, and your webhook processor updated the local record. This makes failures visible at the right layer. A rise in application errors is different from a rise in recipient hard bounces; both need attention, but the fixes are different.

Compare metrics by message type rather than only at account level. Password resets, receipts, and product announcements have different audiences and sending patterns. A campaign with a poor recipient list can distort an overall bounce rate, while a low-volume security alert may need immediate investigation even if aggregate metrics look normal.

Also compare operational behavior, not only delivery percentages. Ask whether your team can find a message in logs quickly, trace an event back to an application request, replay a safe test flow, and explain an address suppression. Those are the capabilities that make email infrastructure manageable after launch.

Conclusion

A reliable SMTP.com to Volanea migration is a controlled transfer of sending responsibility, identity, and feedback loops. The code change may be small if you keep SMTP as the first transport, but DNS, webhooks, suppressions, templates, and monitoring still deserve production-grade attention.

Keep the initial cutover narrow. Preserve the message contract, authenticate the same sending domains correctly, import or retain suppression safeguards, map events to business outcomes, and expand traffic only after seed tests and telemetry show that the new path works. Be equally explicit about features that do not map one-to-one, especially historical suppression data, template syntax, provider-specific reporting, and channel-level operational workflows.

FAQ

Can I migrate from SMTP.com to Volanea without changing application code?

Sometimes. If your application uses standard SMTP through a library such as Nodemailer, JavaMail, or a framework mail adapter, the first migration can often be limited to Volanea SMTP connection settings and credentials. You should still re-test TLS configuration, sender authentication, webhooks, and suppression behavior before using production traffic.

Should I remove SMTP.com DNS records as soon as Volanea verifies the domain?

No. Keep SMTP.com authorization records until you have confirmed that every sender, background job, plugin, and integration has stopped using SMTP.com. Removing old records too early can break overlooked sending paths or affect messages already in queues.

What is the hardest part of an SMTP.com to Volanea migration?

For simple SMTP transactional mail, the transport switch is usually straightforward. The harder work is often moving large historical suppression lists, translating provider-hosted templates and merge syntax, rebuilding webhook consumers, and preserving reporting or channel-specific workflows that were tied to SMTP.com.

Can I send through both providers during the migration?

Yes, but route each logical notification to one provider at a time. Parallel testing is useful for seed mailboxes and controlled cohorts, but sending the same production notification through both providers can create duplicates unless that is an intentional test with clearly isolated recipients.

Does a successful send response mean the recipient received the email?

No. A successful SMTP or API response generally means the provider accepted the message for processing. Delivery, bounce, complaint, and engagement information arrives later through provider logs or webhooks, and even a delivered event does not prove that a human read the message.