Toplu Mail İçin SMTP Sunucu Almalı mıyım?

Elinizde 40 bin kişilik bir bülten listesi var, paylaşımlı hosting hesabınızdan gönderdiğiniz ilk 500 mailden sonra "günlük gönderim limitiniz doldu" uyarısı geldi ve şimdi SMTP sunucu satın alma seçeneklerine bakıyorsunuz. Arama sonuçlarında iki bambaşka ürün yan yana çıkıyor: bir tarafta "kendi SMTP sunucunuz, sınırsız gönderim" diyen VDS tabanlı paketler, diğer tarafta aylık kotayla satılan hazır gönderim servisleri. İkisi aynı kelimeyle satılıyor ama aldığınız şey aynı değil; birinde bir makine ve bir IP adresi satın alıyorsunuz, diğerinde başkasının itibarını kiralıyorsunuz.

Bu yazı, toplu mail gönderimi için kendi mail sunucusunu kurmakla hazır bir smtp relay servisine bağlanmak arasındaki farkı, satın alma kararını gerçekten belirleyen tek konu üzerinden anlatıyor: teslim edilebilirlik. Yıllardır gördüğüm en pahalı hata, sunucuyu alıp Postfix'i kurup ilk gün 40 bin maili tek seferde kuyruğa atmaktır — o gün bittiğinde elinizde çalışan bir sunucu, kara listeye düşmüş bir IP ve bir daha asla Gmail'e ulaşmayacak bir alan adı olur. Aşağıda özel IP'nin ne anlama geldiğini, IP ısıtma (warm-up) takviminin nasıl uygulandığını, PTR/SPF/DKIM/DMARC kurulumunun hangi sırayla yapıldığını ve kara listeye düşerseniz gerçekte ne olduğunu adım adım bulacaksınız.

Toplu Mail İçin SMTP Sunucu Ne İşe Yarar#

SMTP sunucu, mailinizi alıcının posta sunucusuna teslim eden makinedir; toplu gönderimde satın aldığınız şey ise o makinenin bağlı olduğu IP adresinin alıcı tarafındaki itibarıdır. Paylaşımlı hostingte bir sunucuda yüzlerce site bulunur ve hepsi aynı çıkış IP'sini kullanır; komşunuzun hacklenmiş WordPress'i spam atmaya başladığında sizin faturanız da kesilir. Bu yüzden hosting sağlayıcıları saatlik/günlük gönderim limiti koyar — bu limit sizi kısıtlamak için değil, ortak IP'yi korumak için vardır.

Kendi SMTP sunucunuz olduğunda üç şey değişir. Birincisi, çıkış IP'si yalnızca size aittir; itibarı sizin gönderim davranışınız belirler. İkincisi, gönderim hızını (concurrency, saatlik tavan, alıcı bazlı throttling) siz ayarlarsınız. Üçüncüsü — ve çoğu kişinin hesaba katmadığı kısım — o itibarın bakımı da artık sizin işinizdir. Bounce'ları temizlemek, şikâyet geri bildirim döngülerine (FBL) kaydolmak, kara liste kontrollerini yapmak kimsenin sizin yerinize üstlenmediği bir operasyondur.

Kendi SMTP Sunucunuz mu, Hazır Servis mi#

Kısa cevap: aylık gönderiminiz düzenli olarak yüz binleri buluyorsa ve gönderim davranışınız üzerinde tam kontrol istiyorsanız kendi sunucunuz; listeniz küçük, gönderim düzensiz ve teknik operasyon yürütecek kimseniz yoksa hazır servis daha doğrudur.

Aradaki asıl kırılma noktası maliyetin nasıl davrandığıdır. Hazır servislerde maliyet gönderdiğiniz mail sayısıyla doğrusal artar; kendi sunucunuzda ise sabittir ve hacim arttıkça birim maliyet düşer. Ancak bu tasarrufun karşılığında bir operasyon yükü devralırsınız. Ayda 20 bin mail atan bir firma için o operasyon yükü, tasarruftan büyüktür. Ayda 2 milyon mail atan bir e-ticaret sitesi için tam tersi geçerlidir.

