“Sent” Is Not Delivered: Why SPF Alone Does Not Protect Website Email

A website can show a green success message after a form submission and still have broken email delivery.

There is no contradiction. “Form processed successfully” initially means only that your application completed its part of the transaction. A second chain starts afterwards: your email provider must accept the message, the receiving mail server must accept it, the authentication must make sense, and the message must finally arrive where you expect it.

For contact forms, password resets, booking confirmations, invoices or account invitations, that distinction is business-critical. A website can be technically “up” while quietly losing leads, logins or transactions.

The common misconception: “SPF is green, so email is fine”

SPF matters, but it answers only part of the question.

SPF authorizes hosts to use a domain in an SMTP identity. For DMARC, the relevant identity is the domain in MAIL FROM, often visible as the Return-Path. That is not automatically the same domain a person sees in the visible From: header.

This creates a common third-party sending configuration:

• Visible From:: billing@example.com
• Return-Path: a domain owned by the delivery provider
• SPF: passes for the provider domain
• DKIM: also signs with an unrelated provider domain

SPF can therefore report pass while DMARC still fails. RFC 9989 is explicit about why: an authenticated identifier alone is not enough for DMARC; it must align with the domain in the visible author address.

An SPF pass is not proof of delivery, and it is not proof of DMARC.

What DKIM and DMARC add

DKIM applies a cryptographic signature to a message. The signature includes a signing domain in its d= tag. A receiver can retrieve the corresponding public key through DNS and verify the signed parts of the message.

For DMARC, that DKIM domain can serve as an authenticated identity — but again, only if it aligns with the visible From: domain.

DMARC therefore connects two questions that website teams often treat separately:

1. Which domain does the recipient see as the sender?
2. Which domain was actually authenticated by SPF or DKIM?

Google and Yahoo already require SPF, DKIM and DMARC for high-volume senders and require alignment with the visible From domain. Google also recommends setting up all three mechanisms more generally to improve delivery. For a small business, the useful conclusion is not “the 5,000-message threshold does not apply to us.” It is that your website should use clean, coherent sending identities before growth or a provider migration exposes the gaps.

The contact-form anti-pattern: making the visitor the sender

A surprisingly common implementation works like this:

A visitor enters person@gmail.com into a contact form. The website then sends a message with From: person@gmail.com so that replying is convenient.

It looks practical, but it models the identity incorrectly. Your website is not Gmail and is not authorized to send as the visitor’s domain.

A better pattern is:

• From: uses a domain you control, such as website@example.com.
• The visitor’s submitted address goes into Reply-To:.
• Your delivery provider authenticates your own domain with DKIM and/or aligned SPF.
• Input is still validated and never copied unchecked into mail headers.

The visible sender remains under your control while a human can still reply directly to the enquiry.

A useful email audit does not start with DNS

The first step is an inventory of every system that sends on behalf of your domain.

Typical senders include:

• contact and enquiry forms
• WordPress or another CMS
• password resets and login codes
• invoices and order confirmations
• newsletter tools
• CRM and support systems
• appointment booking
• monitoring and system alerts
• staging or test environments
• normal mailboxes such as Google Workspace or Microsoft 365

The classic failure is an SPF record that was configured three years ago for “the email provider” while five additional services now send mail.

An audit therefore asks more than “Does SPF exist?” It asks: Which real messages are created today, and which domain authenticates each one?

Inspect real headers, not only DNS checkers

DNS checkers are useful, but they cannot see a specific message.

For a realistic test, send messages through every relevant delivery path to controlled mailboxes, then inspect the received headers. Important fields and results include:

• visible From:
• Return-Path
• DKIM d= domain and selector
• Authentication-Results
• SPF result
• DKIM result
• DMARC result
• the domain used for each check

The key question is not simply “does everything say pass?” It is:

Does at least one successfully authenticated SPF or DKIM domain align with the visible From domain under DMARC?

That is the difference between “something was authenticated” and “this visible sender identity was plausibly authorized.”

SPF: the quiet red flags

SPF often accumulates maintenance debt that remains invisible for a long time.

Multiple systems, incomplete authorization

A new CRM or transactional email service is connected, but DNS is never updated. Some messages pass SPF while others do not.

