Your website sends email — but does it actually arrive?

A website can appear technically healthy while quietly losing leads, orders, or users. Sometimes the problem is not the form or checkout. It is the final step: the email is generated but does not reliably reach the inbox.

This affects more than newsletters. Contact enquiries, password resets, invoices, appointment confirmations, and system alerts all depend on working email infrastructure.

The common blind spot

Many teams test only whether the application handed a message to an email service. That is not the same as successful delivery. Several failures can happen in between:

• The sender domain is not authenticated correctly.
• A legitimate third-party service is missing from SPF.
• DKIM is disabled, uses the wrong key, or signs with an unexpected domain.
• The visible From domain does not align with the authenticated domain.
• DMARC is missing or its reports are ignored.
• Old or conflicting DNS records remain after a provider migration.
• Bounce events are stored, but nobody monitors them.
• Contact forms and password resets use different sending paths.

The result is deceptive: the website shows “message sent successfully” while the business-critical email is rejected or routed to spam.

SPF, DKIM, and DMARC in practical terms

SPF identifies which servers may send email for a domain. The record needs to include every legitimate sending route, such as Google Workspace, Microsoft 365, Resend, Mailgun, Brevo, or a hosting provider.

DKIM adds a cryptographic signature to outgoing messages. Receiving systems can verify that the message belongs to the signing domain and was not altered in transit.

DMARC combines authentication and domain alignment with a policy for messages that fail. Reports can also reveal which systems send on behalf of the domain.

The key question is not whether DNS records merely exist. They must match the way email is actually sent.

Ten red flags

1. Contact enquiries seem to disappear.
2. Password-reset messages need repeated attempts.
3. The website or email provider recently changed.
4. Marketing, form, and transactional messages use different services.
5. Nobody can list every authorised sender.
6. DMARC reports are not reviewed.
7. Delivery works only with a provider-owned sender domain.
8. Bounce rates and SMTP errors are invisible.
9. Gmail tests succeed, but other recipients report failures.
10. A former agency still controls DNS or DKIM keys.

What a useful audit looks like

1. Inventory every sender

Include website forms, CMS plugins, shops, CRM platforms, newsletters, support tools, authentication, invoicing, and monitoring.

2. Check DNS and alignment

SPF, DKIM, and DMARC must be valid and match the services in use. Alignment between the visible From domain and the authenticated SPF or DKIM domain matters.

3. Inspect real messages

Send tests to different mailbox providers. Full headers show which checks passed and which infrastructure actually handled the message.

4. Test failure paths

What happens after a hard bounce, blocked address, or temporary error? Look for retries, webhooks, logs, and an alert that reaches a responsible person.

5. Test critical journeys separately

Contact forms, password resets, registration, order confirmations, and internal notifications may use different templates, identities, or providers.

What Website-Pflichtencheck would inspect

Website-Pflichtencheck can review publicly visible DNS and sender configuration, common authentication mistakes, form behaviour, technical headers, and operational gaps. It also asks whether failures are merely logged or actually surfaced to someone who can act.

The goal is a practical answer: which business-critical website emails are dependable, which are fragile, and what should be fixed first?

A website has not completed its job just because it generated an email. The process becomes operationally reliable only when important messages can be traced as delivered, rejected, or escalated.

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