Key takeaway
Event email marketing is the sequence of sends that takes somebody from not knowing your event exists to being in the room, and then onto a list worth mailing again. The message types are the easy part. One date drives every send, registrants want logistics while everybody else wants persuasion, and the date is the one thing in the campaign that nothing re-evaluates for you. Nitrosend works out who receives a send at the moment it sends, so a reminder scheduled on Monday will not reach somebody who registered on Tuesday. It does not work out the date. That asymmetry is the design problem, and it is why the approval step on each send is worth more here than on any other campaign: it is the only moment anybody is made to look at the calendar again.
What event email marketing actually is.
Event email marketing is the sequence of messages that takes somebody from not knowing your event exists, to being in the room, to being worth mailing again afterwards. Every guide to it is a list of message types, and the message types are the easy part. What makes an event campaign hard is that it has a deadline it can't move and two audiences that need opposite things from the same list. The event campaigns that go wrong are almost never the ones with a weak invitation. They are the ones where the reminder to people who had already bought a ticket goes out on the same stream as the promotion to people who had ignored three.
The conventional description is correct as far as it goes. An event campaign is a set of sends tied to one date, it mixes persuasion with logistics, and it ends with a follow-up that decides whether the list was worth building at all. The near-universal set is save the date, invite, confirm, remind, and follow up.
That's a description of an event campaign, not a design for one. It says nothing about who each message goes to, or about what happens to the other seven sends when the date on the first one changes. Those two questions are the job, and a platform answers one of them for you automatically and the other not at all.
Two audiences, and only one of them is being marketed to.
Somebody who hasn't registered is being persuaded. That message is marketing: it needs a visible unsubscribe, and the reader is free to make it stop. Somebody who has registered is expecting logistics, which is the confirmation, the joining link, the room number, and the time change. That person isn't a marketing recipient and the mail they need isn't a campaign.
Most event campaigns run both off one list with a date filter, and the failure mode is specific rather than theoretical. An unsubscribe from the promotion suppresses the joining instructions. A complaint from somebody who never registered lands on the same reputation the confirmations depend on. Registrants keep receiving the invitation they already accepted, which is a common reason for a ticket holder to mark event mail as spam.
The answer is two lists, or one list with a hard suppression rule behind it: a registrant leaves the promotional stream the moment they register, and joins a logistics stream that carries no promotional content at all. No upsell in the confirmation, no sponsor message in the reminder, and nothing in that stream a reader would want to unsubscribe from.
The split is easy to state and hard to hold, because the registration event lives in the registration system and the suppression has to happen in the email platform. If those two don't talk to each other, the rule is a note in somebody's head, and it lasts exactly as long as that person is watching.
Hold it as a rule rather than as a file. "Registered" and "invited but not registered" are filter conditions, and the next section is about why that distinction decides whether your reminders are still correct six weeks after you wrote them.
Six sends, and the audience changes underneath them.
An event campaign isn't a content calendar. It's one date with six sends hanging off it, and every send is scheduled relative to that date rather than to a day of the week. The conventional timings are worth stating plainly: the first invitation goes six to eight weeks out, reminders land a week before and again the day before, and the follow-up goes inside two days while people still remember the room.
What the timings don't tell you is who is on the other end, and that changes underneath you while the campaign runs. Somebody registers in week two, and every send after that is aimed at the wrong person unless registering moved them. Here are the six, in order, with the audience that each one belongs to.
| Send | Timing | Audience | Purpose |
|---|---|---|---|
| Save the date | First in the sequence | Everybody | No ask beyond the date itself |
| The invitation | Six to eight weeks out | People who haven't registered | The only send that is pure persuasion |
| The confirmation | Immediately, on registration | A new registrant | Logistics rather than a campaign |
| The reason to come | Between the invitation and the reminders | People still undecided | Carries the program rather than the pitch |
| The reminders | A week before, and again the day before | Registrants | About getting into the room rather than about buying a ticket |
| The follow-up | Inside two days | Split by who turned up | A no-show and an attendee need different mail |
Six sends assume nothing changes. The audience changes constantly, and the useful thing to know is that this half of the problem is already handled for you, at the last possible moment.
Build those audiences as segments rather than as exported lists. A segment is a filter the platform resolves when it needs to, and the documentation is unusually precise about when that is. Segment counts are refreshed in the background and are, in the docs' own words, "intended as an operational guide before sending", because final campaign audiences are "still evaluated at send time so the current subscription, suppression, and unsubscribe state is respected".
Read that twice if you run events. It says the number you were looking at while you drafted the reminder is not the number that will receive it. Somebody who registers on Tuesday drops out of Thursday's invitation without anybody editing anything, and somebody who unsubscribes on Wednesday drops out too. Neither is a bug you have to code around. It is the right answer arriving late, on purpose.
An exported CSV is the opposite of that. It is a photograph of an audience taken on the day you drafted the send, and on an event campaign the gap between the draft and the send is measured in weeks. The docs draw the line as a rule worth stealing whatever you send with: a saved view is how you like to inspect the contacts table, while a segment defines an audience that can be reused for sending. If a filter set should affect delivery, save it as a segment.
So the audience looks after itself. The date does not, and half the sends are wrong the moment it moves.
Put the event in their calendar, not just in the email.
A calendar file is a plain text object in a standard format. iCalendar, specified in RFC 5545, is the format of every .ics file, whether it arrives as an attachment or sits behind an add-to-calendar link, and it carries the start, the end, the location, and the description as fields rather than as sentences somebody has to retype.
That's worth more than any subject line you can write. A calendar entry produces a reminder from the reader's own device, and it keeps working after the mail is archived and the invitation forgotten.
Then there's the distinction almost everybody skips. iTIP, RFC 5546, defines the method types a calendar object's METHOD property can carry, and two of them do very different jobs. PUBLISH broadcasts an event and expects nothing back: the reader adds it and the transaction is over. REQUEST invites somebody to attend, and it expects a REPLY carrying acceptance or refusal.
A REPLY is mail arriving in the organizer's mailbox, so a REQUEST is a scheduling transaction rather than a marketing one. The thing that should issue it is the calendar or registration system that will handle the answer, and what belongs in your campaign is the file that system produces, attached and linked.
There's a second way to put a date in front of somebody, and it lands in the message itself rather than in an attachment. Gmail reads EventReservation markup embedded in the mail, in JSON-LD or microdata, and surfaces the date, the place, and the ticket in the inbox. The markup reference requires the event name, the start date, and a location carrying a full postal address.
Markup renders where the receiver supports it and nowhere else, so it's an upgrade to a message that has to work as plain mail first.
The date is the one thing nothing re-evaluates.
Here is the asymmetry that decides how an event sequence should be built, and I have not seen it stated plainly anywhere else.
The audience is late-bound. The schedule is not.
A scheduled campaign carries a literal timestamp. In Nitrosend that is scheduled_at, required whenever an agent calls nitro_control_delivery with the schedule operation, and it is a fixed point in time rather than an expression like "seven days before the doors open". Nothing recomputes it. There is no object sitting above the six sends that knows they all belong to the same Thursday in November, so when that Thursday becomes a Tuesday in December, six timestamps are six separate edits, and the one you forget is the one that sends.
The calendar standards solved this and the email ones never did. In iCalendar a change of start time is a versioned fact: RFC 5546 requires the sequence number to be incremented whenever the start, the end or the duration changes, and RFC 5545 defines that number as starting at zero and rising on every significant revision. A recipient's calendar can therefore tell that the version it is holding is stale. A scheduled email carries no equivalent, because the date on a campaign was never a claim about an event. It was a claim about when to send. Move the event and the send date is not wrong in any way a machine can detect. It is just early.
There is a second edge here and it bites late. A campaign stops being editable before it sends, not when it sends. The documented lifecycle is exact: a draft has full edit access, a scheduled campaign stays editable until five minutes before send with a countdown banner appearing fifteen minutes before the lock, and inside that final five minutes the only moves left are cancel and duplicate. Once it has gone, a content edit comes back as a campaign_locked error with one suggestion, which is to duplicate it.
On a newsletter that window is a formality. On an event it is the shape of the problem, because your ability to change a send shrinks as the send approaches, and that is precisely when the news most likely to change it arrives. A venue does not move eight weeks out. It moves on the Tuesday.
And the fix path has a cost nobody warns you about. Duplicating a campaign copies the audience and the content. It does not copy the schedule or the approval, and the copy starts clean as a draft awaiting review. Rebuild a locked reminder for the new date and it lands back at the beginning: unscheduled, unapproved, waiting for a person. Moving an event date is not six edits. It is six edits and six approvals, and the approvals are the part that runs out of hours.
The email you hope you never send.
The date moves. The venue changes. A speaker pulls out, or the whole thing is canceled with a week to go.
A change message isn't a campaign. It goes to the people holding a ticket, it carries one fact, and it has to arrive. In calendar terms this is what CANCEL and a re-issued REQUEST exist for, which is again the point where the job belongs to the system that owns the booking rather than to the platform running the campaign around it. Note what the re-issue carries that your email does not: a higher sequence number, which the recipient's calendar can act on by itself. Your message carries nothing but the words you chose, which is why the words have to do all of it.
This message is the strongest argument there is for the two-stream split. If a registrant is sitting on the promotional stream, an unsubscribe they clicked in week two decides whether they find out in week six that the venue moved. Suppression is correct behavior for a campaign and the wrong answer for this, and the way out isn't to override the suppression. It's to never have put the message on that stream.
Write it before you need it. A subject line that names the change, one fact in the first line, no design, no offer, no cross-sell, and no attempt to recover the moment. Send it from the same address that sent the confirmation, because that's the thread the reader will search for when they go looking.
Email isn't a delivery guarantee, so a cancellation inside 24 hours needs the phone number you collected at registration and never used.
The campaign is a volume spike, and the reminders are where it hurts.
An event campaign concentrates months of sending into six weeks. It usually drags in a re-activation of last year's list, and it points all of that at the same few thousand addresses. The result is a spike in volume, a fall in average engagement, and a rise in complaints, all arriving at once.
The reminders do most of the damage. A fifth message about the same event, to somebody who never intended to come, is what the complaint button is for, and the complaint is charged against the domain that also sends your confirmations. Four thresholds decide whether any of this arrives, and they're worth having in front of you before the invitation goes out rather than after the follow-up. The exact shape I've seen spike a complaint rate fastest is a list gone quiet for a year suddenly getting three or four emails a week as the event approaches, which describes a reminder campaign almost exactly.
- Spam rate: below 0.10% in Postmaster Tools, and never 0.30% or higher, per Google's sender guidelines, for senders above 5,000 messages a day to personal Gmail accounts.
- One-click unsubscribe: required on marketing and subscribed mail, alongside a clearly visible unsubscribe link in the body.
- The header behind it: the pair defined in RFC 8058, signed so a receiver can post to it directly.
- Authentication: SPF, DKIM, and DMARC on the sending domain, with the From header aligned to one of them.
Honoring the request has its own clock: Yahoo asks bulk senders to action an unsubscribe within two days, which is shorter than most event campaigns leave between a reminder and the send after it.
A threshold you cross during the campaign is one you find out about after the event, which is one more reason the promotion and the confirmations don't share a stream.
Move the date and everything moves.
Every send in this campaign is defined relative to one date. Not one of them is defined by a calendar day. The six become eight once the reminders split in two and the follow-up splits by who turned up, and every platform makes you schedule those eight as separate things, with eight separate dates typed in by hand.
Move the date and you're editing eight sends, a segment rule, and a landing page. The one you miss is the one that goes out on the old Tuesday, to the people who already hold a ticket for the new one.
The sequence is data and it has one variable in it. Nothing about the design of a dashboard admits that, because a dashboard is built around the screen you're looking at rather than around the object you're editing. Describe the campaign once as an object with a date on it, tell your agent to move the date, and let the sends follow. That's why every capability here is an API endpoint and an MCP tool before it's a screen.
But an agent introduces a failure the dashboard era didn't have, and it is specific to date-pinned work.
A person running an event sequence checks the calendar before every send, because they can't help it. They open the thing, they see the date, they remember the date moved. An agent doesn't. An agent acted once, when you asked it to, and unless something makes it look again it won't. Nothing in a scheduled campaign asks a question at send time except the audience query, and the audience query doesn't care what day the event is on.
The thing that makes it look again is the gate, and the gate here isn't a setting you switch on. It is where the tools are cut. nitro_compose_campaign creates or edits a draft and never delivers it. nitro_compose_flow never activates one. Delivery runs through nitro_control_delivery, where approving and going live are separate operations, scheduling is campaign-only and needs its own timestamp, and an all-contacts audience needs an explicit confirmation on top. Approval, Safe Mode and that confirmation are three separate checks, and the docs say so outright.
Humans approve. Agents operate. On most campaigns that line is about safety. On an event campaign it is about the calendar. The approval step is the only point in the sequence where a person is put in front of a send with its date attached, and on a sequence pinned to a date that can still move, being made to look is the whole value. Strip the gate out in the name of autonomy and you haven't automated an event campaign. You've arranged for a reminder about last Thursday to arrive on Friday.
One trap on the composing side, because an agent will hit it and a person won't. A full replace on a campaign clears an audience or a schedule you left out of the call. An agent rewriting the copy of a reminder and not restating the send time doesn't error. It unschedules the send. On an ordinary campaign you notice, because the newsletter you expected on Tuesday is still sitting in drafts on Wednesday, and you send it Wednesday. On an event there is no Wednesday version of the day before the conference. A send whose window closed isn't late, it is gone, and a reminder that arrives after the room emptied is worse than none, because it tells everybody holding a ticket that nobody was watching.
So the split of work on an event isn't the one the marketing implies. Let the agent hold the sequence, rebuild it when the date moves, and re-derive the audience it can re-derive. Keep the approval, and read the date on it.
The date lives in two places and only one of them is the email platform. Changing it here moves the sends; the tickets, the registration record, and the calendar object still belong to the system that issued them.
An event campaign is the clearest case for treating a schedule as data and an audience as a filter, and that's the platform Nitrosend is: email your agent drives, not a dashboard with an AI button on it. The free tier is enough to build the whole sequence before you sell a ticket: 8,000 emails to start, then 500 a month, unlimited contacts, and full MCP, API, and CLI access, with no credit card. Build the confirmation and the change message first, because those are the two that decide whether the list survives the event.
Sources
- RFC 5545: iCalendar, the object format behind every calendar file attached to or linked from an event email.
- RFC 5546: iTIP, the
METHODvalues that separate a published event from an invitation expecting a reply, and the rule that a change of start time, end time or duration must increment the sequence number. - Nitrosend docs, Segments: segment counts as an operational guide, final campaign audiences evaluated at send time against subscription, suppression and unsubscribe state, and the saved view against segment distinction.
- Nitrosend docs, Campaigns: the editable-until-five-minutes-before lifecycle with its fifteen-minute countdown, the
campaign_lockedresponse, and what duplicating a sent campaign does and does not copy. - Nitrosend docs, MCP tools: composing a campaign never delivers it, composing a flow never activates one, and the schedule operation and its required timestamp on
nitro_control_delivery. - Nitrosend docs, MCP examples: approval, Safe Mode and the all-contacts confirmation as three separate checks on a live send.
- Gmail markup, Event Reservation: the required properties for surfacing an event's name, start date, and address in the inbox.
- Google, Email sender guidelines: the 0.10% spam rate target and the 0.30% never-exceed line, the 5,000-a-day threshold to personal Gmail accounts, one-click unsubscribe, and the SPF, DKIM, and DMARC requirement.
- Yahoo Sender Best Practices: unsubscribe requests actioned within two days, alongside Yahoo's authentication requirements for bulk senders.
- RFC 8058: the signed header pair that makes a one-click unsubscribe work without a landing page.
Common questions
Usually a webhook. The registration or ticketing system fires one the moment a ticket is issued, and the email platform turns it into a suppression: the new registrant drops out of the promotional audience and joins the logistics stream carrying the confirmation, the joining link, and any change of date. Until that handoff exists the split is a manual list edit somebody has to remember, which is why registrants keep receiving the invitation they already accepted.
No. Every scheduled send carries its own timestamp and nothing recomputes it from the event date, so each one is a separate edit. The window is shorter than people expect too: a scheduled campaign stays editable until five minutes before it sends, and once it has sent the only route is to duplicate it, which copies the audience and the content but not the schedule or the approval. Budget for the approvals as well as the edits.
A segment. Nitrosend evaluates a campaign's final audience at send time against current subscription, suppression and unsubscribe state, so a reminder scheduled weeks earlier still reaches the right people. An export is a snapshot taken on the day you drafted, which on an event campaign is weeks before anything sends.
Six is the usual shape: a save the date, an invitation, a confirmation to each new registrant, a program send for the undecided, reminders close to the day, and a follow-up. The count matters less than the split. Once somebody registers they should stop receiving the promotion and start receiving the logistics.
The convention is six to eight weeks before the date, with a save the date earlier than that if people need to book travel or clear a diary. Reminders land a week out and again the day before. Anything much tighter and you're relying on a single send landing at the right moment.
No. An unsubscribe from the promotional stream is a valid opt-out, and if the confirmations share that stream it suppresses the joining instructions too. Worse, it suppresses the message telling a ticket holder the venue moved. Keep registrants on a logistics stream that carries no promotional content.
Yes, and the method matters. A calendar file with <code>METHOD:PUBLISH</code> broadcasts the event: the reader adds it and nothing comes back. <code>METHOD:REQUEST</code> is an invitation that expects a reply in the organizer's mailbox, so it belongs to whichever calendar or registration system is going to handle that answer.
One message, to the people holding a ticket, carrying one fact. No design, no offer, and no attempt to sell the new date in the same breath. Send it from the address that sent the confirmation, because that's the thread the reader will search for, and write it before you need it.
The promotional sends do: a clearly visible unsubscribe link in the body, plus one-click unsubscribe support in the headers if you're sending in bulk. The transactional side is different. A confirmation or a joining link goes to somebody who asked for it, and it isn't a marketing message.
Split it by who turned up. Attendees get the recording, the slides, or the photos, and one clear next step. No-shows get the same material with an acknowledgment that they missed it, which is often the higher-converting of the two. Both segments then rejoin your ordinary list rather than staying an event list forever.