Why Contact Form Emails Get Lost — and the Cloudflare Email Service Setup We Built

The most critical email a website sends is not the marketing newsletter; it is that single message from the contact form. A prospect fills in the form, sees “your message has been received”, and waits for a reply. If that message landed in spam — or never arrived — what was lost is not an email but a customer. And most of the time, nobody notices.

This post covers why form emails get lost, and the sending infrastructure we built on this very site last month with Cloudflare Email Service — a real setup, running in production.

Why Do Emails Get Lost?

Receiving servers ask three identity questions about every message:

• SPF: Is this server authorized to send email on behalf of this domain?
• DKIM: Is the message unmodified in transit, and is its signature really the domain’s?
• DMARC: If the first two fail, what should happen — reject, or send to spam?

The typical problem with form emails is this: the site sends the message “on behalf of” your domain through a third-party SMTP service or a shared hosting server. If SPF/DKIM alignment is broken, or that shared server’s reputation has been damaged by other customers, your message has lost before it even leaves. The second classic failure is silent errors: an SMTP password changes, a quota fills up, a service is suspended — the form says “sent”, and nothing goes out.

The Setup on This Site

Since July, this site’s contact form has worked like this:

1. The submission lands on an endpoint running on Cloudflare Workers — the same platform that serves the site itself. No separate form service, no separate server.
2. The Worker hands the message directly to Cloudflare Email Service, sent from form@bdijital.com to info@bdijital.com. There is no SMTP password stored anywhere, no API key that could leak; the permission is defined on the account itself.
3. Because the domain’s SPF/DKIM/DMARC records are already managed in Cloudflare, the sender identity and the domain verify each other; the message travels under its own identity, not through a “suspicious intermediary”.

The protection layer: form spam and abuse

Every reachable form is a target for bots. The setup applies rate limiting along two separate dimensions: the same IP address can attempt at most 5 submissions per minute, and the same email address at most 3. The form is bounded against automated spam waves and single-source abuse alike — while a real visitor never notices the limits exist.

Visibility: which form, when, from which page?

Every successful submission is recorded as an analytics event, with no personal data included. We can see how many inquiries arrived on which day and which pages produce submissions — so “is the form working?” is answered with data, not guesses.

The Same Approach on Your Site

The nice thing about this setup is that it works at any scale: a single-form brochure site and a portal receiving hundreds of inquiries a day are protected by the same three principles — identity-aligned sending, abuse limits, measurability.

If you are not sure your forms actually reach you, the first step is a delivery test: we send one together and read the SPF/DKIM/DMARC results. Take a look at our email automation service, or simply use our contact form — you will be trying the exact infrastructure this post describes.