Email deliverability: why website forms can fail on SPF, DKIM, and DMARC

A website can technically work and still lose business because emails do not arrive reliably. Contact forms, quote requests, password resets, booking confirmations, invoices, and newsletters all depend on one basic question: do receiving mail servers trust the sender?

Many teams only test whether the form says "sent". That is not enough. What matters is whether the message reaches the inbox, lands in spam, can be replied to, and is authenticated for the sending domain.

Why SPF, DKIM, and DMARC matter

SPF defines which servers are allowed to send email for a domain. DKIM cryptographically signs messages so recipients can check whether they were changed and whether they align with the domain. DMARC builds on both and tells receiving servers what to do when messages fail SPF or DKIM.

For website owners, this may sound like mailserver trivia. In practice it means: if a website sends through a form provider, CMS, SMTP service, or newsletter tool, DNS and sender logic must match.

Common mistakes

Website projects often show the same problems:

• The contact form sends as the visitor address instead of the site domain.
• SPF includes too many or wrong providers.
• DKIM is active for newsletters but not transactional mail.
• DMARC is missing or remains in test mode for years.
• Subdomains such as mail.example.com or app.example.com are undocumented.
• Several tools send for the same domain, but nobody knows the full list.
• Forms work in a test but land in spam at Gmail, Yahoo, or corporate inboxes.

That is not cosmetic. For lead generation and customer communication, it is business-critical.

What a website check should include

A pragmatic email check covers:

1. DNS: SPF, DKIM, and DMARC for the main domain and relevant subdomains.
2. Sender identity: which address does the website actually use?
3. Tool inventory: CMS, SMTP, newsletter, CRM, booking, shop, support.
4. Test mails: send to Gmail, Outlook, Yahoo, and a corporate mailbox.
5. Reply path: can the recipient reply meaningfully?
6. Error logs: bounces, SMTP errors, form logs.
7. DMARC reporting: for larger setups, reports help find misconfigurations.

Important: do not only test newsletters. Contact forms and password resets are often more critical.

Maintenance after changes

Deliverability is not a one-time project. New tools, domain changes, relaunches, and hosting migrations can change DNS records. After relevant changes, teams should check:

• Was a new sending service connected?
• Did the DNS provider change?
• Does the CMS still use the same SMTP server?
• Were DKIM keys rotated?
• Are old SPF entries still needed?

Conclusion

If website forms do not deliver reliably, teams often notice only after leads are missing. SPF, DKIM, and DMARC are therefore not just IT formalities. They are part of website functionality. A good website check should show whether the domain is configured as a trustworthy sender.

Sources

• Google Workspace Admin Help: Email sender guidelines
• Yahoo Sender Hub: Sender Requirements
• DMARC.org: Overview

Note: This article is a technical overview and does not constitute legal advice.