(SQL Server) Send Email without Mail Server

How to send an email without a mail server (so-to-speak).

Note: This example requires Chilkat v11.0.0 or greater.

Chilkat ActiveX Downloads

ActiveX for 32-bit and 64-bit Windows

-- Important: See this note about string length limitations for strings returned by sp_OAMethod calls.
--
CREATE PROCEDURE ChilkatSample
AS
BEGIN
DECLARE @hr int
-- Important: Do not use nvarchar(max). See the warning about using nvarchar(max).
DECLARE @sTmp0 nvarchar(4000)
DECLARE @success int
SELECT @success = 0

-- Sending Email: Do You Really Need an SMTP Server?
--
-- A common question developers ask is: "Can my application send email without connecting to a mail server?"
--
-- The short answer is: No, not really. Every email sent over the internet must be handed to a Simple Mail Transfer Protocol (SMTP) server.
--
-- What people usually mean is: "My application doesn't have credentials for a dedicated SMTP server.
-- Can it send an email directly to the recipient's server without me needing to configure one?"
--
-- The answer to that question is: "Yes, it's technically possible, but it's an outdated and highly unreliable method that will likely fail in the real world."
-- Let's explore how it works and, more importantly, why you shouldn't use it.
--
-- How "Serverless" Email Sending Works
--
-- Components and libraries that claim to send email without a configured server perform a clever trick behind the scenes:
--
-- DNS MX Lookup: They take the recipient's email address (e.g., recipient@example.com) and perform a special DNS query to find the Mail Exchange (MX) records for the example.com domain.
--
-- Direct Connection: This MX record provides the hostname of the SMTP server responsible for handling email for that domain (e.g., mx.example.com).
--
-- Delivery Attempt: The library then connects directly to that server on the standard SMTP port (25) and attempts to deliver the email.
--
-- You're still connecting to an SMTP serverï¿½just the recipient's, not your own.
-- Why This Method Fails in Modern Applications
--
-- While this process seems straightforward, it is almost guaranteed to fail for two critical reasons. These aren't minor "gotchas"; they are fundamental roadblocks in today's internet infrastructure.
--
-- Problem #1: Most Networks Block Port 25
--
-- To combat spam, nearly all residential Internet Service Providers (ISPs) like Comcast and Spectrum, corporate firewalls, and cloud providers (AWS, Azure, Google Cloud)
-- block outgoing connections on port 25 to any server except their own.
--
-- If your application is running on a user's home computer or within a typical corporate or cloud network, its attempt to connect to a random recipient's mail server
-- will be blocked before it even starts. The connection will simply time out.
--
-- Problem #2: You Have No IP Reputation
--
-- Email servers are built on trust. They will not accept mail from unknown, untrusted sources.
--
-- When your application connects directly from its IP address (especially a dynamic IP from a residential ISP), the recipient's server will see it as a suspicious,
-- unauthenticated connection. It will likely be rejected for several reasons:
--
-- No Authentication: You are not logging in to prove who you are.
--
-- Poor IP Reputation: The IP address has no history of sending legitimate mail.
--
-- Blacklists (DNSBLs): The IP is likely on a DNS Blackhole List (DNSBL) that flags dynamic IPs as sources of spam.
--
-- You will receive an error message from the server, like this common example:
--
-- 553-Your message was rejected because it appears to be spam.
-- 553-The IP address [your.ip.address.here] is listed on the SORBS DUHL blacklist.
-- 553 To request removal, see http://www.sorbs.net/
-- The Modern, Reliable Solution: Use an Authenticated Relay
--
-- Instead of trying to deliver mail directly, the correct and reliable method is to relay your email through a server that you can
-- authenticate with. This solves all the problems mentioned above.
--
-- There are two primary ways to do this:
--
-- Authenticated SMTP Relay (The Standard)
--
-- You configure your application to connect to a dedicated mail server that knows and trusts you.
--
-- How it Works: You connect using a specific port designed for authenticated sending (port 587 or 465), which is not blocked by firewalls.
-- You then provide a username and password (or API key) to authenticate.
--
-- Why it Works: You are now a trusted user on a server that has a high IP reputation. That server handles the final delivery to the recipient, who will trust mail coming from it.
--
-- Examples: Your ISP's mail server (e.g., smtp.comcast.net), your web host's server, or your company's Microsoft 365 or Google Workspace mail server.
--
-- Transactional Email API Services (The Professional Standard)
--
-- For applications, the best practice is to use a dedicated email delivery service.
--
-- How it Works: Instead of dealing with SMTP directly, you use a simple API (like a REST API) to send your email.
-- The service handles all the complexities of delivery, reputation, and compliance.
--
-- Why it's Better: These services are built for high-volume, reliable delivery. They provide detailed analytics (opens, clicks, bounces),
-- manage IP reputation across entire server farms, and ensure your mail doesn't land in the spam folder.
--
-- Examples: SendGrid, Mailgun, Postmark, and Amazon SES.
--
-- Conclusion
--
-- While the idea of sending email without a configured server is tempting, the direct-to-MX method is an obsolete technique that is fundamentally incompatible
-- with the security and anti-spam measures of the modern internet.
--
-- For reliable email delivery, always use an authenticated SMTP relay or a dedicated transactional email API service.

