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 immovable date drives every send, and registrants want logistics while everybody else wants persuasion. Run both on one stream and an unsubscribe from the promotion kills the joining instructions. I'd collect a phone number for the cancellation inside 24 hours.
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. I've been building email platforms for over a decade, and the event campaigns I watched go wrong were almost never the ones with a weak invitation. They were the ones where the reminder to people who had already bought a ticket went 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, and the who is the entire problem.
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 the most common reason I've seen a ticket holder 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.
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 programme 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. Half of them are wrong the moment the date moves, and none of them survives a cancellation.
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 organiser'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 email you hope you never send.
The date moves. The venue changes. A speaker pulls out, or the whole thing is cancelled 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.
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 behaviour 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.
Honouring 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 suppression 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. Every existing email platform was designed for humans clicking buttons, and an event campaign is where that shows. Bolting an agent onto a dashboard-first product doesn't fix it, because the object the agent needs to edit was never there. 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 what running your whole email stack from one agent command means, and it's why every capability here is an API endpoint and an MCP tool before it's a screen.
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 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, and the
METHODvalues that separate a published event from an invitation expecting a reply. - 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.
Six is the usual shape: a save the date, an invitation, a confirmation to each new registrant, a programme 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 organiser'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 acknowledgement 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.