Üçüncü bir yol daha var ve pratikte en çok işe yarayan sıklıkla o oluyor: kendi sunucunuzu kurup, kritik işlemsel mailleri (şifre sıfırlama, sipariş onayı) ayrı bir kanaldan göndermek. Pazarlama maili kara listeye düşerse kampanya gecikir; şifre sıfırlama maili düşerse müşteri sisteme giremez. Bu ikisini aynı IP'den göndermek, riski yanlış yere yığmaktır.

SMTP Sunucu Almadan Önce Cevaplamanız Gereken 6 Soru#

1. Listeniz nereden geldi? Satın alınmış ya da kazınmış bir listeyle hiçbir altyapı sizi kurtarmaz. İlk gönderimde spam tuzağı (spam trap) adreslerine çarpar ve IP'niz gün bitmeden Spamhaus SBL/CSS listesine girer.
2. Son 6 ayda bu adreslere hiç mail attınız mı? İki yıldır dokunulmamış bir liste, ölü kutu oranı yüksek listedir. Yüksek bounce oranı, ısıtma sürecini daha başlamadan bitirir.
3. Günlük ve aylık gerçek hacminiz ne? "Sınırsız" bir hedef değildir. Alıcı tarafındaki tavan, sizin sunucunuzun kapasitesinden çok daha düşük olabilir.
4. Abonelikten çıkma mekanizmanız var mı? Tek tıkla çıkış (RFC 8058, List-Unsubscribe-Post başlığı) artık büyük sağlayıcılarda beklenen bir davranış, opsiyonel bir nezaket değil.
5. Alan adınızı ne kadar süredir kullanıyorsunuz? Yeni tescil edilmiş bir alan adından toplu mail atmak, itibar açısından sıfırdan başlamaktır. Mümkünse yerleşik ana alan adınızın bir alt alan adını (gonderim.sirketiniz.com gibi) kullanın.
6. Bounce'ları kim işleyecek? Geri dönen maili okuyup listeden düşen bir mekanizmanız yoksa, her kampanyada aynı ölü adreslere yeniden vurursunuz.

Bu altı sorudan üçüne "bilmiyorum" diyorsanız, kendi sunucunuzu kurmak sorununuzu çözmez, sadece görünür hâle getirir.

Özel IP ve IP İtibarı: Asıl Satın Aldığınız Şey#

Bir SMTP sunucusu satın alırken aslında bir IP adresinin geçmişini satın alırsınız — ve o geçmiş sizinle başlamayabilir. Sağlayıcıdan IP'yi teslim aldığınız gün, ilk maili göndermeden önce şunu kontrol edin:

# IP'nin bilinen kara listelerde olup olmadığına bakın
dig +short 4.3.2.1.zen.spamhaus.org
dig +short 4.3.2.1.bl.spamcop.net
dig +short 4.3.2.1.b.barracudacentral.org

Buradaki mantık şudur: IP adresiniz 1.2.3.4 ise, oktetleri ters çevirip liste alan adının önüne eklersiniz. Yanıt boşsa temizsiniz. 127.0.0.x biçiminde bir yanıt dönerse listedesiniz ve o IP'yle toplu gönderime başlamamalısınız — sağlayıcıdan değişim isteyin. Bunu satın almadan sonra değil, ilk 24 saat içinde yapın; sonradan "ben mi düşürdüm, zaten mi listeydi" sorusuna cevap veremezsiniz.

İtibar üç eksende ölçülür ve üçü de sizin davranışınızın çıktısıdır:

• Bounce oranı: Var olmayan adreslere gönderim. %2'nin üzeri risk, %5 üzeri alarm sinyalidir.
• Şikâyet oranı: "Spam olarak işaretle"ye basanların oranı. Büyük sağlayıcıların beklentisi bunun binde 3'ün altında kalması, tercihen binde 1 civarında olmasıdır.
• Etkileşim: Açılma ve tıklanma. Hiç açılmayan bir listeye ısrarla göndermek, teknik olarak "hatasız" olsa bile itibarı aşağı çeker.

Bir sunucunun donanımı bunların hiçbirini etkilemez. 8 çekirdek 32 GB RAM bir makine, 2 çekirdekli bir makineden daha hızlı gönderir ama daha iyi teslim etmez. Toplu gönderimde darboğaz neredeyse hiçbir zaman CPU değildir; alıcı tarafındaki throttling'dir.

