How would you handle email send failures and retries?

Question

Utpal Vishwas · Answer

Handling email send failures and retries robustly is critical for a reliable email service. Here’s a solid approach to do this in C#:

1. Catch and Log Failures

Always catch exceptions thrown during the email send operation.
Log detailed error information (exception message, stack trace, recipient, timestamp).
Use a persistent log store or monitoring system.

try
{
    await smtpClient.SendMailAsync(mailMessage);
}
catch (SmtpException ex)
{
    // Log failure
    _logger.LogError(ex, $"Failed to send email to {recipient}");
    // Handle retry or escalation
}

2. Retry Policy

Use a retry mechanism with:

A maximum number of retries (e.g., 3 attempts).
Exponential backoff or fixed delays between retries.
Retry only on transient failures (network issues, SMTP server unavailable).
Avoid retrying on permanent failures (invalid email, auth failure).

Implementing Retry with Polly

Polly is a great resilience library for .NET.

var retryPolicy = Policy
    .Handle<SmtpException>(ex => IsTransient(ex))  // Check if error is transient
    .WaitAndRetryAsync(
        retryCount: 3,
        sleepDurationProvider: attempt => TimeSpan.FromSeconds(Math.Pow(2, attempt)), // Exponential backoff
        onRetry: (exception, timeSpan, retryCount, context) =>
        {
            _logger.LogWarning($"Retry {retryCount} after {timeSpan.TotalSeconds}s due to {exception.Message}");
        });

await retryPolicy.ExecuteAsync(() => smtpClient.SendMailAsync(mailMessage));

Note: You need to implement IsTransient(SmtpException ex) to identify transient errors.

3. Queue-Based Retry for Better Scalability

Use a durable queue (e.g., MSMQ, Azure Queue, RabbitMQ) to store emails to send.
Worker services dequeue and send emails.
If sending fails, push the email back with a retry count.
Move failed emails after max retry attempts to a “dead letter” queue or store for manual inspection.

4. Dead Letter Handling

After exceeding retry attempts, mark the email as failed.
Notify an admin or log it for manual investigation.
Avoid infinite retry loops.

5. Fallback and Alerting

Optionally fallback to an alternate email provider or SMTP server.
Send alerts if failure rate exceeds threshold.

Summary Checklist

Step	Purpose
Catch exceptions	Detect failures
Log errors	Diagnostics
Use retry with backoff	Handle transient issues
Limit retries	Avoid infinite loops
Queue-based sending	Scalability and durability
Dead letter queue	Track permanently failed emails
Alert admins	Proactive incident response

interview

How would you handle email send failures and retries?

Can you answer this question?

1 Answers

1. Catch and Log Failures

2. Retry Policy

Use a retry mechanism with:

Implementing Retry with Polly

3. Queue-Based Retry for Better Scalability

4. Dead Letter Handling

5. Fallback and Alerting

Summary Checklist