Email goes out three ways: a campaign you send or schedule, a journey’s send step when a contact reaches it, or a transactional send from your app. Each path checks the sending domain and applicable eligibility rules just before the email leaves. Marketing email also requires email consent.
From a campaign
- In the campaign’s Details, under Channels, choose Email (or email and push).
- Choose the audience, then write the email in the Email step. See Create an email.
- On the review step, Who receives it shows how many people the email reaches, and how many Don’t send to leaves out.
- Choose Save and send… or Save and schedule…, check who it reaches, and confirm.
You can schedule it for one moment or for each contact’s own local time. See Schedule and send a campaign.
Before a campaign can send email, Kirora checks that its sender’s domain is verified and has a DMARC record, which Kirora requires for marketing email, and that your postal address is set. Anything missing shows under Fix before sending, with a link to fix it. For a missing DMARC record, it says: Add a DMARC record to the sender domain. Gmail and Yahoo require one for marketing email.
From a journey
Add a send step and set it to email. Each contact who reaches the step gets the email then, after the step checks their consent, topic and suppression. See Set up a send step.
- Topic: optionally pick one, so contacts who left that topic are skipped.
- Transactional email: tick it for a receipt or reminder the contact asked for, such as a booking confirmation. It goes without email consent, quiet hours or message limits, and has no unsubscribe link. Only addresses that bounced, or marked transactional email as spam, are skipped. Never use it for promotions.
- If they can’t receive this, go to: a path for contacts without email consent, with a suppressed address or outside the step’s topic, for example a push step. Without one, they skip this email and carry on.
- If it can’t be sent, go to: a path for when the email can’t be queued. A bounce comes later and doesn’t branch.
From your app (transactional)
Receipts, password resets and sign-in codes are sent by your server through the API, from a template you design and publish in Kirora. Your developer sends each one with the template’s ID or alias. See Templates your app sends and the developer guide to transactional messages.
It follows different rules from marketing email; see the table below.
The Transactional page shows a Delivery report and the Delivery history of each message. See Understand your reports.
Marketing email and transactional email
| Requirement | Marketing (campaigns and journeys) | Transactional (your app) |
|---|---|---|
| Email consent | Required | Not required |
| Unsubscribe link | Always added | Optional; hide it on the template’s footer |
| Quiet hours and message limits | Apply | Don’t apply |
| New-sender daily limit | Applies | Never |
| Paused for bounces or complaints | Yes | No |
| DMARC record on the domain | Required | Not required |
| Suppressed addresses | Skipped | Skipped, after a bounce or a spam report on a transactional email |
| New account’s daily email limit | Applies | Applies |
What can delay or hold email
- Quiet hours and message limits: campaign and journey email can wait for quiet hours to end, and a contact over your message limits is skipped or waits for room, as the campaign chooses.
- The new-sender limit: past today’s limit, the rest goes over the next days. See How a new workspace starts sending.
- A new account’s daily email limit: a campaign bigger than what’s left of today’s limit is refused, not split. See What can delay messages.
- A marketing pause: campaign and journey email waits, held and not lost, until an admin or the owner resumes it. See If marketing email pauses.