Setting Up Transactional Email for a SEA Product: A Relay Playbook (SMTP2GO Worked Example)
A SEA product sends three kinds of mail that customers actually need: receipts, password resets, and order or shipping notices. When one of them lands in spam, the user does not blame the mail server. They contact support, or abandon the purchase. This playbook walks through wiring those messages through a relay, with SMTP2GO as the working example, and covers where the free tier runs out and how to tell a delivery problem from a reputation problem. Everything attributed to SMTP2GO, Postmark and Amazon SES comes from their public pricing, features and help pages as opened on 4 November 2026; nothing was sent through any of them for this piece.
What does a transactional relay actually do for a SEA product?
Your application hands a message to the relay over SMTP or a REST API. The relay delivers it to the recipient's mailbox provider, signs it, and records what happened. SMTP2GO's homepage describes SPF and DKIM as "handled automatically for your domain names," and its pricing page lists real-time analytics and bounce tracking on every plan.
This is a different job from a newsletter or campaign tool. SMTP2GO has no campaign builder, list management or automation, so a team that needs those is shopping in another category. Receipts and campaigns can coexist in one business on two different tools.
Does SMTP2GO send from Singapore?
Read this one carefully before it influences a decision. SMTP2GO's features page lists Singapore among its server locations, alongside Sydney, Christchurch, Chicago, Frankfurt, London and others. The same page, however, describes data centers "in all three regions" and says data is "stored in the region of your choice." Those three regions are not named as Singapore, and the page does not say that you can pick Singapore as the region for your account.
So the verified statement is narrower than "Singapore sending region": Singapore appears in a list of server locations. If latency or data residency matters to your product or your buyers, ask support, in writing, which region your account sends from and stores logs in before you build on the assumption. Separately, SMTP2GO's sending-limits page gave no region-specific information.
How do you set up SPF and DKIM for the sending domain?
Generic mechanics first. SPF is a DNS record listing which servers may send for a domain; the receiving server checks it against the message's Return-Path domain. DKIM is a cryptographic signature the sender attaches, which the receiver verifies using a public key published in DNS. DMARC sits on top and tells receivers what to do when both checks fail to align with the visible From domain.
SMTP2GO does it with CNAME records instead of asking you to edit your SPF TXT record. Its SPF article says it uses a CNAME-based approach with a variable envelope return-path, and that your public SPF record stays clean. Its sender-domain article says three CNAME records are added, covering SPF, DKIM, and open/click tracking.
- Pick the sending subdomain policy. Many teams send app mail from a subdomain such as a "mail" or "notify" prefix on their main domain, so a problem there does not touch the staff mailboxes on the root domain. This is a common practice, not an SMTP2GO requirement.
- In the dashboard, go to Sending, then Verified Senders, then the Sender domains section, and add the domain.
- Copy the three CNAME records exactly as shown into your DNS host. Check that your DNS provider does not append the domain name twice to the host field, a frequent cause of failed checks.
- Wait for propagation, then recheck the status. SMTP2GO's guidance is that records can flip between verified and unverified while updates propagate.
- Send a test message from your app to a mailbox you own and open the full headers. Look for SPF and DKIM both showing pass and aligned with your From domain.
- Add a DMARC record at the end, starting with a monitoring-only policy, and tighten it only after reports show your legitimate mail passes. SMTP2GO has its own DMARC support article; the generic order of monitor first, enforce later holds with any provider.
The alternative is a single sender email, which is verified by clicking a link. SMTP2GO's own article says the drawback is that the domain will not align with SPF and DKIM, so for a production product, verify the domain.
Which messages go through the relay, and in what order?
Move the mail in order of risk. Password resets first: they are time-sensitive and any failure is visible within minutes. Receipts second. Shipping and order notices last, because they are the highest volume and the most likely to expose a limit. Keep each type recognisable in the subject line and, if your tooling allows, tag or separate them so the activity log can be filtered per type later.
Keep marketing mail off this path. Mixing promotional sends into the stream that carries password resets is how a complaint spike on a promotion delays a reset.
Where does the free tier end?
As read on the pricing page: the free plan covers up to 1,000 emails a month with no credit card. SMTP2GO's sending-limits article adds 200 emails a day and 25 an hour on the free plan, with the hourly cap removed once a domain is verified. Its sender-domain article says the free plan allows 5 verified senders in total.
Starter is USD 15 a month (USD 150 a year) for 10,000 emails, with overage at USD 1.20 per thousand. Professional is USD 75 a month (USD 750 a year) for 100,000 emails with a dedicated IP address and overage at USD 0.85 per thousand. Annual plans are described as two months free, and invoices are in US dollars.
What ends testing in practice is the daily cap, not the monthly one. The sending-limits page says that when the monthly allowance is exceeded, sending stops at 100% (or 300% with the overage allowance) and excess emails are rejected rather than queued. A product that sends a flash-sale burst of order confirmations on a free account would hit the daily ceiling first. If your product has any seasonal peak, upgrade before it, not during it.
How do you tell a delivery problem from a reputation problem?
Treat these as different failures with different fixes.
A delivery problem is specific to a message or address. SMTP2GO's troubleshooting guide points you to Reports, then Activity, where each message has a timeline ending in delivered, soft bounce or hard bounce. It lists common error codes: 452 4.2.2 means the recipient's mailbox is over quota, 550 5.1.1 means the recipient address is invalid, and a DNS lookup failure means the domain has no MX records. Those are fixed by correcting the address list, not by touching DNS. The guide also says to check Reports, then Suppressions, because hard bounces lead to a 7-day suppression.
A reputation problem is a pattern. Signs: otherwise valid addresses at one large mailbox provider start bouncing or landing in spam together; messages show as processed but never delivered; or the sending domain or IP shows up on a blocklist. The troubleshooting guide suggests scanning blocklist databases with a tool such as MXToolbox. Fixes are slow and behavioural: stop sending to unengaged or unconfirmed addresses, remove spam-like content, separate transactional from promotional mail, and keep the sending volume steady.
Our note, not SMTP2GO's: no provider removes the dependency on sender reputation, content and consent. The relay gives you the diagnostics. It does not fix a bad list.
What are the alternatives, and who should not pick SMTP2GO?
Postmark's pricing page lists a free developer plan of 100 emails a month that does not expire, and a Basic plan at USD 15 a month for 10,000 emails with overage at USD 1.80 per thousand. Amazon SES lists outbound email at USD 0.10 per 1,000 for accounts not on a plan, plus USD 0.12 per GB of attachment data, and new AWS customers get up to USD 200 in credits for 6 months. SES is a build-it-yourself option for teams already on AWS; the pricing page does not describe a dashboard comparable to SMTP2GO's. Brevo is also worth pricing if you want transactional and marketing mail under one login. Its pricing details were not readable from the pages fetched for this post, so check them directly.
SMTP2GO is probably the wrong pick if:
- You need campaigns, newsletters or automations. It does not do them.
- You need a confirmed, selectable Singapore region for residency reasons. The page evidence above is not enough to promise that.
- You want a local-currency invoice or local payment rail. Invoices are in US dollars, and the pricing page lists USD, EUR, GBP, AUD and NZD as currency options.
- Your volume is a few hundred emails a month. Postmark's free plan covers 100 emails a month, so a few hundred would need its paid plan, while SMTP2GO's free plan allows 1,000 a month. That is a point in SMTP2GO's favour at that size, within the 200-a-day cap.
SMTP2GO's pricing page also carries a 30-day money-back guarantee, which lowers the cost of a trial on a paid tier.