-- ----------------------------------------------------------
-- The following code is NOT recommended as explained above:
-- ----------------------------------------------------------

-- The mailman object is used for sending and receiving email.
DECLARE @mailman int
EXEC @hr = sp_OACreate 'Chilkat.MailMan', @mailman OUT
IF @hr <> 0
BEGIN
PRINT 'Failed to create ActiveX component'
RETURN
END

DECLARE @recipientEmailAddr nvarchar(4000)
SELECT @recipientEmailAddr = 'joe@example.com'

-- Do a DNS MX lookup for the recipient's mail server.
DECLARE @dns int
EXEC @hr = sp_OACreate 'Chilkat.Dns', @dns OUT

DECLARE @json int
EXEC @hr = sp_OACreate 'Chilkat.JsonObject', @json OUT

-- This gets all MX domains for an email address. (Typically one domain.)
-- The preferred domain will be at index 0 (see below).
EXEC sp_OAMethod @dns, 'Query', @success OUT, 'MX', @recipientEmailAddr, @json
IF @success = 0
BEGIN
EXEC sp_OAGetProperty @dns, 'LastErrorText', @sTmp0 OUT
PRINT @sTmp0
EXEC @hr = sp_OADestroy @mailman
EXEC @hr = sp_OADestroy @dns
EXEC @hr = sp_OADestroy @json
RETURN
END

DECLARE @smtpHostname nvarchar(4000)
EXEC sp_OAMethod @json, 'StringOf', @smtpHostname OUT, 'answer.mx[0].domain'

PRINT @smtpHostname

-- Set the SMTP server.
EXEC sp_OASetProperty @mailman, 'SmtpHost', @smtpHostname

-- Create a new email object
DECLARE @email int
EXEC @hr = sp_OACreate 'Chilkat.Email', @email OUT

EXEC sp_OASetProperty @email, 'Subject', 'This is a test'
EXEC sp_OASetProperty @email, 'Body', 'This is a test'
EXEC sp_OASetProperty @email, 'From', 'My Name <myname@mydomain.com>'
EXEC sp_OAMethod @email, 'AddTo', @success OUT, '', @recipientEmailAddr

EXEC sp_OAMethod @mailman, 'SendEmail', @success OUT, @email
IF @success = 0
BEGIN
EXEC sp_OAGetProperty @mailman, 'LastErrorText', @sTmp0 OUT
PRINT @sTmp0
EXEC @hr = sp_OADestroy @mailman
EXEC @hr = sp_OADestroy @dns
EXEC @hr = sp_OADestroy @json
EXEC @hr = sp_OADestroy @email
RETURN
END

EXEC @hr = sp_OADestroy @mailman
EXEC @hr = sp_OADestroy @dns
EXEC @hr = sp_OADestroy @json
EXEC @hr = sp_OADestroy @email

END
GO