You built a contact form, wired it to send an email, and tested it once. It worked. Three weeks later a visitor says they filled it out and never heard back. You check your inbox: nothing. You check spam: there it is, sitting between a fake invoice and a crypto pitch.
Email deliverability is the set of checks a receiving mail server runs before it decides whether a message belongs in the inbox, the spam folder, or nowhere at all. For a static site's contact form, those checks almost always fail, and the failure is invisible until a real lead is lost.
Why Do Contact Form Emails Land in Spam?
Most static-site contact forms send mail one of two ways: a serverless function calling an SMTP relay with default settings, or a shared-hosting PHP script calling mail(). In both cases the message's From address is usually your domain, but the server actually sending it is not authorized to send mail for that domain. Gmail, Outlook, and every major provider check for that authorization before they trust the message.
The visitor's submission itself is fine. The problem is entirely on the sending side, which is why it is so easy to miss: your test submission from your own laptop, checking your own inbox, can pass while a stranger's submission on a strict corporate mail server silently fails.
What Do SPF, DKIM, and DMARC Actually Check?
Three DNS-based records do the authorization work. SPF (Sender Policy Framework) lists which servers are allowed to send mail claiming your domain; a receiving server checks the sending IP against that list. DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to the message, generated with a private key that matches a public key published in your DNS, proving the message was not altered in transit. DMARC tells receiving servers what to do when SPF or DKIM fail: quarantine, reject, or do nothing.
Under RFC 7208, the specification that defines SPF, a message from a server not listed in the domain's SPF record is not automatically rejected, but it is scored as suspicious and weighed alongside every other spam signal the receiving server has. A form email sent from a generic hosting IP, on a domain whose SPF record only lists a different provider's mail servers, fails that check every single time. DMARC then adds a policy tag, commonly p=none, p=quarantine, or p=reject, telling a receiving server exactly what to do once both SPF and DKIM fail: log it quietly, send it to spam, or refuse it outright.
Does This Affect Serverless Functions on Netlify or Vercel Too?
Yes, and often worse than shared PHP hosting, because the outbound path is less visible. A serverless function that calls an SMTP relay or a transactional email API is still sending on behalf of your domain's From address unless the relay's own sending domain is used instead. Teams building on Astro, Next.js, Hugo, or Eleventy frequently wire a function to a generic SMTP account, get one working test send, and never revisit it until a client reports a missing message weeks later. The static-site host has nothing to do with mail deliverability at all; it only serves the HTML that points the form at wherever the mail actually gets sent from.
| Sending method | Domain authentication | DKIM signing | Typical outcome |
|---|---|---|---|
| Shared-host PHP mail() | None by default | Not signed | Spam folder or silently dropped |
| Serverless function plus generic SMTP | Depends on relay config | Only if relay is set up correctly | Inconsistent, breaks after DNS changes |
| Dedicated form backend with its own sending domain | Pre-authenticated at the provider | Signed automatically | Consistent inbox delivery |
Setting this up correctly for your own domain means publishing an SPF record that lists your actual sending server, generating a DKIM key pair, publishing the public half as a DNS TXT record, configuring your mail software to sign with the private half, and then adding a DMARC record once both are stable. According to Google's own sender guidelines, all three should stay in sync with the actual sending server, and a mismatch after any DNS change is enough to break delivery again. Get one part wrong and the fix is often silent: the form keeps working because it returns a success page, while the email itself never arrives.
This is the point where most site owners stop maintaining their own mail pipeline. SimpleForm sends every notification through its own already-authenticated sending infrastructure, so a submission on your static site is emailed to you without your domain needing any SPF, DKIM, or DMARC record of its own. You point a form's action attribute at your SimpleForm endpoint, per the setup docs, and the delivery mechanics stop being your problem.
How Do You Check If Your Form Emails Are Actually Being Delivered?
Do not rely on your own successful test. Run these checks instead, in order:
- Submit the form from a second, unrelated email provider (a Gmail test account works) and check its spam folder, not just the inbox.
- Search your domain's DNS for a TXT record starting with v=spf1 and confirm it lists the actual server sending your form mail.
- Search for a TXT record at selector._domainkey.yourdomain.com to confirm a DKIM key is published and matches what your mail sender signs with.
- Send a test submission to a deliverability checker such as mail-tester.com and read the SPF, DKIM, and DMARC lines in its report individually.
- Ask three real people on three different email providers to submit the form and confirm delivery, since spam filtering varies by provider.
A message that sends successfully from your server's point of view and a message that arrives in a human inbox are two different events. Only the second one matters to your business.
Isn't It Risky to Hand Form Email to a Third Party?
The usual objection is trust: you would rather send mail yourself than route a lead's information through another company's servers. That is a reasonable instinct, but it inverts the actual risk. A self-hosted contact form with no SPF or DKIM record is not more private, it is just failing quietly, and a lost lead is a worse outcome than a properly delivered one. A dedicated form backend still only stores what your form fields send it, and a provider whose entire product is form delivery has a direct incentive to keep its sending domain's reputation clean, which is harder to guarantee on a general-purpose hosting IP shared with unrelated sites.
The practical middle ground is to stop treating email authentication as a one-time setup task and start treating it as infrastructure someone else specializes in, the same way you would not run your own CDN just to serve a logo. SimpleForm's free plan covers 100 submissions a month across 3 forms with 7 days of submission history, which is enough to confirm delivery is fixed before deciding whether to route more traffic through it.
Fix Deliverability Without Managing DNS Records
If your contact form emails have been landing in spam, the fastest fix is not another round of DNS debugging. Create a free SimpleForm account, point one form's action attribute at your new endpoint, and submit a real test message: within a minute you will see whether it lands in your inbox, because the sending domain is already authenticated on SimpleForm's side, not yours.
If the form still needs other work first, compare submission limits and features on the pricing page, or browse the rest of the blog for related setup guides.
Frequently asked questions
They almost always go to spam because the server sending them is not authorized to send mail for your domain. Receiving providers check SPF, DKIM, and DMARC records in your DNS before trusting a message, and a shared-hosting mail() call or a default serverless SMTP setup usually has none of them configured correctly for your domain.
SPF lists which mail servers are allowed to send messages claiming your domain, checked against the sending server's IP address. DKIM attaches a cryptographic signature to the message itself, proving it was not altered and genuinely came from a server holding the matching private key. Both are separate DNS TXT records, and most providers check both.
Not on its own. SPF alone lowers suspicion but many providers still weigh a message more heavily against spam signals without a matching DKIM signature, and without DMARC there is no policy telling receivers what to do if either check fails. All three need to be configured together and kept in sync with whatever server actually sends the mail.
It fixes it if the service sends notification emails from its own already-authenticated sending domain rather than relaying through your domain's unconfigured DNS. Check that the provider's docs describe how submissions are emailed to you, since some services still expect you to configure your own SPF and DKIM for outbound mail.
Submit the form using an email account you do not normally use, on a different provider than your own, and check both the inbox and spam folder. A deliverability testing tool such as mail-tester.com will also show a line-by-line SPF, DKIM, and DMARC result for that specific message.
No. SPF, DKIM, and DMARC only affect whether your outbound notification email is trusted by the recipient's mail server. They do nothing to stop bots submitting the form itself; that requires separate spam protection such as a honeypot field or rate limiting on the form endpoint.