A transactional message is an automated email (or SMS) sent to a single person to support an action they've taken — a password reset, an order confirmation, a shipping update, a double opt-in link, an appointment reminder, an account-security alert. The defining test is whether the recipient initiated the action that caused the message to fire. If they did, it's transactional; if they didn't, it's marketing, and a different set of consent rules applies.
The distinction matters legally. CASL in Canada and CAN-SPAM in the US both carve out transactional messages from the consent requirements that govern marketing email. That doesn't mean transactional sends are unregulated — they still have to be accurate, identifiable, and not misleading — but they don't need the explicit opt-in that a newsletter requires.
I keep transactional messages on a separate sending infrastructure from marketing messages. The reason is deliverability. Marketing email lives on a sender reputation that goes up and down with engagement; transactional email needs to land in the inbox every time, including for recipients who never open marketing mail. Most teams I work with use a dedicated transactional provider — Postmark, AWS SES, Mailgun's transactional pool, SendGrid's transactional plan — separate from the system that sends their newsletter.
The other reason to separate the two is operational. A failure in your marketing automation should never break a password reset. Keeping transactional sends on their own system, with their own monitoring and their own warmed IP, isolates the failure mode and makes it much faster to debug when something does go wrong.