IP Isıtma (Warm-up) Takvimi Nasıl Uygulanır#

IP ısıtma, yeni bir IP'den gönderilen mail hacmini günler içinde kademeli artırarak alıcı sağlayıcılara "bu gönderici düzenli ve zararsız" sinyalini vermektir. Atlanabilir bir adım değildir: sıfır geçmişi olan bir IP'den bir anda on binlerce mail çıkması, spam filtreleri için en net saldırı imzasıdır.

Tipik bir ısıtma planı şu şekilde ilerler. Rakamlar mutlak değildir; listenizin etkileşim kalitesine göre yavaşlatılır:

Isıtma sırasında uyulması gereken üç kural var. Birincisi, her gün göndermek — üç gün ara verip dördüncü gün iki katını göndermek ısıtmayı sıfırlar. İkincisi, sağlayıcı bazında ilerlemek: Gmail, Outlook/Hotmail ve Yandex ayrı ayrı itibar tutar, birinde iyi durumda olmanız diğerinde işe yaramaz. Üçüncüsü, 4xx geçici hatalarını okumak. Alıcı sunucudan gelen şu yanıt, "çok hızlısın, yavaşla" demektir:

450 4.2.1 The user you are trying to contact is receiving mail at a rate that prevents additional messages from being delivered.
421 4.7.0 Try again later, closing connection.

Bu yanıtları görüp gönderim hızını artırmaya devam ederseniz, ertesi gün 5xx kalıcı retlere döner. Postfix tarafında alıcı bazlı hız sınırı şöyle kurulur:

# /etc/postfix/main.cf
smtp_destination_concurrency_limit = 5
smtp_destination_rate_delay = 1s
default_destination_recipient_limit = 20

# Gmail'e özel daha yavaş politika için transport tanımı
transport_maps = hash:/etc/postfix/transport

# /etc/postfix/transport
gmail.com    smtp-gmail:

# /etc/postfix/master.cf içine eklenecek servis
smtp-gmail unix - - n - 3 smtp
    -o smtp_destination_concurrency_limit=3
    -o smtp_destination_rate_delay=2s

PTR, SPF, DKIM ve DMARC Kurulumu#

Dört kaydın hepsi kurulmadan toplu gönderime başlamayın; büyük sağlayıcılar 2024'ten bu yana toplu gönderici kabul edilen adresler için (Gmail tarafında günde 5.000'i aşan gönderim) kimlik doğrulamayı zorunlu tutuyor. Kurulum sırası önemlidir, çünkü DMARC diğerlerinin üzerine kurulur.

1. PTR (reverse DNS). Bu tek kayıt sizin kontrolünüzde değildir, IP'yi veren sağlayıcının yetkisindedir; panelden ya da destek talebiyle istenir. Doğrulama:

dig -x 1.2.3.4 +short
# beklenen: mail.sirketiniz.com.

# ve ileri yönlü de eşleşmeli (FCrDNS)
dig +short mail.sirketiniz.com
# beklenen: 1.2.3.4

İki yön birbirini tutmuyorsa çoğu büyük sağlayıcı bağlantıyı daha maildeki içeriğe bakmadan reddeder. Ayrıntı için ptr kaydı ve reverse dns yazısına bakabilirsiniz.

2. SPF. Alan adınız adına hangi IP'lerin mail gönderebileceğini ilan eder:

sirketiniz.com.   TXT   "v=spf1 ip4:1.2.3.4 -all"

-all (hard fail) yerine ~all (soft fail) ile başlamak ısıtma döneminde daha güvenlidir; kurulumun oturduğundan emin olduktan sonra sertleştirin. SPF'in 10 DNS sorgusu sınırı vardır — art arda include: eklerseniz kayıt geçersiz hâle gelir ve sessizce başarısız olur.

3. DKIM. Giden her maili özel anahtarla imzalar, alıcı DNS'teki genel anahtarla doğrular. OpenDKIM ile anahtar üretimi:

mkdir -p /etc/opendkim/keys/sirketiniz.com
opendkim-genkey -b 2048 -d sirketiniz.com -D /etc/opendkim/keys/sirketiniz.com -s mail -v
chown -R opendkim:opendkim /etc/opendkim/keys
cat /etc/opendkim/keys/sirketiniz.com/mail.txt

