Ing. Calogero Bono
Outlook.com, Microsoft'un bireysel e-posta hizmeti, günde 5.000'den fazla e-posta gönderen alan adlarından SPF, DKIM ve DMARC ister. Bağımsız bir kaynak olan MailRoute, DMARC kaydı olmayan alan adlarında küçük gönderenlerin de artık reddedildiğini bildiriyor. Microsoft'tan bir doğrulama yok. hotmail veya outlook adresli müşterilere yazıyorsan, bazı mesajların farkına varmadan ulaşmaması riski var.
Aslında önce birkaç terim. SPF, alanın adına e-posta gönderme yetkisi olan sunucuları listeleyen bir DNS kaydıdır. DKIM, mesajın değiştirilmediğini garanti eden dijital bir imzadır. DMARC, SPF ve DKIM'i From alanında görünen adresle ilişkilendirir ve kontroller başarısız olursa alıcılara ne yapacağını söyler. Hizalama, From alanıyla SPF veya DKIM'in denetlediği alanın aynı olması demektir. DNS, alan adına eşlik eden kayıtlar listesidir.
Microsoft büyük gönderenler için ne duyurdu?
Microsoft, resmi blogunda günde 5.000 mesajdan fazla gönderen alan adları için SPF ve DKIM'in başarılı olmasını, en az p=none ayarında ve SPF veya DKIM ile hizalı bir DMARC'ı, tercihen ikisini birden, gerekli gördüğünü açıklıyor. Kural Outlook.com için geçerli; yani hotmail.com, live.com ve outlook.com adresleri.
5 May 2025'ten sonra uyumsuz mesajların Junk klasörüne düşmesi gerekiyordu. Ancak 29 Nisan tarihli bir güncelleme değişikliği açıklıyor; Microsoft bunların «b550; 5.7.515 Access denied» hatasıyla reddedilmesine karar verdiğini belirtiyor.
MailRoute ne bildiriyor?
MailRoute'a göre 5 Kasım 2026'dan itibaren Outlook.com, DMARC kaydı olmayan alan adlarının bir kısmını reddediyor. Hata mesajı «550 5.7.1 Message rejected» ve kimlik doğrulama kayıtlarının eksik olduğu belirtiliyor.
Sağlayıcı, bunu 5 Kasım'da kendi kayıtlarında gördüğünü ve o gün başka yöneticilerin de benzer bildirimlerde bulunduğunu söylüyor. MailRoute'a göre etkilenenler küçük gönderenler de; birçok alan adında SPF zaten çalışıyordu, bazılarında DKIM de vardı.
Sorun neden fark edilmesi zor?
MailRoute, reddin yalnızca kısmi olduğunu anlatıyor. Hotmail adresine giden bir mesaj geçiyor, sonrakisi geri dönüyor, yeni bir gönderim başarılı olabiliyor. Yazımı yapan kişi, kod dolu bir hataya bakar ve geçici bir arıza sanar.
Alıcı ise hiçbir şey bilmez. Faturalar, randevu onayları, müşteri yanıtları bu yüzden kaybolabilir. Bu, yalnızca işletmelere değil bireylere de yazanlar için tipik, sessiz bir zarar. Üç kaydın birlikte nasıl çalıştığını SPF, DKIM, DMARC ve gönderen itibarı rehberimizde anlatıyoruz.
Alan adı nasıl kontrol edilip düzeltilir?
MailRoute, alan adını değiştirerek dig +short TXT _dmarc.example.com komutuyla kontrol etmeni öneriyor. v=DMARC1 ile başlayan bir satır çıkmazsa kayt eksiktir.
Önerilen düzeltme, _dmarc adında ve v=DMARC1; p=none değerinde bir TXT kaydı. Bu politika alıcılardan başarısızlıkları işlemelerini istemez, dolayısıyla posta işlemesini başka yerlerde değiştirmez. Bir koşulu var – DMARC yalnızca SPF veya DKIM, From alanındaki alan adıyla hizalıysa geçer. Microsoft 365 kullanıyorsan, MailRoute, kendi alan adın için DKIM'i etkinleştirene kadar onmicrosoft.com imzasının sayılmayacağını uyarıyor.
Posta alanınız hosting üzerinden yönetiliyorsa, DNS'i kimin yönettiğini kontrol et; bunu alan adı, hosting ve posta yazımızda anlatıyoruz.
Bilmen gereken sınırlar
E-posta reddi haberi yalnızca tek bir e-posta sağlayıcısından geliyor ve bu sağlayıcının ticari bir ilgisi de var. MailRoute'a göre Microsoft 6 Kasım itibarıyla hiçbir şey yayımlamamış. Kaç alanın etkilendiğini, önlemin kalıcı mi yoksa deneme mi olduğunu ve reddedilen mesajların başka etkenlere bağlı olup olmadığını bilmiyoruz. Kesin reddin resmi kaynağındaki tarih de henüz açıklanmadı.
Dijitalle çalışanlar için ne değişiyor
İlk adım, gönderdiğin her alan adını kontrol etmek; müşterilerin alan adları dahil. p=none ayarındaki bir DMARC birkaç dakika sürer. Ardından SPF veya DKIM'in hizalı olduğunu doğrula, özellikle bülten, yönetim yazılımı ve site formları gibi dış araçlarla gönderim yapıyorsan. Microsoft, gönderimi üçüncü taraflara bırakılsa bile kaydın kendi alan adında olması gerektiğini ve Güvenli Gönderenler listesinin dikkate alınmayacağını hatırlatıyor. Terk edilmiş sepet otomasyonu gibi e-posta pazarlaması yapanlar ise geri dönen mesajlara dikkat etmeli.
Bizim değerlendirmemiz
Tablo tutarlı. Kurallar büyük gönderenler için konulmuş, sonra herkes için temel haline geliyor; ana sağlayıcıların yönelimi de bu. Zayıf nokta iletişim. Kısmi bir red duyurulmazsa ve hata mesajı neyin eksik olduğunu söylemezse, bedelini teknik personeli olmayan küçük işletmeler öder. Sinyal doğrulanmalı, ama p=none kaydının maliyeti o kadar düşük ki onay beklemenin anlamı yok. Yayımlanmış bir DMARC, senin yerine geçenlere karşı da yardımcı olur; bu konuyu e-posta yoluyla oltalama ve dolandrıcılıklar yazımızda işliyoruz.
Sık sorulan sorular
Günde 5.000'den az e-posta gönderiyorsam yine de bir şey yapmam gerekir mi?
Evet, yapmanı öneririm. Resmi kurallar büyük gönderenlerle başlar, ama Microsoft bu uygulamalardan herkesin yararlanacağını yazıyor. MailRoute ise küçük gönderenlerde de reddedildiğini bildiriyor.
En az DMARC kaydı nedir?
_dmarc adında ve v=DMARC1; p=none değerine sahip bir TXT kaydı. MailRoute'a göre bu, diğer alıcıların postaını nasıl işlediğini değiştirmez. Yalnızca SPF veya DKIM hizalıysa işe yarar.
Reddi nasıl anlarım?
Gönderene geri dönen hata mesajından. Microsoft büyük gönderenler için 550 5.7.515 kodunu belirtiyor, MailRoute ise eksik kimlik doğrulama kayıtları cümlesiyle birlikte 550 5.7.1 kodunu bildiriyor.
Güvenli Gönderenler listesi sorunu çözüyor mu?
Hayır. Microsoft, Safe Sender listesinin yeni uygulama kurallarında dikkate alınmayacağını belirtiyor.
Gönderim için dış bir hizmet kullanırsam yine de DNS gerekir mi?
Evet. Microsoft, gönderimi üçüncü taraflara bırakılsa bile kimlik doğrulamanın senin alan adına bağlı olduğunu netleştiriyor. Doğru DNS ayarları için sağlayıcıyla koordinasyon yapman gerekir.
Outlook'un reddetme sürecinde önümüzdeki aylarda izlenecekler
İki bilinmeyen var – Microsoft eşik altı kuralı onaylayacak mı ve kesin reddin ne zaman başlayacağı.
- Gönderim kayıtlarını kontrol et ve hotmail, live ve outlook adreslerine giden geri dönemeleri say.
- Yeni aşamaların tarihlerinin yayımlanacağı Microsoft topluluk blogunu takip et.
- Gönderenlerin hizalı olduğunda, Microsoft'un önerdiği şekilde none'dan quarantine'e, sonra reject'e geçişi kademeli olarak değerlendir.
