For web developers & agencies
Contact forms for client sites that don't turn into support tickets
If you build websites for small business clients — a handful of pages, some photos, a contact form — the contact form is the one piece that quietly turns into an ongoing support burden. It works at launch. Then the host disables PHP's mail() function in an update, or migrates the site to a new server, and the form goes silently dead until a client calls asking why they haven't heard from a lead in weeks.
Even when it does send, mail() on shared hosting sends as the client's domain from an IP that domain's SPF record never authorized — so Office 365 and Gmail file it straight into Junk. Fixing that properly means editing SPF, DKIM, and DMARC records on a domain you often don't control and can't touch without the client's registrar login.
PostTo replaces the whole dependency. Point the form's action at a PostTo endpoint and delivery moves off the host entirely — nothing server-side to break, no DNS records to touch on the client's domain, and spam filtering built in so the inbox stays usable.
Free plan, no credit card required.
How PostTo handles it
No PHP mail() to babysit
PostTo delivers the email itself via its own transactional email infrastructure. When a host update disables mail(), bumps the PHP version, or moves servers, the form keeps working — there's no local mail function for anything to break.
Zero DNS changes on the client's domain
PostTo sends from its own verified sending domain and sets Reply-To to the visitor's address, so you never touch the client's SPF, DKIM, or DMARC records — handy when you don't have, or don't want, registrar access.
Stays out of the spam folder
Because delivery isn't spoofing the client's domain from an unauthenticated host IP, the message doesn't trip the SPF/DMARC checks that send shared-hosting mail() straight to Office 365 or Gmail Junk.
Spam-filtered before it reaches the inbox
A honeypot field plus first-party heuristic scoring run on every submission at no extra cost, so the client's inbox doesn't fill up with bot spam either.
One dashboard for every client site
Create one endpoint per client site under a single account — each with its own destination address, rate limit, and spam settings — instead of maintaining mail config per server.
Held, never lost
Anything flagged as spam is held and visible in the dashboard, not silently discarded, so a false positive never costs a client a lead.
Three steps, a few minutes
Create an endpoint per site
Sign up free and create one endpoint per client website, each pointing at that client's inbox.
Swap the form action
Change the existing contact form's action="" to the PostTo endpoint URL. The form's HTML and field names stay exactly as they are.
Delivery just works
Submissions arrive in the client's inbox and are logged in your dashboard — no server-side mail config for you to maintain going forward.
The code
Replace YOUR_TOKEN
with the endpoint URL from your dashboard.
<form action="https://postto.dev/api/v1/send/YOUR_TOKEN" method="POST">
<label for="name">Name</label>
<input type="text" id="name" name="name" required>
<label for="email">Email</label>
<input type="email" id="email" name="email" required>
<label for="message">Message</label>
<textarea id="message" name="message" required></textarea>
<!-- Honeypot: bots fill this in, humans never see it -->
<input type="text" name="_hp" tabindex="-1" autocomplete="off" style="display:none">
<!-- Where to send the visitor after a successful submission -->
<input type="hidden" name="_next" value="https://clientsite.com/thanks">
<button type="submit">Send</button>
</form>Pick your framework
A dedicated walkthrough and copy-pasteable snippet for each stack.
From the docs
Frequently asked questions
- Why did my client's contact form suddenly stop sending email?
- Most often the host disabled or restricted PHP's mail() function, changed PHP versions, or moved the site to a new server without carrying over local mail config. Since PostTo delivers via its own infrastructure instead of the host's mail(), that failure mode goes away — the form keeps posting to the same endpoint URL regardless of what the host changes underneath it.
- Why does contact form mail end up in the client's Junk folder?
- Shared hosting typically sends as the client's domain from an IP that domain's SPF record never authorized, which is exactly what Office 365 and Gmail treat as spoofing. PostTo sends from its own verified domain and sets Reply-To to the visitor, so nothing is being spoofed on the client's behalf.
- Do I need access to the client's domain DNS?
- No. PostTo doesn't require any DNS changes on the client's domain — SPF, DKIM, and DMARC stay exactly as they are. That matters when the client controls the registrar, or nobody remembers the login.
- Can I manage contact forms for several client sites from one account?
- Yes — create one endpoint per site under a single PostTo account, each with its own destination email, rate limit, and spam settings, and review every client's submissions from one dashboard.
- Does this work with WordPress and other CMS platforms, or only static HTML?
- Both. It's a plain HTTP POST to an endpoint URL, so it works from static HTML, a WordPress theme's contact form, or any framework — see the framework guides below for copy-pasteable snippets.
- What does it cost across several client sites?
- The free plan includes one endpoint and 50 submissions a month, enough to try PostTo on a single low-traffic site. Managing several client sites needs a paid plan for the extra endpoints: Starter ($9/month) covers 3 endpoints, and Pro ($29/month) covers 25 — one endpoint per client site, each with its own destination inbox and settings.
See it working in a few minutes
Create an endpoint, point your form at it, and see your first submission in the dashboard — all on the free plan.
Try PostTo free