Çıktıdaki TXT değerini mail._domainkey.sirketiniz.com olarak DNS'e ekleyin. Yayıldığını doğrulayın:

dig +short mail._domainkey.sirketiniz.com TXT

4. DMARC. SPF ve DKIM sonuçlarını "From" başlığındaki alan adıyla hizalar ve uyumsuzlukta ne yapılacağını söyler. p=none ile başlayın, rapor toplayın, sonra sertleştirin:

_dmarc.sirketiniz.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; fo=1; adkim=r; aspf=r"

Bir hafta rapor topladıktan sonra p=quarantine, sonrasında p=reject'e geçilir. Üç kaydın birlikte nasıl çalıştığını spf, dkim ve dmarc kayıtları yazısında ayrıntılı bulabilirsiniz; kurulumu tamamladıktan sonra port, TLS ve HELO uyumunu SMTP test aracı ile doğrulayabilirsiniz.

Son bir kontrol: HELO/EHLO adı da PTR ile aynı olmalı. Postfix'te myhostname değeri mail.sirketiniz.com değilse, kimlik doğrulaması geçen mailiniz bile "tutarsız gönderici" olarak puanlanır.

postconf myhostname mydomain myorigin
swaks --to [email protected] --from [email protected] --server 127.0.0.1 --port 587 --auth

Blacklist'e Düşerseniz Ne Olur#

Kara listeye düşmek, çoğu kişinin sandığı gibi tek ve mutlak bir olay değildir; hangi listeye düştüğünüz sonucu tamamen değiştirir. Uygulamada üç ayrı seviye vardır:

En sinsi olanı üçüncü sıradır. Gmail ve Outlook kara liste yayınlamaz; sizi reddetmez, sessizce Spam klasörüne koyar. 250 OK yanıtı alırsınız, loglarınız tertemiz görünür, açılma oranınız ise dibe vurur. Bu durumda tek göstergeniz etkileşim metrikleridir — bu yüzden ısıtma sırasında sadece bounce'a değil, açılma oranına da bakın.

Kara listeye düştüğünüzde yapılacak sıra şudur:

1. Gönderimi tamamen durdurun. Kuyruğu boşaltmayın, dondurun: postsuper -h ALL.
2. Kaynağı bulun. Sunucu bir spam kaynağı hâline gelmişse, sebebi çoğu zaman açık relay ya da ele geçirilmiş bir hesaptır. Log kontrolü:

   grep "sasl_username" /var/log/mail.log | awk '{print $NF}' | sort | uniq -c | sort -rn | head
   postqueue -p | tail -1
   

3. Açık relay olmadığınızı doğrulayın. smtpd_relay_restrictions içinde permit_mynetworks, permit_sasl_authenticated, reject sırası olmalı.
4. Delisting başvurusu yapın. Listelerin çoğunda self-service kaldırma formu vardır; ancak sorunu düzeltmeden başvurursanız aynı gün geri listelenirsiniz ve tekrarlanan başvurular bekleme süresini uzatır.
5. Yeniden ısıtın. Delisting sonrası eski hacme dönmeyin; ısıtma takvimini 1. günden başlatın.

Adım adım sorgulama ve çıkış süreci için mail blacklist sorgulama ve çıkma yazısı bu konuyu ayrı ele alıyor.

Kurulum Sonrası İlk Hafta: Ölçüm ve Bakım#

Sunucu ayakta ve kayıtlar doğru; asıl iş buradan sonra başlar. İlk hafta boyunca günde bir kez şu üç şeye bakın:

Kuyruk sağlığı. Kuyruğun büyümesi, alıcıların sizi yavaşlattığının ilk işaretidir.

postqueue -p | tail -1
qshape deferred | head -20

qshape çıktısındaki sütunlar mailin ne kadar süredir beklediğini gösterir; belirli bir alan adının satırı sağa doğru şişiyorsa o sağlayıcı sizi throttle ediyordur.

Ret sebeplerinin dağılımı. Ham log içinde hangi hatanın baskın olduğunu görmek, tahmin yürütmekten iyidir:

grep " status=bounced" /var/log/mail.log \
  | sed -E 's/.*said: //' | cut -c1-60 | sort | uniq -c | sort -rn | head -15

