E-Posta & DNS

E-Posta Teslim Edilebilirliği Nasıl Artırılır?

E-Posta Teslim Edilebilirliği Nasıl Artırılır? konusunda güvenli uygulama, doğrulama ve sık yapılan hatalar için UST Bilişim teknik rehberi.

E-Posta Teslim Edilebilirliği Nasıl Artırılır?Teknik bilgi • Uygulanabilir yaklaşım
E-Posta Teslim Edilebilirliği Nasıl Artırılır? konusunda güvenli uygulama, doğrulama ve sık yapılan hatalar için UST Bilişim teknik rehberi.

Teslim edilebilirliği ölçmek için “gönderildi” kaydı yeterli değildir. Uygulama kabulü, SMTP kabulü, alıcı teslimi ve inbox yerleşimi ayrı aşamalardır. Bu rehber işlem e-postası gönderen bir web uygulamasına odaklanır.

1. Her mesaja takip kimliği verin

Uygulamada iş kimliği, alıcı, oluşturma zamanı, SMTP sağlayıcı mesaj kimliği ve son durumu saklayın. Gövdeyi veya parolaları loglamayın. Sağlayıcının delivered, deferred, bounced ve complaint olaylarını bu kimlikle eşleştirin.

2. Geçici ve kalıcı hatayı ayırın

4xx cevaplarda kontrollü tekrar deneme yapılır; 5xx kalıcı hatalarda aynı mesajı sonsuz döngüyle göndermeyin. Hatalı adresleri suppression listesine alın. Webhook tekrar gelebileceği için olay kimliğine unique kısıtı koyun.

CREATE TABLE mail_events (
  id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  provider_event_id VARCHAR(190) NOT NULL UNIQUE,
  message_id VARCHAR(190) NOT NULL,
  event_type VARCHAR(40) NOT NULL,
  occurred_at DATETIME NOT NULL
);

Bu örnek yeni bir uygulama tablosudur; sağlayıcının imza doğrulaması ve olay alanları ayrıca uygulanmalıdır. Webhook'u imzasız kabul etmeyin.

3. Kimliği doğrulayın

SPF, DKIM, DMARC ve reverse DNS'i gerçek gönderim domain/IP'si için kontrol edin. Bülten ve işlem maillerinin itibarını ayrı izleyin. Alıcının spam şikayeti, SMTP hatası olmadan oluşabilir.

4. Rapor oluşturun

Günlük kabul, teslim, geçici hata, kalıcı hata ve şikayet sayılarını hesaplayın. Paydaları belirtin: kabul edilenlere göre teslim oranı ile tüm gönderim denemelerine göre oran farklıdır. Sağlayıcı başına artan deferred oranını alarm konusu yapın.

Kontrol

Test ortamında sağlayıcının test olaylarıyla aynı webhook'u iki kez gönderin; iki ayrı teslim olayı yaratılmamalıdır. Bounce sonrası sistemin aynı hatalı adrese yeniden göndermediğini sınayın.

Örnek tablo üzerinde günlük olay sayımı

Yukarıdaki mail_events tablosunda event_type değerlerini sağlayıcınızdan normalize ettiğinizi varsayarak:

SELECT DATE(occurred_at) AS day, event_type,
       COUNT(*) AS event_count,
       COUNT(DISTINCT message_id) AS message_count
FROM mail_events
WHERE occurred_at >= '2026-09-01 00:00:00'
  AND occurred_at <  '2026-09-02 00:00:00'
GROUP BY DATE(occurred_at), event_type;

Tarih aralığını ve veritabanının saat dilimini kendi raporunuza göre değiştirin. event_count ile message_count farkı tekrarlı olay/çoklu durum takibini gösterir; bütün durumları toplayıp benzersiz mesaj sayısı sanmayın. Delivered olayı sağlayıcının teslim tanımına göre yorumlanır, inbox yerleşimini her zaman göstermez.

UST Bilişim Yaklaşımı

Bilgiyi uygulanabilir projeye dönüştürelim.

İhtiyacınızı teknik, operasyonel ve ticari açıdan değerlendirip doğru çözüm yol haritasını birlikte oluşturalım.

Projenizi Anlatın