Tukuk-OSA contact form looks easy: a text box, a submit button, done. In reality email is the most fragile part of any small website. The Tukuk-OS contact form took longer to refine than any other feature I built, and here is what I learned along the way.
Why Email Is Hard for Small Sites
The problem starts with reputation. Major email providers (Gmail, Outlook) are deeply suspicious of new senders. If you send email directly from your own server it will likely land in spam — or be rejected outright — even if your intentions are completely genuine.
My first solution was a third-party email delivery service, but that added a new dependency and free-tier limits. Then I found a better fit for my project: Cloudflare Email Routing.
How Cloudflare Email Routing Works
Because the tukuk.org domain is already managed by Cloudflare, I can set up email rules: [email protected] forwards to my personal inbox. No email server to host, no fees, and delivery goes through Cloudflare infrastructure that large providers already trust.
When the form is submitted the Tukuk-OS server builds an email message and sends it through the configured delivery method. The recipient sees a message from the domain itself, which dramatically improves delivery success rates.
Security of the Form
An open form is a target for automated spam, so I added four layers:
- A secret API key — only legitimate forms can submit.
- Rate limiting — one IP can only send a few messages per minute.
- Basic validation — required fields are trimmed and length-checked.
- Logging — every attempt is recorded so I can see abuse patterns.
There is no annoying captcha for real users. Instead I rely on a combination of rate limits and a hidden key, which solves the bot problem without adding friction for humans.
What Gets Sent
The email contains the name, the sender's address, and the message body, all sanitised first to prevent header injection (fake message headers that could poison logs or mislead recipients). I also set the correct Reply-To so I can reply directly to the sender with one click.
On the server side delivery failures are not swallowed: they are logged and returned to the form as an honest error message, so the sender knows the message did not get through and can try again.
My First Mistake: Email Vanished Without a Trace
In the first month the contact form existed, someone told me they had sent an inquiry but never received a reply. I checked the logs and found no record of the request at all — meaning the form failed long before the email was sent, and the user was told nothing.
The cause was simple: a server-side error that only occurred when a particular field was filled in a particular way. The error was caught, but the response sent back to the form still reported success. I had assumed "silent failure" was better than frightening the user — that experience taught me it was one of the worst assumptions I ever made.
Since then every failure state gets the correct status code and a message written specifically for users. If email delivery fails the form tells you clearly and keeps your typed text so you do not have to retype. Success rates jumped after that change — not because fewer errors happened, but because errors are now detected and reported.
Writing Messages That Get Replies
One lesson beyond the technical: what you write in the form affects whether you get an answer. My first messages were short and vague — "hi, I have a question" — and the reply rate was low.
Now I follow a simple template: introduce yourself in one sentence, state the question specifically (including links or references if any), and close with a reasonable expectation for reply time. Such messages respect the recipient's time and make it easier for them to reply usefully.
I also learned not to send repeated follow-ups. One clear message, then wait a few days before following up. That patience produces better reply rates than repeated pressure — and it keeps relationships with the people I contact in good shape.
Key Lessons
Four takeaways from this work:
- Do not host email yourself if you do not have to; use infrastructure that is already trusted.
- Every open form needs at least rate limiting.
- Outbound email alone is not enough — you need logs to know what actually happened.
- An honest error message beats confusing silence every time.
The Tukuk-OS contact form now runs reliably, and I would much rather spend my time building new features than keep guessing why an email did not arrive.