Key Technical Aspects of Sending Email in Web Applications

Core Protocols & Architecture

SMTP (Simple Mail Transfer Protocol) is the fundamental protocol for sending email. Your application acts as an SMTP client, connecting to an SMTP server (port 25, 587, or 465) to submit messages. Port 587 with STARTTLS is the modern standard for submission.

Key flow: Your app → SMTP server → Recipient's mail server → Recipient's inbox

Authentication & Security

SMTP Authentication prevents unauthorized use of mail servers. You'll typically authenticate with username/password via:

PLAIN - Base64 encoded credentials
LOGIN - Similar to PLAIN
CRAM-MD5 - Challenge-response (more secure)

Most services (Gmail, SendGrid, Mailgun) require authentication on port 587.

TLS/SSL Encryption:

STARTTLS (port 587) - Starts unencrypted, upgrades to TLS
SSL/TLS (port 465) - Encrypted from the start
Always use encryption to protect credentials and content

Email Authentication Standards

SPF (Sender Policy Framework) - DNS record listing which servers can send email for your domain. Prevents spoofing.

v=spf1 include:_spf.google.com ~all

DKIM (DomainKeys Identified Mail) - Cryptographic signature proving the email came from your domain and wasn't altered. The sending server signs the email with a private key; recipients verify using a public key in your DNS.

DMARC (Domain-based Message Authentication) - Policy telling recipients what to do if SPF/DKIM fail (quarantine, reject). Also provides reporting.

Why these matter: Without proper authentication, your emails will likely be marked as spam or rejected entirely. Major providers (Gmail, Outlook) heavily penalize unauthenticated mail.

Content Encoding

Quoted-Printable - Encoding method for text that's mostly ASCII but contains some special characters. Encodes non-ASCII bytes as =XX (hex). Human-readable and efficient for primarily English text.

Content-Transfer-Encoding: quoted-printable

Hello=20World=21

Base64 - Encodes binary data (images, attachments) into ASCII text. Less human-readable but handles any binary content.

Multipart Messages

Multipart refers to emails with multiple content sections. The most common types:

multipart/alternative - Different versions of the same content (plain text + HTML). Email clients display the best version they support:

Content-Type: multipart/alternative; boundary="boundary123"

--boundary123
Content-Type: text/plain

Plain text version

--boundary123
Content-Type: text/html

<html>HTML version</html>

--boundary123--

multipart/mixed - Contains different types of content (body + attachments):

Content-Type: multipart/mixed; boundary="boundary456"

--boundary456
Content-Type: text/html

<html>Email body</html>

--boundary456
Content-Type: application/pdf; name="document.pdf"
Content-Disposition: attachment

[binary PDF data]

--boundary456--

Difference: Alternative = same content in different formats; Mixed = different pieces of content (body + attachments).

Critical Headers

Required headers:

From: - Sender address
To: - Recipient(s)
Subject: - Email subject
Date: - When sent
Message-ID: - Unique identifier

Important optional headers:

Reply-To: - Where replies should go
Return-Path: - Where bounces go
Content-Type: - MIME type and charset
MIME-Version: - Usually "1.0"
X-Mailer: - Identifies sending software (optional)

Common Failure Scenarios

Email fails to send:

SMTP authentication failure (wrong credentials)
Network/firewall blocking SMTP ports
Recipient server rejects (invalid address, full mailbox)
Message rejected by spam filters
Rate limiting by your SMTP provider
Missing or malformed headers
Server timeout

Email sends but arrives with no body:

Content-Type header missing or incorrect
Multipart boundary mismatch (boundary in header doesn't match content)
Character encoding issues (wrong charset declared)
Content-Transfer-Encoding missing for non-ASCII content
Empty or corrupted message body in SMTP transaction
Mail client rendering issues (HTML not supported, CSS stripped)
Content filtered by security software

Email sends but goes to spam:

Missing SPF/DKIM/DMARC
From domain doesn't match sending server
Poor sender reputation
Spammy content (excessive links, trigger words)
No plain text alternative for HTML emails
Missing unsubscribe header for bulk mail

Best Practices

Always send multipart/alternative (plain text + HTML) - improves deliverability
Implement proper authentication (SPF, DKIM, DMARC) before going to production
Use a reputable SMTP service (SendGrid, Mailgun, Amazon SES) rather than your own server - they handle reputation management
Handle bounces and complaints - monitor Return-Path and feedback loops
Test thoroughly - use services like Mail-Tester or GlockApps to check spam scores
Respect rate limits - queue emails and send gradually
Use UTF-8 encoding for international character support
Keep HTML simple - many clients strip CSS and JavaScript
Include plain text versions - some users prefer them, and it helps with spam filters
Monitor delivery rates - track bounces, opens, and spam complaints

Debugging Tips

Use telnet or openssl s_client to manually test SMTP connections
Check SMTP server logs for rejection reasons
Validate your DNS records (SPF, DKIM, DMARC) with online tools
Test with multiple email providers (Gmail, Outlook, Yahoo)
Use email header analyzers to inspect authentication results
Enable bounce handling to catch delivery failures

The most critical factors for success are proper authentication (DKIM especially) and using a reputable sending service with good IP reputation.