Old providers remain authorized forever

A retired newsletter or hosting platform is still present in the SPF chain. At minimum, this leaves unnecessary operational and security surface and makes it harder to answer who is actually allowed to send.

Complex include chains

SPF has processing limits for DNS-triggering mechanisms. Every new platform can make an innocent-looking include: chain more complex. An audit should therefore evaluate the effective record, not merely read the visible TXT string.

The wrong domain gets celebrated

An SPF pass on a provider-owned Return-Path domain sounds reassuring, but for DMARC it only helps if that identity is appropriately aligned.

DKIM: is the signature actually yours?

With external delivery services, inspect the d= domain.

If it contains only a provider-owned domain, DKIM can be cryptographically valid without authenticating your visible sender domain for DMARC.

A well-configured provider typically supports an authenticated sending domain backed by DNS records you control. A real test message should then show that:

• the DKIM signature validates,
• the expected domain appears in d=,
• the selector resolves in DNS,
• and the DKIM domain aligns sufficiently with the visible From domain.

Broken or forgotten DKIM selectors are especially common after DNS moves, provider changes and website migrations: the application keeps sending, but authentication silently becomes weaker.

DMARC: monitoring is not a checkbox

A DMARC record with p=none can initially observe mail without asking receivers to quarantine or reject messages that fail. RFC 9989 explicitly describes aggregate reporting as a way for domain owners to monitor their mail streams and authentication.

That is useful only if someone actually reads the reports.

A sensible rollout is:

1. inventory all legitimate senders,
2. configure SPF and DKIM cleanly,
3. observe with DMARC reporting,
4. fix unknown or misaligned sending sources,
5. only then make a deliberate decision about stricter policies.

Turning on p=reject blindly while invoices, password resets or a forgotten CRM still send with broken alignment is not hardening. It is a self-inflicted delivery incident.

“SMTP accepted” still does not mean “in the inbox”

Even perfect authentication does not turn delivery into a binary API call.

Mailbox providers can temporarily defer mail, permanently reject it, or accept it and place it in spam. Yahoo, for example, documents 4xx responses as temporary problems where a later retry may be appropriate, while 5xx responses indicate permanent failures.

For website systems, that means:

• temporary failures need controlled retries,
• permanent bounces should not be retried forever,
• authentication and reputation errors need visibility,
• provider webhooks or logs must not disappear into nowhere,
• and critical transactional mail needs monitoring.

A password reset that has hard-bounced three times should not still be treated as “email sent.”

Seven checks we want to see for website email

1. Sender inventory

Every application and service that uses your domains in From: is documented.

2. Real end-to-end tests

The provider API returning success is not enough. A test message reaches multiple major mailbox providers and its headers are inspected.

3. SPF matches the infrastructure that actually exists

Active senders are authorized, retired services are not unnecessarily retained, and evaluation does not run into processing limits or errors.

4. DKIM signs with the expected, aligned domain

We inspect d=, the selector and validation on a real message.

5. DMARC passes for the visible sender

At least SPF or DKIM passes and the authenticated domain aligns with the From domain.

6. Bounces and provider errors are processed

Temporary and permanent failures are distinguished. Delivery problems are observable instead of living only in a provider dashboard nobody opens.

7. Forms use a controlled From address

Visitor addresses belong in Reply-To, not as an impersonated sender in From:.

What Website-Pflichtencheck inspects

In a technical website check, we do not treat email as an isolated DNS task. We follow the actual path of a message from the website to receipt:

• Which function triggers it?
• Which service sends it?
• Which domain appears in the visible sender?
• Which domains are authenticated through SPF and DKIM?
• Does DMARC alignment pass?
• What happens on a bounce, timeout or provider failure?
• Does the interface report success while delivery is still unknown?
• Is there monitoring for business-critical mail flows?

The goal is not a theoretically “perfect” DNS zone. The goal is a delivery path whose failures are visible and whose identities make sense together.

If your website depends on email for leads, bookings, logins or orders, this check is especially valuable after a relaunch, hosting migration, domain move or mail-provider change.

Website-Pflichtencheck can audit the complete delivery path technically — from the form through DNS and the delivery provider to the authentication headers received at the destination.