KAHIBARO
Discord Login Register ☰
☰

18.8. Email Delivery Best Practices

Table of Contents

Understanding Email Delivery Quality

When you send an email from your backend, two big questions matter:

  1. Does it reach the inbox and not the spam folder?
  2. Does it actually get delivered and not silently dropped?

This chapter focuses on the practical habits and technical settings that improve your chances of reliable, inbox‑bound delivery.

We assume you already know the basics of sending emails and SMTP from earlier chapters. Here we focus on best practices only.

Use a Reputable Email Service Provider

Running your own SMTP server correctly is possible, but for most backend applications, a dedicated Email Service Provider (ESP) is safer and faster.

Common options:

Provider typeExamplesTypical use
Transactional email servicesSendGrid, Mailgun, PostmarkApp notifications, password resets, etc.
Cloud provider email servicesAWS SES, GCP SendGrid, AzureApps already on cloud platforms
Marketing / bulk email platformsMailchimp, Brevo, ConvertKitNewsletters, campaigns

Key reasons to use an ESP:

For transactional backend emails (password resets, verifications, receipts) choose a transactional ESP. Avoid mixing transactional and marketing emails from the same sender domain if possible, or at least use different sending subdomains (for example app.example.com vs news.example.com).

Configure DNS Authentication Properly

Modern email delivery depends heavily on DNS records that prove your server is allowed to send emails for your domain.

You typically configure three key mechanisms.

SPF

SPF (Sender Policy Framework) tells the world which servers may send email using your domain.

Example SPF TXT record for the root domain:

txt 
example.com.  TXT  "v=spf1 include:sendgrid.net include:_spf.google.com ~all"

Meanings:

Always have only one SPF TXT record per domain.
If you need multiple services, put multiple include: parts into a single record.

DKIM

DKIM (DomainKeys Identified Mail) signs each outgoing email with a cryptographic signature. Receivers verify that:

The ESP usually gives you one or more DKIM records like:

txt 
s1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb..."

In your ESP dashboard, you will usually see a status like "DKIM: verified" once DNS propagation finishes.

DMARC

DMARC tells receivers what to do with emails that fail SPF or DKIM checks for your domain and also lets you collect reports.

Typical DMARC record:

txt 
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-fail@example.com; fo=1"

Key tags:

Typical rollout strategy:

  1. Start with p=none to see what is sending on your behalf.
  2. Clean up unauthorized senders.
  3. Move to p=quarantine, then eventually p=reject.

SPF, DKIM, and DMARC must agree on your domain.
Use the same sending domain in your “From” header that you have configured in DNS records.

Choose Good Sender Addresses and Domains

The sender identity strongly influences spam filters.

Use a Real Domain, Not Free Email Addresses

Avoid sending transactional emails "from" yourapp@gmail.com or other free email providers while using an external SMTP service. This usually conflicts with DMARC and looks suspicious.

Better:

Use Clear, Human Senders

Better sender formats:

Even for automated messages, consider not using no-reply@ if you want to allow replies or if it can hurt user trust. Some systems still use no-reply but make sure your app provides clear support channels.

Consistent sender addresses:

Write Inbox‑Friendly Email Content

Spam filters look at both content and behavior.

Avoid Spammy Subject Lines

Bad examples:

Better:

Keep subjects:

Write Clean, Simple Body Text

Guidelines:

For transactional emails, include:

Example password reset email:

text 
Subject: Reset your YourApp password
Hi {{user_name}},
We received a request to reset the password for your YourApp account.
To reset your password, click the link below:
{{reset_link}}
If you did not request a password reset, you can safely ignore this email.
Thanks,
The YourApp team

Always Include a Plain-Text Version

Many transactional emails are HTML. You should also include a plain text version. Most ESPs support this directly.

Benefits:

Provide a Clear Unsubscribe or Preference Link for Non‑Essential Emails

For marketing or optional notifications, provide an unsubscribe mechanism. Even if not legally required for a simple transactional app, this is a good habit and lowers spam complaints.

Examples:

For strictly required emails like password resets or receipts, you still should explain why the user got it, but unsubscribe is usually not applicable.

Respect Legal and Compliance Requirements

Different regions have different laws for email, like CAN‑SPAM (US), GDPR (EU), CASL (Canada).

