Uygulamanız sipariş onayı, şifre sıfırlama ve fatura maili gönderiyor. Bunları kendi sunucunuzdan göndermeye çalıştığınızda teslim oranı beklediğiniz gibi çıkmıyor ve bir gönderim servisi arıyorsunuz. Karşınıza çıkan ilk üç isim genellikle SendGrid, Mailgun ve Amazon SES oluyor. Üçü de "mail gönderiyoruz" diyor ama aslında birbirinden oldukça farklı ürünler; birini seçip altı ay sonra taşımak zorunda kalmak, baştan doğru seçmekten çok daha pahalıya patlıyor.
Bu SendGrid, Mailgun ve Amazon SES karşılaştırmasında üç servisi pazarlama sayfalarındaki özellik listeleriyle değil, gerçekte fark yaratan beş eksende inceleyeceğim: fiyatlandırma modelinin mantığı, teslim edilebilirlik ve IP havuzu yönetimi, entegrasyon yükü, bounce/webhook altyapısı ve destek. Sonunda hangi senaryoda hangisinin doğru seçim olduğunu, kendi sunucunuzu kurmanın ne zaman daha mantıklı hale geldiğini net biçimde göreceksiniz.
Üç Servisin Gerçek Konumlandırması#
Amazon SES, adı üstünde bir "Simple Email Service" — AWS'in altyapı katmanıdır. Size ham gönderim kapasitesi verir ve geri kalan her şeyi (şablon yönetimi, liste yönetimi, gelişmiş raporlama, abonelikten çıkma altyapısı) kendiniz kurmanızı bekler. Bunun karşılığında birim maliyeti üçü arasında açık ara en düşüktür. Zaten AWS içinde çalışan bir uygulamanız varsa IAM, CloudWatch ve SNS ile doğal entegrasyonu ciddi bir avantajdır. Buna karşılık ilk kurulumda sandbox modundan çıkma, üretim erişimi talebi ve alan adı doğrulama adımları başlangıç sürtünmesini artırır.
SendGrid, altyapıdan çok "ürün" tarafında konumlanır. API'si ve SMTP relay'i yanında görsel şablon editörü, pazarlama kampanya modülü, ayrıntılı aktivite kayıtları ve gönderici doğrulama sihirbazları sunar. Geliştirici olmayan bir ekibin de kullanabileceği tek servis genelde budur. Fiyatlandırması kademeli paketler üzerinden ilerler ve düşük hacimde SES'e göre belirgin biçimde pahalıdır; ancak kurulum süresi ve ekip verimliliği düşünüldüğünde bu fark birçok ekip için makul gelir.
Mailgun ikisinin arasında, geliştirici odaklı bir yerde durur. Güçlü bir API'si, gelen mail yönlendirme (inbound routing) yetenekleri ve log/olay sorgulama tarafında iyi araçları vardır. Özellikle gelen maili işleyip uygulamanıza aktarmak (destek talebi oluşturma, mail ile komut alma gibi senaryolar) istiyorsanız bu tarafta en olgun deneyimi sunar. Kullandıkça öde ve paket modellerini birlikte sunar.
| Eksen | Amazon SES | SendGrid | Mailgun |
|---|---|---|---|
| Ana kimlik | Ham altyapı | Ürünleşmiş platform | Geliştirici API'si |
| Birim maliyet | En düşük | En yüksek | Orta |
| Kurulum sürtünmesi | Yüksek (sandbox, IAM) | Düşük | Düşük-orta |
| Şablon/kampanya arayüzü | Yok denecek kadar az | Güçlü | Sınırlı |
| Gelen mail işleme | Ayrı kurulum gerekir | Var | En olgun |
| Ayrılmış IP | Ek ücretli seçenek | Üst paketlerde | Ek ücretli seçenek |
| AWS ekosistem entegrasyonu | Doğal | Yok | Yok |
Fiyatlandırma Modelleri Nasıl Farklılaşıyor#
Fiyat karşılaştırmasında rakamları ezberlemek yerine modelleri anlamak çok daha kalıcıdır, çünkü rakamlar değişir, modeller nadiren değişir. Amazon SES saf kullandıkça öde mantığıyla çalışır: gönderdiğiniz her bin mesaj için sabit bir birim ücret ödersiniz, ek olarak veri transferi ve varsa ayrılmış IP ücreti eklenir. Aylık taahhüt yoktur; sıfır mail gönderdiğiniz ay sıfıra yakın ödersiniz.
SendGrid ise büyük ölçüde kademeli abonelik üzerinden ilerler: aylık bir mesaj kotası satın alırsınız, kotayı aşarsanız üst pakete geçmeniz ya da ek ücret ödemeniz gerekir. Kullanmadığınız kota devretmez. Bu model, hacmi öngörülebilir ve düzenli olan ekipler için sorunsuzdur; ayda bir patlayan kampanya trafiği olanlar içinse verimsizdir. Mailgun her iki modeli de sunar, bu yüzden dalgalı hacimlerde esneklik açısından ortada durur.
Karar verirken maliyet hesabını şu üç adımda yapın:
- Gerçek aylık hacminizi ve aylar arası dalgalanmayı çıkarın. Zirve ayı ile en düşük ay arasındaki fark iki katın üzerindeyse kullandıkça öde modeli lehine çalışır.
- Yalnızca gönderim ücretini değil, ayrılmış IP, ek doğrulama, gelişmiş analitik ve log saklama gibi kalemleri de toplayın. Fatura genellikle bu eklerle şişer.
- Kendi geliştirme maliyetinizi ekleyin. SES'te şablon ve abonelik yönetimini siz yazarsınız; bu iş saatlerinin de bir bedeli vardır.
Hacminizi ve zirve dağılımınızı henüz ölçmediyseniz, karşılaştırmaya başlamadan önce mail gönderim hacmi planlama yazısındaki yöntemle gerçek sayıları çıkarın; yanlış hacim tahmini üzerine kurulan her fiyat karşılaştırması yanıltıcıdır.
Teslim Edilebilirlik ve IP Havuzu Yönetimi#
Üç servis de varsayılan olarak paylaşımlı IP havuzu üzerinden gönderim yapar ve teslim edilebilirlik farklarının kaynağı büyük ölçüde bu havuzların nasıl yönetildiğidir. SendGrid ve Mailgun, göndericileri itibar sınıflarına ayırıp riskli hesapları izole etme konusunda uzun yıllara dayanan süreçlere sahiptir. Amazon SES ise gönderici davranışını çok sıkı denetler: bounce oranınız veya şikâyet oranınız eşiği aşarsa hesabınız önce incelemeye alınır, sonra gönderim yetkiniz askıya alınabilir. Bu sertlik ilk bakışta dezavantaj gibi görünse de havuzun temiz kalmasını sağlayan şey tam olarak budur.
Üçünde de ayrılmış IP seçeneği ek ücretlidir ve hepsinde ısıtma zorunluluğu aynen geçerlidir. Servis sağlayıcı değiştirmek ısıtma borcunu ortadan kaldırmaz; ayrılmış IP aldığınız anda yeni bir adresin itibarını sıfırdan inşa etmeye başlarsınız. Paylaşımlı ile ayrılmış arasındaki eşiği nasıl belirleyeceğinizi paylaşımlı mı ayrılmış IP mi yazısında ayrıntısıyla ele aldım.
Üç servisin de sizden beklediği ortak şart, alan adı kimlik doğrulamasının eksiksiz kurulmasıdır. Hepsinde süreç aynı mantıkla işler: servis size bir dizi DNS kaydı verir, siz bunları alan adınıza eklersiniz, servis doğrular. Tipik olarak eklemeniz gereken kayıtlar şöyle görünür:
; DKIM - servisin verdiği seçici (selector) ile
s1._domainkey.firmaniz.com. 3600 IN CNAME s1.domainkey.uXXXX.servis.net.
s2._domainkey.firmaniz.com. 3600 IN CNAME s2.domainkey.uXXXX.servis.net.
; SPF - servisin include mekanizmasi tek kayitta birlestirilir
firmaniz.com. 3600 IN TXT "v=spf1 include:servis.net ~all"
; Link takibi ve dönus yolu icin ozel alt alan adi
mail.firmaniz.com. 3600 IN CNAME sendgrid.net.
Bu kayıtlar eklendikten sonra doğrulamayı komut satırından teyit edin:
# DKIM seçicisinin çözümlenip çözümlenmediği
dig +short s1._domainkey.firmaniz.com CNAME
# SPF kaydının tek ve doğru olduğu (birden fazla v=spf1 hata sebebidir)
dig +short firmaniz.com TXT | grep spf1
# DMARC politikasının yayında olduğu
dig +short _dmarc.firmaniz.com TXT
DKIM tarafında CNAME yerine doğrudan TXT kaydı veren servislerde anahtar 255 karakteri aşabilir; bu durumda kaydın nasıl bölüneceğini DKIM TXT kaydı 255 karakter sınırı yazısı anlatıyor. Doğrulama sonrası imzanın gerçekten geçerli olup olmadığını görmek içinse DKIM doğrulaması başarısız yazısındaki teşhis adımları işinizi görür.
API, SMTP Relay ve Entegrasyon Yükü#
Üç servisin de iki ayrı kullanım yolu vardır: HTTP API veya klasik SMTP relay. SMTP relay yolu, mevcut uygulamanızı hiç değiştirmeden geçiş yapmanızı sağlar — tek yaptığınız SMTP sunucu adresini, portunu ve kimlik bilgilerini değiştirmektir. Bir WordPress sitesi, bir WHMCS kurulumu veya eski bir PHP uygulaması için genellikle en pratik yol budur.
; Tipik SMTP relay ayarları (servis fark etmeksizin şablon aynıdır)
host = smtp.servis-adi.com
port = 587 ; STARTTLS
encryption= tls
username = apikey ; birçok serviste kullanıcı adı sabittir
password = <API_ANAHTARINIZ>
from = [email protected]
Postfix'i bir relay üzerinden göndermeye ayarlamak da birkaç satırlık iştir:
# /etc/postfix/main.cf
relayhost = [smtp.servis-adi.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt
# Kimlik bilgisi dosyası ve izinleri
echo "[smtp.servis-adi.com]:587 apikey:API_ANAHTARINIZ" > /etc/postfix/sasl_passwd
chmod 600 /etc/postfix/sasl_passwd
postmap /etc/postfix/sasl_passwd
postfix reload
API yolu ise daha fazla kontrol verir: mesaj başına özel başlıklar, şablon değişkenleri, planlanmış gönderim ve zengin olay geri bildirimi. SendGrid'in API'si en geniş dokümantasyona sahip olanıdır; Mailgun'unki geliştirici ergonomisi açısından en rahatıdır; SES'in API'si ise AWS SDK'sının içinde geldiği için AWS kullanan bir ekip için sıfır ek öğrenme maliyeti taşır. Bağlantı ayarlarını doğrularken port ve TLS modu uyumsuzluğu en sık takıldığınız yer olur; SMTP test aracı ile port-TLS eşleşmesini ve gerekli komutları hızlıca çıkarabilirsiniz.
Webhook, Bounce Yönetimi ve Raporlama#
Bu, karşılaştırmanın en çok göz ardı edilen ama uzun vadede en belirleyici ekseni. Bir mail gönderdikten sonra ne olduğunu bilmek — teslim edildi mi, açıldı mı, bounce mu etti, şikâyet mi edildi — liste hijyeninin tek kaynağıdır ve bu bilgi size webhook ile ulaşır.
SendGrid ve Mailgun, olayları doğrudan sizin belirlediğiniz bir HTTPS adresine POST eder; kurulum panelden birkaç tıklamadır. Amazon SES'te ise olaylar SNS konularına yayımlanır ve siz SNS'ten kendi uç noktanıza abone olursunuz; bu ek bir katman ve ek bir yapılandırma demektir. AWS içindeyseniz avantaj, değilseniz fazladan iş.
| Olay | Ne anlama gelir | Yapmanız gereken |
|---|---|---|
| delivered | Alıcı sunucu kabul etti | Kayıt tut, işlem yok |
| bounce (hard) | Adres kalıcı olarak yok | Listeden hemen çıkar |
| bounce (soft) | Kutu dolu / geçici sorun | Say, eşiği aşarsa çıkar |
| complaint | Kullanıcı spam işaretledi | Derhal listeden çıkar |
| unsubscribe | Abonelikten çıkış | Listeden çıkar, kayda geç |
| open / click | Etkileşim | Segmentasyonda kullan |
Kritik nokta şu: complaint olayını işlemek isteğe bağlı değildir. Şikâyet eden bir kullanıcıya göndermeye devam etmek, üç servisin de kullanım şartlarına aykırıdır ve hesabınızın askıya alınmasına yol açar. Aynı şekilde hard bounce alan adresleri listede tutmak, bounce oranınızı yükselterek gönderim yetkinizi tehlikeye atar. Bu iki olayı otomatik işleyen bir uç nokta yazmadan üretime geçmeyin.
Kendi Sunucunuzu Kurmak Ne Zaman Daha Mantıklı#
Bu üç servis her senaryoda doğru cevap değildir. Kendi MTA'nızı çalıştırmak şu durumlarda daha mantıklıdır: hacminiz yüksek ve öngörülebilir olduğunda birim maliyet servislerin çok altına iner; verinin ülke içinde kalması gereken kurumsal senaryolarda konum kontrolü sizde olur; ve gönderim davranışınız üzerinde tam kontrol istediğinizde hız limiti, kuyruk politikası, imza ayarları gibi her parametreyi kendiniz belirlersiniz.
Buna karşılık üstlendiğiniz sorumluluklar da net: PTR kaydı, TLS sertifikası yenileme, kara liste izleme, güvenlik güncellemeleri, kuyruk yönetimi ve — en önemlisi — teslim edilebilirlik sorunları çıktığında bunu tek başınıza çözmek. Bu yükü almaya hazırsanız, hazır yapılandırılmış SMTP sunucu paketleri Postfix, Dovecot, DKIM ve rDNS kaydıyla teslim edildiği için sıfırdan kurmaya göre çok daha hızlı bir başlangıç sağlar. Daha genel bir altyapı istiyorsanız VDS üzerinde tam root erişimiyle her şeyi kendiniz kurabilirsiniz.
Bir ara yol da mümkündür ve pratikte en verimlisi genellikle budur: işlemsel mailleri kendi sunucunuzdan, kampanyaları bir servisten göndermek. Böylece kritik maillerin kontrolü sizde kalır, kampanyaların yüksek şikâyet riski ise sizin IP itibarınıza yansımaz.
Sıkça Sorulan Sorular#
Hangisi en ucuz#
Birim maliyet açısından Amazon SES üçü arasında açık ara en düşüktür, çünkü yalnızca ham gönderim satar. Ancak toplam maliyeti hesaplarken şablon yönetimi, abonelikten çıkma altyapısı ve raporlama gibi parçaları kendiniz yazacağınızı hesaba katmalısınız. Ekibinizde bunu yazacak geliştirici zamanı yoksa, SendGrid'in daha yüksek faturası toplamda daha ucuza gelebilir.
Ücretsiz plan var mı#
Üç servisin de deneme veya sınırlı ücretsiz kullanım seçenekleri zaman zaman değişir, bu yüzden güncel koşulları kendi fiyat sayfalarından teyit edin. Genel eğilim şudur: SES'te ücretsiz kotalar AWS altyapısı üzerinden çalışan uygulamalara bağlıdır, SendGrid ve Mailgun ise düşük hacimli başlangıç planları sunar. Üretim kararınızı ücretsiz kotaya göre vermeyin; hacminiz büyüdüğünde geçerli olacak fiyat neyse ona bakın.
Servis değiştirmek teslim oranımı sıfırlar mı#
Paylaşımlı havuzda kalıyorsanız hayır, yeni servisin havuz itibarını devralırsınız ve geçiş genelde sorunsuz olur. Ayrılmış IP kullanıyorsanız evet, yeni IP'yi baştan ısıtmanız gerekir. Her iki durumda da alan adı itibarınız (SPF, DKIM, DMARC ve gönderim geçmişiniz) sizinle taşınır; bu yüzden geçişte alan adını değiştirmemek önemlidir.
SMTP relay mi API mi kullanmalıyım#
Mevcut bir uygulamayı hızlıca taşımak istiyorsanız SMTP relay en az iş çıkaran yoldur; tek yaptığınız sunucu adresi ve kimlik bilgisini değiştirmektir. Yeni bir entegrasyon yazıyorsanız API'yi tercih edin: olay geri bildirimi daha zengindir, şablon değişkenleri ve planlı gönderim gibi yetenekler yalnızca API üzerinden gelir, ayrıca hata ayıklaması çok daha kolaydır.
Amazon SES sandbox modundan nasıl çıkılır#
SES yeni hesapları sandbox modunda başlatır; bu modda yalnızca doğrulanmış adreslere gönderim yapabilirsiniz. Üretim erişimi için AWS konsolundan bir talep açar, ne tür mail göndereceğinizi, listeyi nasıl topladığınızı ve bounce/şikâyet olaylarını nasıl işleyeceğinizi açıklarsınız. Talebin kabul edilmesi genellikle bir iş günü sürer; net ve dürüst bir açıklama süreci belirgin biçimde hızlandırır.
Bounce ve şikâyet olaylarını işlemezsem ne olur#
Kısa vadede bounce oranınız yükselir, orta vadede gönderim yetkiniz kısıtlanır veya hesabınız askıya alınır. Üç servis de bu oranları izler ve eşiği aşan hesaplara müdahale eder. Bunun ötesinde şikâyet eden kullanıcılara göndermeye devam etmek alıcı sağlayıcılar nezdinde itibarınızı doğrudan düşürür. Webhook uç noktanız üretime geçmeden hazır olmalıdır.
Kendi sunucumdan gönderirken bu servislerden birini yedek olarak kullanabilir miyim#
Evet ve bu iyi bir dayanıklılık desenidir. Postfix'te birincil çıkış kendi sunucunuz olur, teslim edilemeyen veya belirli alan adlarına giden mesajlar için ikinci bir relay tanımlarsınız. Böylece IP'niz geçici olarak kara listeye girdiğinde kritik mailler yine teslim edilir. Yalnızca her iki çıkış yolunun da SPF kaydınızda tanımlı olduğundan emin olun, aksi halde yedek yol SPF'ten kalır.
Kapanış#
Üç servis arasındaki seçim, aslında "ne kadarını kendim yapmak istiyorum" sorusunun cevabıdır. Aklınızda kalması gereken dört şey: SES ham ve ucuz ama etrafındaki ürünü siz yazarsınız; SendGrid ürünleşmiş ve hızlı ama pahalıdır; Mailgun geliştirici ergonomisi ve gelen mail işleme tarafında öne çıkar; ve hangisini seçerseniz seçin bounce ile şikâyet olaylarını işleyen bir uç nokta yazmadan üretime geçmeyin. Fiyat karşılaştırmasını da gerçek hacim verinizle yapın, tahminle değil.
Kontrolü kendinizde tutmayı tercih ederseniz Postfix, Dovecot ve DKIM'i hazır kurulu gelen SMTP sunucu paketleri ya da tam root erişimli VDS sunucuları iyi bir başlangıç noktasıdır. Kurumsal posta kutularınız için e-posta paketlerimize, kampanya ve segmentasyon tarafı için e-posta pazarlama çözümlerimize, altyapıyı tamamen devretmek isterseniz sunucu yönetimi hizmetimize bakabilirsiniz.