Postal Mail Server, web uygulamaları ve sunucular için e-posta dağıtım platformudur. SMTP/API üzerinden gönderim, gönderim logları ve teslimat olaylarının webhook ile uygulamalara aktarılması için kullanılır. Resmi ürün belgesi, kendi sunucusunda işletilen dağıtım katmanını ve teslimat sorunlarına ilişkin olay bildirimlerini tanımlar.
Parola sıfırlama, sipariş bilgisi ve uygulama bildirimleri gibi işlem e-postalarında değerlendirilebilir. Çalışan posta kutusu, takvim veya kampanya tasarım aracı değildir. Abone ve bülten yönetimi için Listmonk, posta kutuları için Zimbra Collaboration farklı rollerdedir.
Tipik üretim akışı
Uygulama → Postal → alıcı posta sistemi gönderim yoludur. Postal → webhook endpoint → uygulama durum kaydı ise teslimat geri bildirimidir. Webhook, bir olay olduğunda uygulamanın tanımladığı HTTP endpoint’e bildirim gönderilmesidir.
Postal’ın gönderim isteğini kabul etmesi, alıcı sunucunun iletiyi kabul etmesi ve kullanıcının iletiyi okuması farklı aşamalardır. Alıcı sunucunun SMTP kabulü bile iletinin gelen kutusuna yerleştiğini garanti etmez.
Webhook endpoint’i idempotent tasarlanır: aynı olay yeniden geldiğinde aynı iş kaydı veya bildirim ikinci kez oluşturulmamalıdır. Olayın kaynağını doğrulama ve erişimi sınırlama yöntemi seçilen sürümün arayüzüyle birlikte incelenir.
DNS ve gönderici kimliği
Postal DNS rehberi, kurulum alan adı, dönüş adresi (return path), SPF, DKIM ve yönlendirme kayıtlarını ayrı tanımlar. Ürün örnekleri gerçek alan adı ve gönderim topolojisine uyarlanmalıdır.
- Gönderici alan adının SPF ve DKIM kayıtlarını doğrulayın.
- DMARC değerlendirmesinde görünür gönderen alan adıyla hizalamayı kontrol edin; yalnız TXT kaydı bulunması yeterli değildir.
- IP adresinin ters DNS ve dış SMTP erişimini barındırma sağlayıcısıyla netleştirin.
- IPv6 yayımlanıyorsa erişim ve kimlik doğrulamasını IPv6 üzerinden de test edin.
- Gönderim, dönüş ve izleme alan adlarının görevlerini belgeleyin.
Alan adı doğrulaması teslimat garantisi değildir. Yeni gönderim altyapısında trafik kontrollü artırılmalı; kalıcı/geçici retler ve şikâyetler izlenmelidir.
Güvenlik ve işletim
Uygulamalara ayrı kimlik bilgileri verilir; bir uygulamanın ele geçirilmesi bütün gönderim kaynaklarını etkilememelidir. Yönetim paneli ve altyapı bileşenleri kısıtlanır. Mesaj içerikleri ve loglar kişisel veri barındırabileceğinden saklama ve erişim politikası belirlenir.
İzlemede yalnız gönderilen ileti sayısı değil, en eski kuyruk öğesinin yaşı, başarısız teslimat nedenleri, disk tüketimi ve webhook hataları da bulunmalıdır. Parola sıfırlama gibi zaman hassasiyetli iletilerin gecikme hedefi, büyük bülten gönderimlerinden ayrı ele alınır.
Yaygın sorunlar ve çözümler
| Belirti | İlk kontrol |
|---|---|
| Gönderim bağlantısı kurulamıyor | Sağlayıcının SMTP çıkış kısıtları, DNS ve ağ erişimi |
| İletiler kuyrukta bekliyor | Alıcı geçici retleri, kota, çalışan süreçler ve kuyruk yaşı |
| İleti spam klasörüne gidiyor | Kimlik doğrulama/hizalama, itibar, içerik ve alıcı politikası |
| Uygulamada teslimat durumu güncellenmiyor | Webhook erişimi, HTTP yanıtı ve olay eşleştirmesi |
| Yinelenen gönderimler oluşuyor | Uygulama yeniden denemeleri ile teslimat sonucunun uzlaştırılması |
Göç ve geri dönüş
Yeni kimlik bilgileriyle önce test uygulaması taşınır. Gerçek alıcı sistemlerinde DNS, teslimat ve bounce akışı doğrulanır. Uygulama bazında geçiş, bütün göndericileri aynı anda değiştirmekten daha kontrollüdür.
Veritabanı, mesaj verisi, yapılandırma ve imzalama anahtarları için kullanılan sürüme uygun yedekleme planı gerekir. Geri dönüşte eski ve yeni kuyruklardaki iletiler uzlaştırılır; aynı iletinin yeniden gönderilmesi ve süresi geçmiş bildirimlerin dağıtılması önlenir.
