Delphi DLL

Send Email without Mail Server

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

uses
    Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
    Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls, MailMan, Dns, Email, JsonObject;

...

procedure TForm1.Button1Click(Sender: TObject);
var
success: Boolean;
mailman: HCkMailMan;
recipientEmailAddr: PWideChar;
dns: HCkDns;
json: HCkJsonObject;
smtpHostname: PWideChar;
email: HCkEmail;

begin
success := False;

// 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.
mailman := CkMailMan_Create();

recipientEmailAddr := 'joe@example.com';

// Do a DNS MX lookup for the recipient's mail server.
dns := CkDns_Create();
json := CkJsonObject_Create();

// This gets all MX domains for an email address.  (Typically one domain.)
// The preferred domain will be at index 0 (see below).
success := CkDns_Query(dns,'MX',recipientEmailAddr,json);
if (success = False) then
  begin
    Memo1.Lines.Add(CkDns__lastErrorText(dns));
    Exit;
  end;

smtpHostname := CkJsonObject__stringOf(json,'answer.mx[0].domain');
Memo1.Lines.Add(smtpHostname);

// Set the SMTP server.
CkMailMan_putSmtpHost(mailman,smtpHostname);

// Create a new email object
email := CkEmail_Create();

CkEmail_putSubject(email,'This is a test');
CkEmail_putBody(email,'This is a test');
CkEmail_putFrom(email,'My Name <myname@mydomain.com>');
CkEmail_AddTo(email,'',recipientEmailAddr);

success := CkMailMan_SendEmail(mailman,email);
if (success = False) then
  begin
    Memo1.Lines.Add(CkMailMan__lastErrorText(mailman));
    Exit;
  end;

CkMailMan_Dispose(mailman);
CkDns_Dispose(dns);
CkJsonObject_Dispose(json);
CkEmail_Dispose(email);

end;