Send from a name the guest knows
The sender is the first thing a guest sees and the main reason an invitation is opened or ignored. It should be the organiser — a person or the organisation — at a domain the guest associates with them. An invitation from a tool’s address, or from a generic no-reply, reads as a newsletter and is treated like one.
Sending from your own domain means proving you are allowed to: the domain has to be verified with the sending service, and its records set so receiving servers can check the mail really came from you. It is a one-time setup and it is the single biggest factor in whether the invitation lands in the inbox.
Deliverability is a list problem first
Receiving servers judge a sender by its history. A batch of invitations with a high bounce rate — dead addresses, mistyped domains, role addresses nobody reads — teaches them that your domain sends to bad lists, and the next batch lands in spam. Cleaning the list before sending is therefore not only about reaching those guests; it protects the delivery of every invitation after them.
Send in one pass, from one verified sender, to a list that has been checked. Do not send the same invitation from three colleagues’ mailboxes “to be safe”; three copies from three senders is a pattern that looks like exactly what it is.
The path of one invitation
- Verified senderYour name, your domain
- Clean listChecked before sending
- InvitationOne personal link
- DeliveredAccepted by the inbox
- OpenedSeen by the guest
- RSVPThe reply on their record
One link, and it should be theirs
The invitation should contain one link that does the work — the reply — and it should be personal to the guest. A personal link means the guest does not type their name into a form, does not create an account, and cannot answer for somebody else by mistake. It also means a forwarded invitation replies as the original guest, which is a reason not to add “feel free to forward this” to the text.
Everything else in the email — the calendar button, the map, the programme — is secondary and should look it.
Design from the event, not from a picture of it
An invitation made as an image in a design tool is correct on the day it is exported. When the start time moves by an hour, the image still says the old time, and the version already sent says it forever. Build the invitation from blocks that read the date, time and place from the event itself, so that a change to the event is a change to every unsent invitation, and so that a preview shows what a guest will actually receive.
Test the real email, to yourself, on a phone. Most invitations are read on one, and a two-column layout that looked fine on a monitor is a single column of tiny text on a screen the width of a hand.
Built from the event, read on a phone
Keep every version
When the venue changes, you send a correction, and now two versions of the invitation exist in the world. Keep both, with the date each was published and the list of who received which. It is the only way to answer “which invitation did the press list get?” a fortnight later, and the only way to know whether a guest who turned up at the old venue was working from the old email or the new one.
Every version kept, with who received it
- Version 1Sent to 180 guests
- Version 2 · new venueSent to 64 guests
- CorrectionSent to the 180 who had version 1
Resends and reminders
A resend is for a guest whose invitation did not arrive; a reminder is for a guest who has not replied. They go to different people and should say different things. Before either, read the delivery record: an address that bounced gets a different address, not a resend; an address that was delivered but never opened gets a reminder with a different subject line; an address that opened and did not reply gets the reminder as written.
Never resend to the whole list. The guests who replied will assume something changed.
Resend
The invitation did not arrive. Fix the address first, then send the same invitation again.
To: bounced addresses, with a new address
Reminder
The invitation arrived; there is no reply. A different subject line, the same personal link.
To: the silence only — never to those who replied
The delivery record
“Sent” means a mail server accepted the message. It does not mean the guest received it, and it is the least informative status there is. Insist on a record per guest that distinguishes queued, delivered, bounced, and suppressed — an address that asked never to be written to again — and read it the day after sending. The bounces are the guests you have not yet invited.
- A sender the guest knows, at a verified domain of your own.
- A cleaned list, sent in one pass from one sender.
- One personal reply link; everything else secondary.
- Blocks bound to the event, previewed as the real email on a phone.
- Every published version kept, with who received it.
- Resends to bounces with a new address; reminders to the silence only.
- A delivery record per guest, read the next day.
A record per guest, read the next day
| Guest | Status |
|---|---|
| Ayşe Yılmaz | Opened |
| Deniz Kaya | Delivered |
| Can Demir | Bounced |
| Elif Şahin | Suppressed — asked not to be written to |
| Mert Aydın | Queued |