Email deliverability: why SPF, DKIM, and DMARC matter for websites too

Many website projects treat email as a side quest: submit the contact form, connect the newsletter tool, send the invoice email, done. Until customers report that confirmations never arrive. Or reports land in spam. Or Gmail starts behaving like a dragon with DNS trauma.

Email deliverability is no longer only a newsletter problem. It affects contact forms, booking confirmations, password resets, quote requests, technical reports, invoices, and support communication. If these messages do not arrive, the website feels broken — even when the code itself is technically fine.

What changed at major mailbox providers

Since 1 February 2024, Google requires all senders to personal Gmail accounts to use at least SPF or DKIM. Senders that send more than 5,000 messages per day to Gmail accounts have additional requirements: SPF and DKIM, DMARC for the sending domain, valid forward and reverse DNS, TLS, low spam rates, and one-click unsubscribe for marketing or subscribed messages.

This is not only relevant for large newsletters. It shifts the baseline expectation for serious email sending. Even small websites can become unreliable when they send through poorly configured domains, old SMTP setups, or unclear third-party providers.

SPF, DKIM, and DMARC in practical terms

SPF tells receiving servers which mail servers are allowed to send on behalf of a domain. If a form server, newsletter tool, or CRM is missing from the SPF record, messages may be treated with more suspicion.

DKIM cryptographically signs emails. Receiving servers can check whether the message really matches the sending domain and whether it was modified in transit.

DMARC connects SPF and DKIM to the visible From domain. It also tells receivers what to do when a message fails authentication: monitor, quarantine, or reject.

The key point: having a random DNS record somewhere is not enough. Sending paths must align with the visible sender domain.

Where websites usually break

In website projects, deliverability problems often come from small, boring decisions:

• The contact form sends directly from the web server, but the domain actually uses Google Workspace or Microsoft 365.
• A newsletter tool was configured, but DKIM was never enabled.
• The SPF record contains too many includes or old providers.
• Transactional emails use a no-reply address that nobody monitors.
• Form emails put the visitor’s address in the From header and break authentication.
• Reports are sent through a third party, but the domain is not verified properly.
• Marketing emails do not include a working one-click unsubscribe header.

The result is rarely a clean hard error. Worse: it becomes unreliable. Sometimes the email arrives, sometimes it does not. Support then starts searching in the wrong monster basement.

What a website check should cover

A technical website check should not ignore email. At minimum, it should cover:

1. Sending inventory: Which systems send email for the domain? Website, shop, CRM, newsletter, booking tool, report system?
2. SPF check: Are all legitimate senders included? Are there outdated includes or DNS lookup limits?
3. DKIM check: Are keys active for workspace email, newsletters, transactional mail, and other providers?
4. DMARC check: Does a record exist? Are reports used? Does the policy match the team’s maturity?
5. From header check: Does the website send from its own domain instead of spoofing visitor addresses?
6. Reply-To hygiene: Visitor addresses usually belong in Reply-To, not From.
7. Unsubscribe check: Newsletters and subscription emails need visible unsubscribe; high-volume senders also need one-click unsubscribe.
8. Monitoring plan: Bounce messages, spam rates, and provider errors should not disappear into the void.

For Website-Pflichtencheck, this matters directly because reports and contact requests only create value when they are delivered reliably.

Privacy and trust are part of the same story

Email deliverability is also a trust issue. If customers expect a confirmation and receive nothing, they may submit the same data multiple times. If forms forward to private mailboxes, data flows can become unclear quickly. If newsletter unsubscribes do not work cleanly, marketing turns into a reputation problem.

Clean email configuration does more than appease spam filters. It makes communication traceable, reduces support work, and prevents unnecessary data copies.

Conclusion

SPF, DKIM, and DMARC are not glamorous features. Nobody throws confetti for them. But they decide whether forms, reports, newsletters, and transactional emails work reliably.

For website teams, email deliverability belongs in maintenance and website audits. Not only after customers ask why their request never arrived. DNS is dry, yes. Lost leads are drier.

Sources

• Google Gmail Help: Email sender guidelines
• IETF RFC 7208: Sender Policy Framework
• IETF RFC 6376: DomainKeys Identified Mail
• IETF RFC 7489: DMARC
• IETF RFC 8058: One-Click Unsubscribe

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