Editorial illustration.
Originally published 26 June 2023; rewritten and reviewed on 15 October 2026.
A user submits a form and sees a success message. Behind the page, the SMTP server rejects the notification. If the application treats sending email as an invisible side effect, the problem may remain unnoticed until somebody asks why no messages arrived.
Separate acceptance from delivery
Decide whether the form submission is accepted independently of the notification. Store the business record first when the workflow requires it, then hand the email to a queue or another observable delivery mechanism. An accepted record and a delivered message are different states.
The original article demonstrated System.Net.Mail and Kentico’s email APIs. Those examples belong to particular .NET and CMS versions. Use the email service supported by the deployed stack rather than assuming an old snippet is the preferred client for a new project.
Keep configuration out of the handler
Store transport credentials in the deployment’s protected configuration, with the permissions needed for the sending identity. Construct recipients and templates from validated application data. Use a controlled sender address rather than trusting a form field as the message’s From value.
For a Kentico project, inspect the installed version’s email queue, template resolution and logging features before adding a second delivery path. Test template variables and HTML encoding with realistic content.
Test what happens after a rejection
Exercise invalid recipients, authentication failure, temporary transport errors and a retry. Ensure retries cannot send the same business notification repeatedly without control. Log identifiers and failure categories without exposing passwords or unnecessary message content.
A useful application response says what actually happened: the submission was received, the notification was queued or the operation failed. That distinction gives both the user and the support team a reliable starting point.