Gmail ve Outlook/Hotmail hesaplarına gönderilen e-postalarınız hiç teslim edilmeden geri dönüyor ya da spam klasörüne düşüyor mu? Bu durum tesadüf değildir; arkasında RFC standartlarına dayanan katmanlı bir kimlik doğrulama sistemi yatmaktadır. Bu rehberde ret nedenlerini, hata kodlarını ve kalıcı çözüm yollarını teknik düzeyde ele alıyoruz.
Küçük veya orta ölçekli posta sunucuları genellikle daha hoşgörülüdür; ancak Gmail ve Outlook/Hotmail dünya e-posta trafiğinin büyük bölümünü işlediğinden güvenlik politikaları da buna orantılı olarak katıdır. Google, Postmaster Tools (postmaster.google.com) adlı herkese açık aracıyla gönderenler için alan adı itibar skoru yayımlar. Microsoft ise Smart Network Data Services (SNDS) ve Junk Mail Reporting Program (JMRP) platformları aracılığıyla benzer bir şeffaflık sunar.
Her iki sağlayıcı da RFC 5321'de tanımlanan SMTP protokolü üzerine ek kontrol katmanları inşa etmiştir. Bu katmanları anlamadan sadece "tekrar dene" yaklaşımıyla sorunu çözmeye çalışmak zaman kaybıdır.
RFC 7208 ile standartlaştırılan SPF, alıcı sunucunun bir e-postayı gönderen IP adresinin, gönderen alan adının DNS kayıtlarında yetkili olup olmadığını denetlemesini sağlar. Alan adınızın DNS'inde bir TXT kaydı olarak yayımlanır. Örnek bir SPF kaydı şu şekildedir:
v=spf1 ip4:203.0.113.10 include:spf.connect365.com.tr ~all
Kaydın sonundaki ~all (softfail) yerine -all (hardfail) kullanılması, yetkisiz kaynaklardan gelen postaların reddedilmesi için daha güçlü bir sinyal gönderir. SPF mekanizması, RFC 5321'de tanımlanan "MAIL FROM" zarfı üzerinden kontrol gerçekleştirir; bu nedenle başlıkta görünen "From" adresiyle her zaman örtüşmeyebilir.
RFC 6376 ile tanımlanan DKIM, gönderen posta sunucusunun e-postaya kriptografik bir imza eklemesine olanak tanır. Alıcı sunucu, bu imzayı DNS'te yayımlanan açık anahtarla doğrular. İmza, DKIM-Signature başlığı aracılığıyla iletilir ve başlıklar ile gövdenin belirtilen bölümlerini kapsar. DKIM'nin kritik avantajı, mesajın aktarım sırasında değiştirilmediğini kanıtlamasıdır; bu sayede SPF'nin ulaşamadığı "yönlendirilmiş e-posta" senaryolarında da doğrulama mümkün olur.
RFC 7489 ile standartlaştırılan DMARC, SPF ve DKIM'yi bir üst katmanda birleştirir ve alan adı sahibine politika belirleme yetkisi verir. DMARC politikası üç modda çalışır:
DMARC ayrıca rua (aggregate) ve ruf (forensic) raporlama adreslerini destekler; bu raporlar, yetkisiz gönderim girişimlerini tespit etmek için son derece değerlidir. Google, 2024 yılında bulk gönderenler (günde 5.000'den fazla mesaj) için DMARC politikası zorunlu hale getirmiştir.
SMTP ret yanıtları RFC 5321'de tanımlanan üç basamaklı kodlara göre sınıflandırılır. Aşağıdaki tablo, Google ve Microsoft'tan alınan en yaygın ret kodlarını ve olası nedenlerini özetlemektedir:
| SMTP Kodu | Sağlayıcı | Tipik Mesaj / Durum | Olası Neden |
|---|---|---|---|
| 550 5.7.1 | Gmail | Message rejected due to policy | DMARC politikası ihlali (p=reject), SPF/DKIM başarısızlığı |
| 550 5.7.26 | Gmail | This message fails DMARC checks | DMARC hizalaması (alignment) sorunu; "From" alanı SPF/DKIM alan adıyla örtüşmüyor |
| 550 5.7.25 | Gmail | IP not in SPF record | Gönderen IP, alan adının SPF kaydında tanımlı değil |
| 421 4.7.0 | Gmail | TLS required | Bağlantı şifrelenmemiş; STARTTLS veya SMTPS zorunlu |
| 550 5.7.350 | Outlook/Microsoft | Remote server returned an error | Genel politika reddi; SPF/DKIM/DMARC kombinasyon hatası |
| 550 5.7.1 | Outlook | Unfortunately, messages from [IP] weren't sent | Gönderen IP'nin Microsoft tarafında kara listede olması |
| 451 4.7.500 | Outlook | Server busy, please try later | Geçici gönderim hızı kısıtlaması (rate limiting); itibar skorunun düşük olması |
| 550 5.4.1 | Outlook | Recipient address rejected | Hedef adres mevcut değil veya alan adı MX kaydı hatalı |
Google, Şubat 2024 itibarıyla günde 5.000 veya daha fazla mesaj gönderen alan adları için üç koşulu zorunlu kıldı: (1) SPF veya DKIM kimlik doğrulaması uygulanmış olmalı, (2) alan adında DMARC politikası yayımlanmış olmalı (en azından p=none), (3) pazarlama ve abonelik e-postalarında RFC 2369 ve RFC 8058'de tanımlanan tek tıkla abonelikten çıkma (one-click unsubscribe) başlığı yer almalıdır. Bu koşulların herhangi birini karşılamayan gönderenler önce spam filtresi baskısıyla, ardından doğrudan SMTP reddiyle karşılaşır. Koşulların ayrıntısı Google'ın resmi Email Sender Guidelines sayfasında belgelenmiştir.
Outlook.com ve Microsoft 365 (eski adıyla Exchange Online Protection — EOP), SPF/DKIM/DMARC'ın yanı sıra "Composite Authentication" olarak adlandırdıkları bir puanlama sistemi kullanır. Bu sistem, geçmişe dayalı gönderim davranışını, kullanıcı şikayetlerini ve liste hijyenini de hesaba katar. Bir IP veya alan adı bu puanlama sisteminde düşük skor alırsa, teknik kimlik doğrulama başarılı olsa dahi posta spam klasörüne yönlendirilebilir. Microsoft, bu konudaki teknik belgeleri Microsoft Learn (learn.microsoft.com) platformunda yayımlamaktadır.
Microsoft ayrıca "Authenticated Received Chain" (ARC — RFC 8617) protokolünü destekler; yönlendirilmiş ya da dönüştürülmüş postalarda kimlik doğrulama zincirini korumak için bu protokolden yararlanılabilir.
RFC 5321, gönderen IP adresi için geçerli bir PTR kaydı bulunmasını önerir; Google ve Microsoft bu öneriyi fiilen zorunluluk olarak uygular. PTR kaydı yoksa ya da IP'nin forward DNS kaydıyla örtüşmüyorsa (bazen "forward-confirmed reverse DNS" — FCrDNS olarak anılır) mesaj doğrudan reddedilebilir. PTR kaydı, sunucunuzun barındırıldığı IP bloğunu yöneten ISP veya veri merkezi tarafından oluşturulur; bu nedenle değişiklik talepleri hosting sağlayıcınıza yapılmalıdır.
Yeni bir IP adresinden yüksek hacimde e-posta göndermek, hem Google hem de Microsoft'un spam filtrelerini tetikler. Alıcı sağlayıcılar, bilinmeyen IP'lerden gelen ani trafik artışını şüpheyle karşılar. Bu nedenle yeni bir IP'yi "ısıtmak" (warm-up) gerekir: ilk hafta günde birkaç yüz mesajla başlayıp her hafta hacmi kademeli olarak artırmalısınız. Google Postmaster Tools ve Microsoft SNDS üzerinden IP'nizin itibar skorunu düzenli olarak izleyebilirsiniz.
Paylaşımlı IP kullanıyorsanız, aynı IP'yi kullanan başka bir gönderenin kötü davranışı sizi de olumsuz etkileyebilir. Bu risk, özel (dedicated) IP kullanımını haklı kılan temel gerekçelerden biridir.
Teknik altyapı kusursuz olsa bile içerik ve liste kalitesi ret kararını belirleyebilir. Yüksek hemen çıkma (bounce) oranı, Google ve Microsoft'un gönderen itibarını düşürür. RFC 2821'de "permanent failure" olarak tanımlanan 5xx hataları alan adresler listeden çıkarılmalıdır. Benzer şekilde, alıcıların "Spam olarak işaretle" düğmesine tıklama oranı — şikâyet oranı — Google'ın Postmaster Tools aracında izlenebilir; bu oran %0,1'in üzerine çıktığında teslimat hızla bozulmaya başlar.
Redlerin nedenini belirlemek için şu araçlardan yararlanabilirsiniz: MXToolbox (mxtoolbox.com) SPF, DKIM ve DMARC kayıtlarınızı analiz eder; Google Admin Toolbox (toolbox.googleapps.com) DKIM imzasının doğruluğunu test eder; mail-tester.com ise bir bütün olarak "gönderim skoru" hesaplar. Microsoft'un uzak IP'leri kara listeden çıkarmak için Sender Support portalı (sendersupport.olc.protection.outlook.com) kullanılabilir; bu portal üzerinden delist talebi açılabilir.
SPF tek başına yeterli değildir. Google ve Microsoft, DMARC hizalaması (alignment) da arar; yani "From" başlığındaki alan adının SPF veya DKIM ile hizalı olması gerekir. Yalnızca SPF'nin geçmesi, DMARC politikası p=reject veya p=quarantine olarak ayarlanmışsa reddi önleyemez. DKIM imzasını da ekleyip DMARC politikanızı kontrol edin.
Google'ın Şubat 2024 güncellemesine göre bulk gönderenler için en azından p=none bulunması zorunludur; ancak bu politika yalnızca raporlama sağlar, koruma sağlamaz. Uzun vadede p=quarantine veya p=reject'e geçmek, alan adı sahteciliğine karşı gerçek bir koruma sunar ve itibarınızı olumlu etkiler.
Bu hata genellikle IP adresinizin Microsoft'un kara listesinde olduğunu gösterir. Microsoft'un Sender Support portalından (sendersupport.olc.protection.outlook.com) delist talebinde bulunabilirsiniz. Talep öncesinde SPF, DKIM ve PTR kayıtlarınızın doğru yapılandırıldığından emin olun; aksi hâlde talep reddedilir.
"From" başlığındaki alan adı ile SPF ya da DKIM tarafından doğrulanan alan adının örtüşmediğini ifade eder; DMARC terminolojisinde buna "alignment failure" denir. Çözüm: "From" adresinizin alan adını DKIM imzanızın d= değeriyle veya SPF geçiş alan adınızla eşleştirin.
Teknik kimlik doğrulama geçse de içerik filtreleri, alıcı şikâyetleri veya düşük gönderim itibarı spam sınıflandırmasına yol açabilir. Google Postmaster Tools üzerinde alan adı ve IP itibarınızı inceleyin. Şikâyet oranı yüksekse listenizi temizleyin; abonelikten çıkma bağlantısının çalıştığından emin olun.
Günde 50.000'in üzerinde mesaj gönderiyorsanız özel IP tercih edilmelidir; bu sayede başka gönderenlerin olumsuz davranışlarından etkilenmezsiniz. Daha düşük hacimler için iyi itibar geçmişine sahip bir ESP'nin (E-posta Servis Sağlayıcısı) paylaşımlı havuzu yeterli olabilir.
PTR (reverse DNS) kaydı, IP adresini size tahsis eden ISP veya veri merkezi tarafından oluşturulur. Hosting ya da sunucu sağlayıcınıza başvurarak IP'niz için bir PTR kaydı talep etmeniz gerekir. Kayıt, alan adınızla tutarlı olmalı ve bir dig -x [IP] sorgusuyla doğrulanabilir düzeyde çalışır hâlde olmalıdır.
Standart bir ısınma planında 4–6 hafta öngörülür. İlk hafta günde birkaç yüz mesajla başlanır ve her hafta hacim iki katına çıkarılır. Google Postmaster Tools ve Microsoft SNDS üzerinde itibar skorunu haftalık olarak izlemek, ısınmanın seyri hakkında güvenilir geri bildirim sağlar.
Evet. Google, gelen bağlantılarda TLS şifrelemesini tercih eder ve şifrelenmemiş bağlantıları 421 4.7.0 hata kodu ile geri çevirebilir. RFC 3207 (SMTP üzerinde TLS için STARTTLS uzantısı) bu konudaki teknik standardı tanımlar. Posta sunucunuzun STARTTLS veya port 465 üzerinden SSL/TLS desteklediğinden emin olun.
Connect365, müşteri alan adları için SPF, DKIM ve DMARC kayıtlarını kurulum aşamasında yapılandırır; özel IP seçeneği sunar ve Google Postmaster Tools entegrasyonuyla itibar skorunu sürekli izler. Yüksek hacimli gönderimlerde kademeli ısınma planı uygulanır, liste hijyeni otomatik bounce yönetimiyle korunur.
Reklamsız, KVKK uyumlu; kurulum ve geçiş ücretsiz, mailleri biz taşırız.
Kurulum + migrasyon ücretsiz. KVKK uyumlu, Türkiye'de barındırma. 7/24 Türkçe destek.
Kampanya 30 Haziran'a kadar geçerlidir.