DMARC raporları. rua adresine gelen XML raporlar, sizin adınıza kimin mail gönderdiğini ve hizalamanın nerede kırıldığını gösterir. İlk hafta bu raporlarda kendi uygulama sunucunuzu SPF'te unuttuğunuzu görmeniz çok olasıdır.

Bunun ötesinde, sunucuyu tek başına bırakmayın. Bir mail sunucusu diskin dolmasına diğer servislerden daha duyarlıdır: /var/spool/postfix şiştiğinde kuyruk yazılamaz ve gönderim sessizce durur. Basit bir izleme kurulumu (netdata ile sunucu izleme yazısındaki gibi) disk, kuyruk uzunluğu ve 25/587 port erişilebilirliğini takip etmeye yeter. Postfix + Dovecot tabanlı tam kurulumu sıfırdan yapacaksanız postfix ve dovecot ile mail sunucu kurulumu, panelli bir çözüm istiyorsanız mailcow mail sunucu kurulumu adım adım anlatıyor.

Sıkça Sorulan Sorular#

Kendi SMTP sunucumdan günde kaç mail gönderebilirim#

Teknik bir üst sınır yoktur; sınırı alıcı tarafındaki sağlayıcılar koyar. Isınmış, itibarı iyi tek bir IP'den günde yüz binlerce mail gönderilebilir, ancak bu rakama ilk günde değil haftalar süren kademeli artışla ulaşılır. Aynı sunucudan aynı anda kaç bağlantı açtığınız da önemlidir: paralel bağlantı sayısını yükseltmek gönderimi hızlandırmaz, yalnızca throttling'e daha hızlı çarpmanızı sağlar. Pratikte hacim planlaması yaparken IP başına günlük hedefi belirleyip listeyi ona göre dilimlemek en sağlıklı yöntemdir.

SMTP sunucu almadan önce alan adım kaç günlük olmalı#

Alan adınızın en az birkaç aylık, tercihen bir yıldan eski ve halihazırda web sitesi yayında olan bir alan adı olması teslim edilebilirliği belirgin şekilde artırır. Yeni tescil edilmiş alan adları spam filtreleri tarafından ek şüpheyle karşılanır, çünkü tek kullanımlık spam kampanyalarının tipik imzası budur. Zorunlu olarak yeni bir alan adı kullanacaksanız, önce siteyi yayına alıp normal işlemsel maillerle birkaç hafta düşük hacimli trafik oluşturun. Mümkünse yerleşik ana alan adınızın bir alt alan adından gönderin.

Paylaşımlı hostingten toplu mail gönderebilir miyim#

Teknik olarak gönderebilirsiniz ama saatlik ve günlük limitler nedeniyle toplu kampanya için uygun değildir. Paylaşımlı hostingte çıkış IP'si onlarca hesapla ortaktır; sizin gönderiminiz komşuların itibarını, onların gönderimi de sizinkini etkiler. Ayrıca limit aşımı çoğu sağlayıcıda hesabın geçici olarak askıya alınmasıyla sonuçlanır ve bu sırada sitenizin işlemsel mailleri de durur. Bülten gibi düzenli toplu gönderim yapacaksanız gönderimi hosting hesabından ayırmak, sadece performans değil risk yönetimi meselesidir.

SMTP relay ile kendi mail sunucusu arasındaki fark nedir#

SMTP relay, mailinizi kabul edip alıcıya kendi IP havuzundan teslim eden aracı bir servistir; kendi mail sunucusunda ise teslim işini kendi IP'nizden siz yaparsınız. Relay kullandığınızda kimlik doğrulama kayıtlarını sağlayıcının talimatına göre eklersiniz ve itibar yönetimi büyük ölçüde onlarda kalır. Kendi sunucunuzda ise SPF, DKIM, PTR, bounce işleme ve kara liste takibinin tamamı size aittir. Birçok kurum ikisini birlikte kullanır: pazarlama maillerini kendi sunucusundan, kritik işlemsel maillerini ayrı bir kanaldan gönderir.

Isıtma sürecini hızlandırmanın bir yolu var mı#

