Migomail's transactional email infrastructure sends receipts, OTPs, password resets, shipping notifications, and alerts in under 2 seconds — via REST API or SMTP relay — on dedicated IPs completely isolated from your marketing sends.
Transactional emails — receipts, OTPs, alerts, confirmations — are the most important emails you send. They need sub-2-second delivery, 99%+ inbox placement, and infrastructure completely isolated from your marketing sends.
Migomail's transactional MTA queues and dispatches messages within 2 seconds of API receipt in 99th-percentile conditions. For OTPs, login alerts, and payment confirmations where the customer is actively waiting, this latency target is operationally non-negotiable. Our SLA is measured at the MTA exit point, not at estimated inbox arrival.
Your transactional emails share no IP infrastructure with marketing campaign sends — not within your own account, and not with any other Migomail customer. A reputation event on a marketing campaign cannot degrade delivery of your OTPs, receipts, or password resets. Isolation is enforced at the MTA configuration level, not just at the UI level.
Send transactional email via a simple REST API call with JSON payload — authentication, to/from/subject/body, template ID, and merge variables in a single request. Alternatively, configure Migomail as an authenticated SMTP relay in your application's existing mail library — no code changes beyond the SMTP host and credentials.
Store and version transactional email templates on Migomail's template engine — so your engineering team manages HTML/CSS design once, and your application sends a template ID plus merge variable values per message. Template updates are deployed via API or dashboard without code changes or application redeployment.
Every transactional message has a unique message ID. Query delivery status, open events, and bounce outcomes per message ID via the REST API — or view them in the transactional analytics dashboard. Essential for debugging delivery issues, proving delivery for legal purposes, and monitoring message-level SLA compliance.
Subscribe to real-time delivery events via webhook — delivered, soft bounce, hard bounce, spam complaint, and unsubscribe — streamed to your own endpoint as each event occurs. Use delivery webhooks to trigger retry logic, update your own database with message status, or alert your operations team when critical message types fail to deliver.
Send transactional email from your own domain — support@yourapp.com, noreply@yourapp.com — with full DKIM and SPF authentication. Migomail generates and manages DKIM keys, provides SPF include records, and guides you through the 3-DNS-record setup process. DMARC policy configuration is supported and recommended.
Manage transactional sends from multiple applications — production, staging, and multiple products — under a single Migomail account. Each application gets its own API key with scoped permissions, its own sending domain, and its own analytics view. API keys can be restricted to specific send operations for security.
Migomail's transactional infrastructure handles every message type your application sends — from time-critical OTPs to detailed order confirmations — each on the same dedicated, isolated sending infrastructure.
One-time passwords and 2FA codes where every second of delay increases abandonment. Migomail prioritises OTP messages in the send queue.
Post-purchase confirmation with order summary, line items, delivery estimate, and support link. Sent from your ecommerce platform via API or SMTP.
Secure password reset links with expiry time, requesting IP, and one-click invalidation. Critical for account security — slow delivery increases account-takeover risk.
Order dispatch and delivery milestone notifications triggered by warehouse events. Connects to your fulfillment system via API to fire on each status change.
Payment failures, subscription renewals, account threshold alerts, and system status notifications. Triggered programmatically by your backend with custom merge data.
Post-signup welcome emails and account activation messages triggered immediately on registration. Sent via API with account-specific merge data.
Whether your application uses direct HTTP calls, a mail library with SMTP, or a server-side SDK — Migomail connects without changing your existing code architecture.
// Send a transactional email via Migomail REST API
const response = await fetch('https://api.migomail.com/v1/messages', {
method: 'POST',
headers: {
'Authorization': 'Bearer migo_sk_live_••••••••',
'Content-Type': 'application/json'
},
body: JSON.stringify({
to: 'priya@example.com',
from: 'noreply@yourapp.com',
template: 'otp-verification-v3',
variables: {
otp_code: '847 291',
expires_min: 5,
user_name: 'Priya'
}
})
});
const { message_id, status } = await response.json();
REST API for direct HTTP sends, SMTP relay for existing mail library compatibility. Both use the same dedicated IP infrastructure, the same template engine, and the same analytics — so you can mix both methods across different services in the same account.
Production-ready SDKs for Node.js, Python, PHP, Ruby, and Java — each maintained in the Migomail GitHub organisation. SDKs handle authentication, request signing, retry logic, and response parsing. Each SDK has full TypeScript type definitions and inline documentation.
Store HTML templates on Migomail and send a template ID + variables per API call. Your application code contains no email HTML — design changes are deployed via the Migomail dashboard with no application code release required.
Dedicated sandbox API keys send emails into a delivery simulation environment — messages are processed through the full stack (authentication, template rendering, variable substitution) but not delivered to real inboxes. Use the sandbox for automated integration tests without sending to real subscribers.
Versioned REST API documentation with request/response examples for every endpoint, error code reference, rate limit specifications, SDK installation guides, and webhook payload schemas. Available at migomail.com/api-docs and searchable in-browser.
Every transactional message passes through four distinct infrastructure stages — each engineered for the lowest possible latency at that point in the delivery chain.
Your app sends a POST request to /v1/messages or connects via SMTP relay. Authentication, rate limiting, and payload validation happen here in under 100ms.
The template is fetched from storage, merge variables are substituted, conditional blocks are evaluated, and the final HTML is assembled. CSS is inlined for Outlook compatibility before dispatch.
The rendered message enters the dedicated transactional MTA queue. Connection to the recipient's mail server is established using pre-warmed SMTP connections. DKIM signing is applied before dispatch.
The message is accepted by the recipient's mail server. A delivery event is logged and available via API and webhook. The message ID can be used to query per-message status at any future point.
Most transactional email integrations are complex. Migomail's onboarding is designed to get your first production send live in under an hour.
Transactional email has completely different requirements from marketing email. These are the five dimensions on which purpose-built transactional infrastructure differs from a shared marketing ESP used for both.
For marketing emails, delivery within a few minutes is acceptable. For OTPs and payment confirmations, every second of delay directly increases abandonment and support ticket volume. Migomail's transactional MTA is engineered specifically for sub-2-second dispatch — with pre-warmed SMTP connections, priority queue processing, and no shared-resource contention from marketing campaign sends.
A marketing campaign with a 2% complaint rate — acceptable for a promotional send — will permanently damage the reputation of any IP it shares. Migomail enforces hard IP isolation between transactional and marketing sends at the MTA configuration level. No shared IP pools, no shared reputation exposure, no cross-contamination risk.
Marketing campaigns are measured in aggregate — open rate, click rate, bounce rate across the send. Transactional emails require per-message accountability: was this specific receipt delivered? Can I prove this specific OTP was sent? Migomail logs every transactional message with a unique ID, queryable delivery status, and timestamped events — for debugging, compliance, and SLA reporting.
Marketing teams use dashboards. Engineering teams use APIs, SDKs, and documentation. Migomail's transactional API is versioned, fully documented, available in a Postman collection, tested with a sandbox environment, and shipped with SDKs in 5 languages. The integration documentation is written for the engineer implementing it, not the marketer explaining what it does.
When a transactional email template needs updating — legal footer change, new brand guidelines, updated product image — most integrations require an engineering ticket, a code review, and a deployment. Migomail's server-side template engine lets the design team update templates via the dashboard, with the change live on the next API send, without any application code change.
Feedback from engineering leads, backend developers, and CTOs who integrated Migomail's transactional API into production applications.
We were using a popular marketing ESP for our transactional sends because it was what the marketing team already had. Our OTP delivery was averaging 4.2 seconds and we were getting about 8% support tickets from users who didn't receive their code. After migrating to Migomail's transactional infrastructure, our p95 OTP delivery is 1.3 seconds and those tickets essentially disappeared. The integration took about 3 hours including testing.
The server-side template feature is the one I wish every transactional email provider had. Before Migomail, every time legal or brand needed to update the footer in our transactional emails, it was an engineering ticket, a PR, a code review, and a deployment. That process took between 3 days and 3 weeks depending on sprint planning. Now the legal team goes into the Migomail dashboard, edits the template, and it's live on the next send. We've had zero engineering tickets for transactional email template changes in 8 months. That's a meaningful engineering-hours saving over a year.
The sandbox environment is what convinced me to choose Migomail during the evaluation. Every other provider's sandbox was either broken, not a real simulation of production, or didn't support webhooks. Migomail's sandbox runs the full stack — authentication, template rendering, variable substitution, DKIM signing — and fires webhooks to your test endpoint. I could write complete integration tests that covered the real sending flow without touching production. We caught 3 integration bugs in testing that would have caused production failures.
“Rackwave Technologies has significantly improved our marketing performance while providing reliable cloud services. We’ve been using their solutions for a while now, and the experience has been seamless, scalable, and results-driven.”
David Larry
Founder & CEO
Common questions about Migomail's transactional email infrastructure.
Transactional emails are triggered by a specific user action or system event — an OTP after login, a receipt after purchase, a password reset link after a request. They are sent to one recipient at a time, are expected by the recipient, and must arrive immediately. Marketing emails are sent in bulk to subscriber lists, are promotional or informational in nature, and have more flexible delivery time requirements. Migomail provides separate infrastructure for each type because they have fundamentally different latency, deliverability, and compliance requirements.
Migomail's transactional SLA is sub-2-second MTA dispatch at the 99th percentile — measured from API receipt to SMTP acceptance by the recipient's mail server. This does not include the time for the recipient's mail server to deliver the message to the user's inbox, which is outside Migomail's control and typically adds 0–30 seconds depending on the provider. For OTPs where immediate delivery is critical, our measured p50 latency is under 800ms.
Yes. Migomail provides an authenticated SMTP relay on port 587 with STARTTLS. Configure your application's existing mail library (Nodemailer, PHPMailer, Python smtplib, ActionMailer, etc.) with the Migomail SMTP host, your account username, and an API key as the password. The SMTP relay uses the same dedicated IP infrastructure and template engine as the REST API — the only difference is the protocol your application uses to connect.
You create a template in the Migomail builder or by importing HTML, give it a template ID (e.g., "otp-verification-v2"), and reference that ID in your API calls along with a variables object containing the merge values. At send time, Migomail fetches the current template version, substitutes all merge variables, evaluates any conditional blocks, inlines the CSS for Outlook compatibility, and dispatches the rendered HTML. To update the template design, you edit it in the Migomail dashboard — no application code change or redeployment required.
Yes, completely. Migomail enforces hard IP isolation between transactional and marketing sends at the MTA configuration level — not just at the user interface level. Your transactional emails use a dedicated IP pool with its own reputation history, DKIM signing domain, and Postmaster Tools monitoring. A reputation event on a marketing campaign (high complaint rate, sending to spam traps) cannot affect the delivery or reputation of your transactional IP pool.
Yes. Every transactional message receives a unique message_id in the API response. You can query the delivery status of any message by its ID via GET /v1/messages/{message_id} — the response includes queued timestamp, dispatch timestamp, provider acceptance timestamp (if available), open events, bounce outcome, and complaint flag. Message records are retained for 90 days on standard plans and 1 year on enterprise plans.
Yes. Configure a webhook endpoint URL in your account settings to receive real-time events for all transactional messages: delivered (accepted by recipient server), opened (tracking pixel fired), soft_bounce (temporary failure, retry scheduled), hard_bounce (permanent failure, suppressed), and spam_complaint (FBL report received). Each event includes the message_id, recipient, event timestamp, and additional context data. Webhooks are retried with exponential backoff if your endpoint returns a non-2xx response.
Official Migomail SDKs are available for Node.js / TypeScript, Python, PHP, Ruby, and Java — all maintained in the Migomail GitHub organisation with semantic versioning. Each SDK includes full type definitions, inline documentation, retry logic for rate limit and transient errors, and usage examples for the most common transactional use cases. A Postman collection covering all API endpoints is also available for teams that prefer API-client testing before integration.