General best practices:

These rules mostly apply to marketing or bulk emails, but following them in transactional contexts improves user trust.

Manage Bounces and Invalid Addresses

Bounces are delivery failures. They affect your reputation, especially if you ignore them.

Two main types:

TypeMeaning
Hard bouncePermanent failure, such as non‑existent address.
Soft bounceTemporary problem, such as mailbox full or server down.

Track Bounces via Your ESP

Most ESPs:

You should:

Example logic in your backend:

  1. Receive bounce webhook from provider.
  2. Mark the user’s email as "invalid" or "delivery problem".
  3. Optionally prompt the user next time they log in to confirm or update their email.

Continuing to send to invalid or bouncing addresses will damage your sender reputation and can cause broad deliverability problems.

Handle Complaints and Unsubscribes Correctly

Email providers offer feedback loops that tell ESPs when users click "This is spam".

Your ESP might:

Your backend should:

For explicit unsubscribes:

Throttle and Warm Up Sending Volume

If your app is new or your IP/domain has little history, sending a large burst of emails can look suspicious.

Warm Up New Domains and IPs

When starting out:

ESP dashboards often include recommended warm‑up schedules. Follow those if provided.

Avoid Sudden Spikes

Even later, avoid patterns like:

Better:

Example strategy:

Use Background Jobs for Sending

In your backend, sending email should almost never block the main request for long.

Typical pattern:

  1. User submits an action that triggers an email, such as registration or password reset.
  2. Your API:
    • Saves the necessary data (email address, type of email, payload) in a queue or jobs table.
    • Quickly responds to the user (for example "Check your inbox").
  3. A background worker:
    • Reads jobs from the queue.
    • Sends emails via the ESP.
    • Handles retries on temporary failures.

Benefits:

Be careful to:

Monitor Key Email Metrics

Track delivery quality over time. Most ESPs show these metrics.

Important metrics:

MetricDescriptionTypical target
Delivery rateDelivered / SentAs high as possible, ideally > 98%
Bounce rateBounced / SentPreferably below 1%
Complaint rateSpam complaints / DeliveredKeep below 0.1%
Open rateOpened / DeliveredVaries by email type and audience
Click rateClicked / Delivered or Clicked / OpenedDepends on email purpose
Unsubscribe rateUnsubscribes / DeliveredHigher for marketing, low for transactional

If bounce or complaint rates rise:

Use Proper Message Headers

Correct headers help spam filters and improve user experience.

Common headers for transactional emails:

text 
From: YourApp Notifications <notifications@example.com>
To: Alice <alice@example.org>
Subject: Your YourApp password reset
Message-ID: <unique-id-1234@example.com>
Date: Tue, 27 Aug 2026 10:15:00 +0000
Reply-To: support@example.com
List-Unsubscribe: <https://example.com/unsubscribe?token=...>

Notes:

Your ESP usually handles many of these but you should know what they do and configure them where appropriate.

Test Deliverability Across Providers

Delivery can differ between providers (Gmail, Outlook, Yahoo, corporate servers).

Testing checklist:

  1. Create test accounts on multiple providers.
  2. Send test emails from your app:
    • Password reset.
    • Verification email.
    • Marketing email if applicable.
  3. Check:
    • Does it arrive in the inbox, spam, or not at all?
    • Does the HTML render correctly?
    • Are links and tracking parameters working?
    • Are images blocked by default?

You can also use specialist tools or services that analyze headers and content and provide a “spam score” with suggestions.

Keep Your Infrastructure Secure

If your sending account or API keys are compromised, attackers can send spam pretending to be you. This quickly destroys your domain reputation.

Best practices:

If you detect abuse:

  1. Immediately revoke the compromised keys or password.
  2. Stop suspicious sending.
  3. Investigate which addresses might have received spam.
  4. Work with your ESP to clean up reputation issues if needed.

Summary Checklist

Use this list as a quick reference when setting up email delivery for your backend:

Following these practices from the start makes your backend’s email both reliable and trusted, which is essential for features like authentication, password reset, and user notifications.

Views: 7

Comments

Please login to add a comment.

Don't have an account? Register now!

© 2025 Kahibaro
Visitors: 2994 / 24h
Impressum / Imprint
Datenschutz / Data Policy