Transactional email

Receipts, password resets and shipping notifications are a different kind of mail from a newsletter, and they need different handling. This page explains the distinction, why keeping the two streams separate protects both, and how transactional sending fits alongside your campaigns.

The distinction in plain terms#

Transactional mail goes to one person because of something that person did. They bought something, so they get a receipt. They clicked "forgot password", so they get a reset link. They booked an appointment, so they get a confirmation. The recipient is expecting it, usually within seconds, and often cannot complete what they started without it.

Marketing mail goes to a list. You decide the content, you decide the audience, you decide the moment. Nobody is sitting there waiting for your newsletter, and nobody is blocked when it is late.

Two practical tests, when a message is ambiguous:

• Who chose the timing? If the recipient's action set the clock, it is transactional. If you set the clock, it is marketing.
• Can they opt out? Marketing mail must carry an unsubscribe link, because the recipient consented to receive it and can withdraw that consent. Transactional mail is part of a transaction they initiated, so there is no list to leave. You cannot unsubscribe from your own password reset.

Why you keep the two streams apart#

Mailbox providers build a reputation for the source that sends mail. That reputation follows the sending domain and the sending infrastructure, not the individual message. If both streams share a source, everything that happens to one happens to the other.

Consider the ordinary case. You send a promotion to 40,000 people. A fraction of them, having forgotten they signed up two years ago, hit the spam button. Complaint rate rises. The provider starts filtering mail from that source more aggressively.

Now a customer clicks "forgot password". Their reset email lands in spam or gets delayed by twenty minutes. They cannot get into their account, so they contact support. A marketing decision has turned into a support cost and a customer who cannot use your product.

Separating the streams contains that blast radius. The usual pattern is a dedicated subdomain for each: something like news.yourdomain.com for campaigns and mail.yourdomain.com for operational messages, each with its own SPF, DKIM and DMARC records. A complaint problem on the marketing subdomain then stays on the marketing subdomain.

The separation is worth setting up before you need it. Reputation takes weeks to build and recovers slowly, so splitting the streams after a problem starts does not fix the problem quickly.

How transactional sending works here#

Transactional sending is available over SMTP relay. Your application connects to the relay and hands over a message, in the same way it would talk to any other mail server. Your code composes the message, because your code is the only thing that knows the order total, the reset token or the appointment time.

That is a different model from campaigns. A campaign is content you author in IGSendMail and address to a list. A transactional message is content your application generates and addresses to one person. The API endpoints documented in Subscribers API and Campaigns API are for the campaign side of that split: they manage contacts, build campaigns and return reporting. They are not a send-one-message endpoint, and using a one-contact campaign as a substitute for a receipt is the wrong shape for both.

Connection details and credentials for the relay come from your account area. Configure them in your application's mail settings the way you would any SMTP server, and keep the credentials in environment variables rather than in your source code, for the same reasons set out in API authentication.

Practical rules#

Send transactional mail immediately. A password reset that arrives in ten minutes is close to useless, because the person has already requested another one. Do not queue operational mail behind a batch job.

Keep the content minimal. State the fact, give the link or the number, stop. Short operational messages render correctly everywhere, including on watches and in text-only clients.

Log what you send. When a customer says they never got the receipt, you want a record showing the address it went to and the time. That is your own application's job.

Do not add transactional recipients to a marketing list. Somebody buying a product is not consent to receive your newsletter. If you want them on the list, ask them, and record when and how they said yes.

Watch the reply-to address. People reply to receipts with real questions. Point the reply-to at a mailbox somebody reads.

If something goes wrong#

Reset emails are slow or missing. Check your application logs first to confirm the message was handed off at all. A large share of "the email never arrived" reports are a failed call inside your own code.

Transactional mail lands in spam. Check that the sending domain is authenticated, and check whether the same domain or subdomain is also carrying marketing volume. If it is, splitting them is the fix.

Customers say a receipt looks like a phishing attempt. Usually the sender address does not match the brand they bought from, or the link points at a domain they do not recognize. Send from a subdomain of your own domain and link to your own domain.