Collecting emails on every trip

You cannot check whether an email address is correct. That is not a limitation of your software, it is a property of the system: the standard states that the part before the at-sign must be interpreted and assigned semantics only by the host named after it. Nobody else gets a vote, including you, including the form on your website. Which means the address you scribbled on a waiver at the ramp is either right or silently useless, and you will not find out for months. The whole problem of collecting addresses reduces to that one fact, and so does the solution: confirm at the moment of collection, while the person who owns the address is standing in front of you. Everything downstream of a clean list is covered under the getting-booked hub.

Why can nobody validate an address?

Because the rule says only the destination host may interpret it.

The specification is unambiguous, and it explains the reasoning: after a long history of problems when intermediate hosts tried to optimise transport by modifying addresses, the local part became the exclusive business of the host in the domain part.

It goes further on a detail almost nobody knows. The local part must be treated as case sensitive, and implementations must take care to preserve the case.

Its own example is that for some hosts, the user named in lower case is a different user from the same name capitalised.

The specification adds that exploiting that case sensitivity impedes interoperability and is discouraged, which is a warning to system builders rather than a promise to you.

Domains, by contrast, follow ordinary naming rules and are not case sensitive.

So the half of the address you might be tempted to tidy up is the half you must not touch.

The specification is RFC 5321, published by the IETF.

Calcasieu Charter Service, LA

What counts as a valid address anyway?

Far more than any form on your site accepts.

The reference document on checking names lists what may appear in a local part without any quoting: letters, digits, and the characters exclamation mark, hash, dollar, percent, ampersand, apostrophe, asterisk, plus, minus, slash, equals, question mark, caret, underscore, backtick, brace, pipe and tilde.

A full stop may appear too, but not at the start or end, and never twice in a row.

It states plainly that in local parts the apostrophe and the acute accent are ordinary characters rather than quoting characters, which is why a client named O'Brien has a valid address that half the forms on the internet reject.

It gives real examples that look wrong and are not, including addresses containing a plus, a slash, a dollar sign and an underscore.

Its conclusion is the operative one: since there is no way to know whether the remote host is using those characters for special handling or treating them as ordinary text, programs evaluating validity must simply accept the strings and pass them on.

There is one hard limit worth knowing: 64 characters before the at-sign, 255 after it, 320 in total.

The document is RFC 3696, published by the RFC Editor.

Is there anything you can check?

One thing: whether the ending exists at all.

The naming authority publishes the complete list of top-level domains as a plain text file, updated continuously.

The copy read for this piece carried a version stamp of 26 July 2026 at 07:07 coordinated universal time and contained 1,438 entries, running alphabetically from the first three-letter entry to the last two-letter country code.

That file answers exactly one question, and answers it definitively: does the ending somebody typed exist.

Which catches the single most common transcription error, meaning a mistyped or invented ending, and catches nothing else.

It will not tell you whether the domain is registered, whether the mailbox exists, or whether the person typed their own address rather than a friend's.

A tool that claims to verify addresses is mostly doing this check plus some guesses, and the guesses are the part that removes real clients from your list.

The list is published by IANA as the delegated top-level domain file.

So how do you actually get one right?

Have the owner type it, then send something while they are there.

Every reliable collection method is a variation on those two steps, and every unreliable one skips the second.

Typing it themselves removes your handwriting and your hearing from the chain, which is where most errors enter.

Sending something immediately, even a one-line message with a photograph attached, converts an unverified string into a confirmed address within seconds.

If it bounces while they are still on the dock, you fix it in ten seconds instead of losing them for two seasons.

That is the whole method, and it is why the moment of collection matters more than the number of collection points.

What that first real message should contain is set out in the welcome sequence piece.

Whitney's Almost Everything, TX

What is the best moment on a trip?

The photo handoff, and it is not close.

At the end of a good day everybody aboard wants the pictures, which means for about ninety seconds the client wants something from you rather than the other way round.

Ask them to type their address into your phone so you can send the photographs, and the address arrives typed by its owner, with a reason attached.

Send one photograph before they leave the dock and the confirmation happens on the spot.

Compare that to asking for an address so you can add them to a newsletter, which is the same request with the benefit removed.

The other advantage is that you reach everybody aboard rather than only the person who booked, which on a group trip triples what you collect.

Be straightforward about what else you will send and how often, because a surprise is what produces a complaint later.

What you are allowed to do with those pictures is covered in the photo permission piece.

What about the booking form?

It is already collecting them, correctly, and nobody uses them.

Almost every booking system captures an address because it needs somewhere to send the confirmation, and that address was typed by its owner and demonstrably works.

It is therefore the highest quality list an operation owns, and it usually sits in the booking system unexported and unused.

Getting it into whatever you actually send from is a one-off export rather than a project, and it is the single fastest improvement available to most operations.

Do it once, then set a recurring reminder to do it again, because the export is a snapshot rather than a connection unless your tools are linked.

While you are there, note which of those addresses have never received anything from you, since they are the ones most likely to mark a first message as unexpected.

Warm them up with something genuinely useful before anything that reads as a campaign.

Sorting them into groups afterwards is described in the segmenting piece.

Does a website signup form still work?

Yes, if it offers something other than news.

A box asking people to subscribe for updates collects almost nothing, because nobody wants updates from a business they have not used.

