Ofisteki Küçük Kriz: “E-postalar niye gitmiyor?”
Satış tekliflerinin spam klasörüne düşmesi, tek bir DNS kaydından kaynaklanmayabilir. Varsayımsal bir incelemede önce gönderim günlüğü, alıcının verdiği SMTP yanıtı ve teslim edilen iletinin doğrulama sonuçları birlikte değerlendirilir. SPF, DKIM, DMARC ve rDNS, gönderen kimliğini açıklığa kavuşturur; ancak iyi yapılandırılmış bir sunucu bile içerik, şikâyet veya itibar sorunları nedeniyle gelen kutusuna ulaşamayabilir.
Bu yazıda, seni hiç boğmadan şu dört kahramanı tek tek ele alacağım: SPF, DKIM, DMARC ve rDNS. Her birini, “Neden önemli?”, “Sunucuda nasıl yapılandırılır?” ve “Neleri kontrol etmelisin?” diye akıcı bir akışla işleyeceğiz. Mesela şöyle düşün: Domainin bir kimlik kartıysa, SPF kimlerin adına konuşabileceğini söyler; DKIM imzayı basar; DMARC hakemi oynar; rDNS ise kapıdaki güvenlik görevlisine kim olduğunu net anlatır. Bu kontroller farklı kimlikleri değerlendirir; doğru kurulum teslimat garantisi vermez.
Adım adım anlatacağım. Gerektiğinde ekran başında birlikte ayar yapıyormuşuz gibi, küçük notlar ve ipuçları bırakacağım. Sonunda, bir denetim listesiyle tüm taşları yerine koyacağız. Hazırsan başlayalım.
Önce Temel Mantık: Neyi, Neden Yapıyoruz?
Alıcılar bağlantı IP’si, DNS, mesaj kimlikleri ve davranışsal sinyalleri değerlendirir. Tutarlılık, bütün adların harfiyen aynı olması demek değildir. SPF zarf gönderenini, DKIM imzalayan alanı, DMARC ise görünür From alanıyla gerekli uyumu denetler. rDNS bağlantı IP’sinin adlandırılmasıyla ilgilidir; bu dört kontrol mesajın güvenli içerik taşıdığını veya bir insan tarafından yazıldığını kanıtlamaz.
Bir benzetmeyle SPF yetki listesidir, DKIM imzadır, DMARC görünür gönderen alanıyla ilişkiyi ve alan sahibinin politikasını bildirir, rDNS ise IP için geri arama kaydıdır. Bu rolleri ayırmak, örneğin SPF başarılıyken neden DMARC başarısız olabildiğini anlamayı kolaylaştırır.
Bu yüzden her adıma tek tek bakacağız; ama akılda tutman gereken büyük resim şu: DNS ve sunucu ayarlarının birbiriyle konuştuğundan emin ol. Aksi halde bir yerde bir kırık halka teslimat zincirini zayıflatır.
SPF: Kimler Benim Adıma Konuşabilir?
SPF, bağlantı kuran IP’nin SMTP zarfındaki MAIL FROM alan adı adına gönderim yapmaya yetkili olup olmadığını değerlendirir; görünür From başlığını doğrudan doğrulamaz. Boş zarf göndereni gibi durumlarda HELO kimliği de önem taşır. Önce uygulama, pazarlama ve destek servislerinin gerçek zarf alanlarını ve çıkış IP’lerini envantere alın. Her hizmetin mutlaka kök alan SPF kaydını kullandığını varsaymayın.
TXT kaydını SPF’nin gerçekten değerlendirdiği alan adına yayınlayın; bu kök alan veya bir dönüş alt alanı olabilir. Aynı ad için birden fazla v=spf1 kaydı oluşturmayın. Aşağıdaki IP belgeleme içindir; gerçek, yetkili çıkış IP’nizle değiştirin. Üçüncü taraf kullanılıyorsa yalnız sağlayıcının size verdiği doğrulanmış include değerini ekleyin:
Örnek SPF kaydı:
v=spf1 ip4:203.0.113.10 -all
ip4 ilgili IPv4 adresini yetkilendirir; IPv6 ile gönderim varsa uygun ip6 mekanizması da gerekir. a ve mx, kendi web veya gelen posta sunucularınızı otomatik olarak güvenli gönderici yapmaz: yalnız gerçekten gönderim yapıyorlarsa kullanın. include başka bir SPF politikasının başarılı eşleşmesine dayanır. -all eşleşmeyen IP için fail, ~all softfail üretir; alıcının mesajı kesin reddedeceği anlamına gelmez. Her iki sonuç da SPF pass değildir. Politika seçmeden önce bütün meşru kaynakları doğrulayın.
SPF değerlendirmesinde DNS sorgusu doğuran include, a, mx, ptr, exists ve redirect terimleri iç içe değerlendirmelerle birlikte en fazla 10 olabilir; aşım permerror üretir. ip4, ip6 ve all bu sayaca dahil değildir. Tek TXT kaydını birden fazla metin parçasına bölmek bu sınırı aşmaz veya sıfırlamaz; parçalar boşluk eklenmeden birleştirilir. Gereksiz kaynakları kaldırın. Sağlayıcı IP’lerini elle flatten etmek, adres değişikliklerini takip eden güvenilir bir güncelleme süreci olmadan politikayı eskitebilir.
SPF pass, DMARC için tek başına yeterli olmayabilir. Başarılı SPF kimliğinin alanı görünür From alanıyla seçilen uyum kuralına göre ilişkili olmalıdır. Örneğin bounce.example.com ile example.com, aynı kurumsal alan altında gevşek uyuma uygun olabilir; katı uyumda alanların tam eşleşmesi gerekir.
DKIM: İmzanı Bas, Mesajına Sahip Çık
DKIM, seçilen başlık alanlarını ve gövdeyi normalleştirme kuralları kapsamında özel anahtarla imzalar. Alıcı, selector ve imzadaki d= alanına göre DNS’teki açık anahtarı bulup doğrular. Başarılı imza, imzalayan alanın sorumluluğunu ve imzalanan verinin bütünlüğünü destekler; bütün başlıkların imzalı olduğunu, gönderen kişinin kimliğini veya içeriğin güvenliğini kanıtlamaz.
Uygulama tarafında iki yol görürsün. Ya kullandığın kontrol paneli üzerinden kolayca anahtar üretirsin ya da sunucunda DKIM servisleri (OpenDKIM gibi) ile çalışırsın. Kontrol paneli kullanıyorsan, mesela AlmaLinux üzerinde cPanel kurulumu adımlarını tamamladıktan sonra, e-posta bölümündeki DKIM kaydını yetkili DNS’e yayınlayıp gerçek çıkış iletisinde imzalama ve doğrulamayı test edin. DNS başka sağlayıcıdaysa panelde kayıt görünmesi yayınlandığını göstermez. Manuel çalışıyorsan, sunucuda bir anahtar çifti üretirsin; özel anahtar MTA tarafından saklanır, açık anahtar DNS’te yayınlanır.
Her anahtar için m1 gibi bir selector kullanın. Rotasyonda önce yeni selector’ın açık anahtarını yayınlayıp DNS görünürlüğünü doğrulayın, sonra yeni özel anahtarla imzalamaya geçin. Eski açık anahtarı, daha önce imzalanmış ve kuyrukta kalmış iletilerin doğrulanması gereken süre boyunca tutun. Süreyi DNS önbelleği, kuyruk ve olay müdahalesi politikanız belirler; herkese uyan altı aylık bir kural yoktur. Örnekteki anahtar metni çalışır bir anahtar değildir:
Örnek DKIM DNS kaydı:
m1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=UZUN_BASE64_ANAHTAR"
Bir test iletisinde DKIM-Signature başlığının bulunmasıyla yetinmeyin; alıcının güvenilir Authentication-Results kaydında doğrulama sonucunu ve d= alanını kontrol edin. İmzadan sonra gövdeyi veya imzalı başlıkları değiştiren ağ geçitleri geçerli imzayı bozabilir; bu yalnız “zayıf anahtar” sorunu değildir. Gönderim yolunu ve kullanılan normalleştirmeyi birlikte inceleyin.
DMARC: Hakem Sahaya İner
DMARC, görünür From alanı için kimlik uyumunu ve alan sahibinin başarısız mesajlar hakkındaki politikasını bildirir. En az bir başarılı ve uyumlu SPF veya DKIM sonucu DMARC geçişi sağlayabilir; ikisinin de mutlaka geçmesi gerekmez. Bununla birlikte ikisini de doğru kurmak ve özellikle yönlendirme akışlarında DKIM’i korumak önemlidir. Alıcı, DMARC dışında da içerik ve itibar kontrolleri yapar.
Politikayı görünür From alanının _dmarc adı altında tek bir TXT kaydı olarak planlayın. Örneğin example.com için _dmarc.example.com kullanılır. Aşağıdaki rapor adresi yer tutucudur; rapor alabilen ve erişimi denetlenen kendi adresinizle değiştirin:
Örnek DMARC kaydı (izleme modu):
v=DMARC1; p=none; rua=mailto:dmarc-rapor@example.com; adkim=r; aspf=r
p=none, DMARC başarısızlığı için özel yaptırım istemeyen izleme politikasıdır; mesajın spam’e düşmesini önlemez. adkim=r ve aspf=r gevşek uyumu, s ise tam alan eşleşmesini seçer. Sırf daha katı göründüğü için s kullanmayın; gerçek gönderen mimarisine göre karar verin. rua toplu rapor talep eder; her alıcı rapor göndermez ve raporlar tüm trafiğin eksiksiz kaydı değildir. İsteğe bağlı ruf hata raporları hassas ileti verisi içerebilir; bu başlangıç örneği onları istemez.
Güncel DMARC standardı RFC 9989, eski pct etiketini kaldırmıştır; yüzde 25 gibi bir geçişin alıcılarca güvenilir biçimde uygulanacağını varsaymayın. Yaptırım kararını doğrulanmış göndericilere, raporlara ve yönlendirme/posta listesi etkisine göre verin. Genel amaçlı kullanıcı alanlarında p=reject evrensel hedef değildir; posta listesi kullanıcılarında uyumluluk sorunu yaratabilir. Böyle bir alan reject’i değerlendiriyorsa standart en az bir ay none, ardından benzer süre quarantine sonuçlarının karşılaştırılmasını önerir. Reject yayımlayan alan, yalnız SPF’ye güvenmemeli ve geçerli DKIM imzaları kullanmalıdır. Alt alanlar için sp politikasını ve açık alt alan kayıtlarını birlikte inceleyin; dış rapor adresleri için alıcı alanın yetkilendirmesi gerekebilir.
rDNS (PTR): Kapıdaki Güvenlik Görevlisi
rDNS, gönderim IP’sini PTR kaydıyla bir ada eşler. Bu adın ileri DNS kaydı da kullanılan IP’ye dönmelidir: IPv4 için A, IPv6 için AAAA. Bu ilişki sunucunun bağlantı kimliğini destekler; görünür From alanının sahipliğini doğrulamaz ve DMARC uyumunun bir parçası değildir.
Çoğu zaman PTR’ı sen değil, IP’yi kullandıran sağlayıcı ayarlar. Destek talebi açıp “X.X.X.X IP’si için PTR’ı mail.ornek.com olarak ayarlayabilir misiniz?” diye rica edersin. Ayar yapılmadan önce “mail.ornek.com” ilgili A veya AAAA kaydını IP’ye yönlendirmiş olman gerekir. Ardından MTA’nın host isimlerini, EHLO/HELO değerlerini de bu isme sabitle. Böylece bağlantı anında söylediğin isim ile DNS’te görülen isim aynı olur.
Birden fazla meşru çıkış IP’si kullanılabilir; her biri için PTR ve ileri çözümlemeyi ayrı doğrulayın. MTA’nın dışarı gönderdiği EHLO adı çözümlenebilir ve mimariyle tutarlı olmalıdır. TLS sunucusu sunduğunuzda sertifikanın, istemcilerin doğruladığı hizmet adını kapsaması gerekir; bir istemci sertifikası veya PTR ile eşleşen sertifika bütün dış SMTP teslimatlarının evrensel şartı değildir.
Sunucuda Adım Adım Yapılandırma: Pratik Yol Haritası
Birlikte bir yol çizelim. Önce DNS kayıtlarını planla. Alan adın için SPF’i yaz, DKIM anahtarını üret, DMARC’ı izleme modunda yayınla. Ardından IP’nin PTR’ını ayarlat. Sunucu tarafında hostname’i “mail.ornek.com” yap, MTA’nın EHLO adını buna sabitle ve sunduğun TLS hizmetinin sertifika adlarını doğrula. Dış bağlantı TLS politikasını ayrıca test et.
Kontrol paneli kullanıyorsan bu adımlar büyük ölçüde yönlendirmelerle çözülür. Manuel yönetiyorsan, hizmetlerin birbiriyle konuştuğunu kontrol et. Posta kuyruğunda takılan mesajlar var mı, loglarda “reverse mismatch” benzeri uyarılar çıkıyor mu, dikkat et. Bağlantı zaman aşımları genelde ağ ve güvenlik duvarı ile ilgilidir; sunucudan sunucuya SMTP için 25 ile istemci gönderim hizmetleri 465/587’nin rollerini ayırın. Yalnız gereken hizmetleri açın; sağlayıcının dış 25 kısıtını da kontrol edin. İhtiyaç halinde güvenlik duvarı kurallarını sağlam kurgulamak iyi bir başlangıçtır.
Sunucunun genel hijyeni de önemli. Güncellemeleri ihmal etme, yetkisiz açık röle bırakma, beklenmedik bir servis e-posta çıkışı yapıyorsa engelle. Kaynakları dengeli kullan; CPU ve disk tavan yaparsa MTA gecikmeye düşer. Güvenlik tarafında da, SSH erişimi, fail2ban benzeri korumalar ve sunucu güvenliği için pratik, ölçeklenebilir ve doğrulanabilir yaklaşımlar teslim edilebilirliğe dolaylı katkı verir. Ağ altyapını düşünürken de DDoS saldırılarına karşı alınabilecek adımlar bir gün hayat kurtarır.
İçerik ve Liste Hijyeni: Sunucu Kadar Önemli
Kimlik doğrulama başarılı olsa bile içerik, izin durumu, şikâyetler ve gönderim davranışı teslimatı etkiler. Görsel veya bağlantı sayısı için evrensel bir spam formülü yoktur. Gönderen adı ve konu mesajı doğru tanımlamalı; işlem e-postasıyla pazarlama içeriği karıştırılmamalıdır. Alıcının beklediği içerik, açık abonelikten çıkış ve şikâyetleri izlemek önemlidir.
Bir başka kritik başlık: Liste temizliği. Bir süre kullanılmayan adreslere ısrarla gönderim yapmak, sert geri dönüşleri artırır. Hard bounce gördüğün adresleri hızlıca listeden çıkar, soft bounce için makul tekrar deneme politikaları uygula. Abonelikten çıkmayı kolaylaştır, tek tıkla ayrılabilsinler. Yeni bir IP veya alan adıyla gönderime başlıyorsan, küçük hacimlerle ısınma süreci uygula. Bir anda yüksek hacimli gönderim filtreler için alarm olabilir. Gmail’in toplu gönderici kurallarında pazarlama ve abonelik iletileri için tek tıkla çıkış başlıklarıyla birlikte gövdede görünür çıkış bağlantısı gerekir; yalnız bağlantı koymak tek tıkla çıkış protokolü yerine geçmez.
Test ve İzleme: Görmediğini Yönetemezsin
Test etmek için pratik araçlar var. Kayıtlarını ekledikten sonra MXToolbox üzerindeki SPF, DKIM ve DMARC testleri ile ilk kontrolü yap. Gmail tarafındaki durumunu görmek için Google Postmaster Tools paneli işe yarar; orada etki alanı ve IP itibarını, spam oranlarını zaman içinde izleyebilirsin. Microsoft tarafı için Microsoft SNDS aracı Microsoft ağındaki IP verilerini değerlendirmek için ayrı bir kaynaktır; Google verisi Microsoft’un kararını açıklamaz.
Önbelleklerin ve yetkili DNS’in yeni kaydı gösterdiğini doğrulayın. Her gerçek gönderim kaynağından size ait test adreslerine ileti gönderin; alıcının eklediği doğrulama sonuçlarını, SMTP hata kodlarını ve uygulama kayıtlarını birlikte okuyun. Sonra hacmi, şikâyetleri ve kalıcı/geçici teslimat hatalarını izleyin. Rapor gelmemesi tüm iletilerin geçtiğini kanıtlamaz.
Sık Yapılan Hatalar: Küçük Taşlar, Büyük Etki
Yeni bir otomasyon veya SaaS göndericisi devreye girdiğinde gerçek zarf alanı, DKIM d= alanı ve görünür From uyumu kontrol edilmelidir. Değişim yönetimine e-posta kimlik doğrulama etkisini ekleyin; sağlayıcının SPF kaydını yanlışlıkla her alan adına eklemeyin.
Yeni selector DNS’te yayınlanmadan imzalama anahtarını değiştirmek DKIM doğrulamasını bozabilir. Yeni kaydı önce doğrulayın, eski anahtarı ihtiyaç süresi boyunca koruyun ve gerçek gönderimle test edin. DMARC yaptırımını da yalnız takvim dolduğu için artırmayın; yönlendirilmiş iletiler, posta listeleri ve seyrek çalışan sistemler değerlendirmeye dahil olmalıdır.
PTR ve ileri çözümlemeyi gerçek çıkış IP’si üzerinden kontrol edin. EHLO adıyla gelen SMTP banner’ını karıştırmayın; dış teslimatta alıcının gördüğü kimlik önemlidir. TLS hatasında ise hangi uç noktaya bağlanıldığını ve hangi sertifika adının doğrulandığını inceleyin. Bu düzeltmeler itibarın belirli sürede toparlanacağını garanti etmez.
İnce Ayarlar: Küçük Dokunuşlarla Büyük Fayda
Eğer iletim sırasında şifreleme konusunda da çıtayı yükseltmek istersen, MTA’nda modern TLS sürümlerini açık tut ve zayıf şifre takımlarını devre dışı bırak. Sertifikan güncel kalmalı, sona erme tarihini otomatik hatırlatıcılara bağla. Ayrıca, iletim gecikmeleri görürsen, DNS çözümleme hızlarını ve sunucu kaynaklarını gözden geçir; bazen bir cache katmanı veya resolver değişikliği nefes aldırır.
İçerik tarafında marka kimliğini güçlendirmek için logonu doğrulayan yöntemler gündeme gelebilir, ama bunlar SPF/DKIM/DMARC/rDNS dörtlüsünün tamamlayıcısıdır. Önce bu omurgayı sağlam kur, sonra süslemelere geç. İstersen ileride e-posta gönderimi kadar web uygulamalarının da performansını iyileştirmek için farklı yöntemlere bakabilirsin; buna örnek olarak Redis cache ile hız kazanmanın pratik etkileri hem uygulama deneyimini hem de altyapı sağlığını iyileştirir.
Mini Denetim Listesi: Bir Çırpıda Gözden Geçir
Yayın öncesi her gerçek gönderim kaynağını kontrol edin: SPF kimliği ve kaydı doğru mu, DKIM imzası alıcıda doğrulanıyor mu, en az bir başarılı kimlik From alanıyla uyumlu mu? DMARC raporlarının kapsamı ve politika etkisi anlaşılıyor mu? Her çıkış IP’sinin PTR ve A/AAAA ilişkisi doğru mu? Gerekli TLS bağlantıları, kuyruklar, hata kodları, abonelikten çıkış ve bastırma listeleri test edildi mi? Sonuçları kaydedin ve değişiklik sonrasında tekrar karşılaştırın.
Kapanış: “Gönder” Tuşuna Daha Rahat Bas
Başlangıçtaki varsayımsal teslimat sorununda izlenecek sıra, kanıt toplamaktan geçer: gerçek göndericileri belirlemek, SPF ve DKIM’i doğrulamak, DMARC uyumunu incelemek ve IP/DNS ilişkisindeki hataları düzeltmek. Bunlar tutarlı kimlik sağlar; gelen kutusu yerleşimi için içerik, alıcı beklentisi ve gönderim davranışı da izlenmelidir.
Sen de adımları sakince uygula. Önce kayıtlarını doğru yaz, sonra raporları dinle, içerik ve liste hijyenine özen göster. Gerekirse ağ ve güvenlik tarafını gözden geçir; kapıları gereksiz yere kapatma ama açık da bırakma. Panel kullanıyorsan ilgili menüleri gez, manuel yönetiyorsan notlarını düzenli tut. İhtiyaç duyduğunda, sunucu tarafında güvenlik notlarına veya güvenlik duvarı tüyolarına tekrar göz atmak iyi gelir. Umarım bu rehber, “Gönder” tuşuna basarken içini rahatlatır. Takıldığın bir nokta olursa notlarını topla, küçük testlerle ilerle, sonuçları ölçüp bir sonraki değişikliği buna göre seç. Bir dahaki yazıda görüşürüz.