Isıtmayı kısaltmanın tek meşru yolu, en yüksek etkileşimli aboneleri ilk günlerde hedeflemektir. Açılma ve tıklanma oranı yüksek bir segmentle başlamak, alıcı sağlayıcılara olumlu sinyali daha hızlı üretir ve hacim artışını rahatlatır. Buna karşılık gönderim hacmini plan dışı sıçratmak, ısıtmayı hızlandırmaz; büyük ihtimalle sıfırlar ve baştan başlamanız gerekir. Ara vermeden her gün göndermek, tek bir günde yüksek hacim göndermekten çok daha etkilidir.

Mailim Gmail'de spam klasörüne düşüyorsa ne yapmalıyım#

Öncelikle kimlik doğrulamanın Gmail tarafında geçtiğini doğrulayın: maili açıp "Orijinali göster" dediğinizde SPF, DKIM ve DMARC satırlarının üçünde de PASS görmelisiniz. Üçü de geçiyorsa sorun teknik değil itibarla ilgilidir; hacmi kesip yalnızca son 30 günde etkileşim gösteren adreslere göndermeye dönün. İçerik tarafında tek bir görselden ibaret mailler, kısaltılmış bağlantılar ve büyük harfli konu başlıkları puanı aşağı çeker. Ayrıca tek tıkla abonelikten çıkma başlığını eklemek, kullanıcıları "spam olarak işaretle" düğmesine yönelmekten alıkoyar ve şikâyet oranını doğrudan düşürür.

Aynı sunucudan hem bülten hem sipariş maili göndermek sorun olur mu#

Aynı IP'den göndermek çalışır ama risk yönetimi açısından önerilmez. Bülten gönderimi doğası gereği şikâyet ve bounce üretir; bu iki metrik IP itibarını aşağı çektiğinde, aynı IP'den giden şifre sıfırlama ve sipariş onayı mailleri de birlikte etkilenir. Müşteri siparişini onaylayan maili alamadığında bu doğrudan gelir kaybıdır. Kaynaklarınız elveriyorsa iki ayrı IP ya da iki ayrı alan adı (bulten.sirketiniz.com ve siparis.sirketiniz.com) kullanmak, sorun çıktığında hasarı tek kanalla sınırlar.

SMTP sunucusunda hangi portlar açık olmalı#

Giden gönderim için 25, kullanıcı kimlik doğrulamalı gönderim için 587 (STARTTLS) ve implicit TLS için 465 kullanılır. Sunucudan dışarı çıkan trafikte 25 numaralı portun sağlayıcı tarafından açık olduğundan emin olun; birçok altyapıda spam nedeniyle bu port varsayılan olarak kapalıdır ve talep üzerine açılır. Uygulamalarınızın sunucuya bağlanacağı port 587 olmalı, 25 istemci kimlik doğrulaması için kullanılmamalıdır. IMAP/POP3 ile posta okunacaksa ayrıca 993 ve 995 portları gerekir.

Kapanış#

SMTP sunucu satın alma kararı, aslında bir makine kararı değil bir sorumluluk kararıdır. Donanım tarafı en kolay kısım; iş asıl özel IP'nin itibarını sıfırdan inşa etmekte, ısıtma takvimine sadık kalmakta, PTR-SPF-DKIM-DMARC dörtlüsünü doğru sırayla kurup DMARC raporlarını okumakta ve kara listeye düştüğünüzde paniğe kapılmadan kaynağı bulup delisting sürecini yürütmekte. Bu operasyonu üstlenecek biriniz varsa kendi sunucunuz uzun vadede hem daha ucuz hem daha esnektir; yoksa hazır bir servis, ödediğiniz farkın karşılığını fazlasıyla verir. Karar kriteri hacminiz değil, bu bakımı kimin yapacağıdır.

Kendi gönderim altyapınızı kurmaya karar verdiyseniz, önceden yapılandırılmış bir gönderim ortamı için SMTP sunucu paketleri, her şeyi kendiniz kurgulamak istiyorsanız VDS sunucu seçenekleri uygun başlangıç noktalarıdır. Kurumsal posta kutularınızı da aynı yapıya taşımak isterseniz kurumsal e-posta hizmeti, kampanya tarafını uçtan uca yönetilen bir hizmet olarak almak isterseniz e-posta pazarlama sayfalarına bakabilirsiniz. Sunucunun günlük bakımını üstlenecek kimseniz yoksa sunucu yönetimi hizmeti bu işi devralır.