A box offering something specific to the water you fish collects steadily, because it trades a real thing for the address.

What that thing is matters less than whether it is genuinely useful and impossible to find elsewhere.

A seasonal calendar for your particular stretch, a short guide to what to bring in each month, or the honest answer to the question every enquiry asks are all fine.

Confirm the address by sending the thing immediately rather than by promising it later, which is the same principle as the dock.

And keep the form to one field, because every additional field is a reason to close the tab.

Ideas for what to send afterwards are collected in the newsletter ideas piece.

How should the address be stored?

Exactly as typed, in one place.

Given that the local part is case sensitive by rule, do not lower-case addresses on the way in, and do not let a spreadsheet autocorrect anything.

Keep the source and the date next to each address, because in a year you will want to know whether somebody came from a trip, a form or an enquiry.

One place matters more than which place: an operation with addresses in a booking system, a phone, a notebook and two spreadsheets effectively has none.

Consolidating is unglamorous work that takes an evening and makes every later decision possible.

Keep a note of anybody who asked not to hear from you, and keep it in the same file, because that list is the one you cannot afford to lose.

Then stop collecting into anywhere else, which is a discipline rather than a tool.

What happens when the sending side is misconfigured is explained in the deliverability piece.

What do you do with the ones that bounce?

Read the code, then stop sending.

A permanent bounce is telling you the address does not work, and continuing to send to it damages how the rest of your mail is treated.

Remove it from the list rather than leaving it in place hoping it recovers, and note the client's name so you can ask them next season.

Where the address came from a photo handoff you may still have the client's phone number, which is the cheapest way to fix it.

Resist the urge to guess a correction, since the rule above means you cannot know what the destination host considers valid.

A single character you assume is a typo may be exactly how that mailbox is spelled.

Ask instead, in one line, which takes less effort than the guessing does.

What bounces mean in detail is covered in the spam and bounce piece.

What about the people who enquired and never booked?

A different list, and a more careful one.

An enquiry that went nowhere is not the same as a client, and treating the two identically is where most complaints originate.

Somebody who asked about a date you could not cover has given you their address for one purpose, and nothing more was agreed.

That does not mean the address is useless; it means the first message they receive should acknowledge what actually happened.

A short note when the season they asked about comes round again is welcome. A newsletter arriving from a business they never used is not.

Keep them tagged separately so the difference survives the next tool change, because a merged list cannot be unmerged.

And if somebody enquired two seasons ago and never replied to anything since, treat their silence as the answer it is.

The practical version is one message a year, written as a person rather than as a campaign.

What that seasonal message looks like is set out in the gift certificate piece.

Should you use a tablet, a form or paper?

Whatever the client can type into with wet hands.

The device matters less than the property that the owner of the address is the one entering it.

A phone handed over works, a tablet in a dry bag works, and a form on your site that you open for them works.

Paper works only if you type it up before they leave, which in practice means it does not work.

Whatever you use, keep the field wide enough to show the whole address, because a client cannot proofread what they cannot see.

Turn off any automatic capitalisation on that field, since the first letter of a case-sensitive local part is exactly the character your phone likes to change.

Read the address back once, out loud, before you send the confirming photograph, which catches the errors typing does not.

Then send it, and watch for the bounce for the minute it takes to load the trailer.

Subject lines for everything that follows are handled in the subject lines piece.

Which habits lose addresses?

Seven, and the first is writing them down yourself.

Transcribing an address the client says out loud, which introduces your hearing and your handwriting into a case-sensitive string.

Collecting on paper and typing it up that evening, by which point the client is gone and a bounce is unfixable.

Asking for the address so you can send a newsletter, which offers the client nothing.

Only asking the person who booked, so a boat of four yields one address.

Letting a form reject apostrophes and plus signs, which quietly excludes real addresses.

Keeping the list in four places, so no single list is ever complete.

And never sending anything for a year, so the first message arrives from a stranger.

Turning that first contact into a review request is handled in the review request piece.

What surprises operators here?

That case matters and correction is impossible.

Most people assume email addresses are case insensitive, and the specification says the opposite about the part before the at-sign.

The second surprise is that a great many characters are legal in an address, including several that common forms reject outright.

The third is that an apostrophe is an ordinary character, which means a rejected client with an Irish surname is your form's fault rather than theirs.

The fourth is that the only thing genuinely checkable from outside is whether the ending exists, and that list is a public text file.

The fifth is that the booking system already holds the best list the operation owns, unexported.

Taken together, collecting addresses is less about persuasion and more about not corrupting the string.

The automated sends that depend on all this are described in the automations piece.

The collection, in order

Own the moment, then confirm it on the spot.

Export the addresses your booking system already holds, into the one place you send from.

Add the photo handoff at the end of every trip, with the client typing into your phone rather than dictating.

Send one photograph before they leave the dock, so a bad address surfaces while it can still be fixed.

Store the string exactly as typed, with the source and the date beside it, and never lower-case anything.

Check only what is checkable, meaning whether the ending appears on the public list, and pass everything else through.

Put a one-field form on the site offering something genuinely local, delivered immediately rather than promised.

Remove permanent bounces rather than retrying them, and ask the client next season instead of guessing.

Keep the do-not-contact names in the same file as everything else, because that is the list you cannot afford to rebuild.

What to send that list in the off-season is planned in the winter rebooking piece.