SPF, DKIM, DMARC: Gmail, Yahoo ve Microsoft Kuralları Mailinizi Nasıl Etkiler?

Teklif maili müşterinin gelen kutusuna değil de spam klasörüne düşüyorsa ya da hiç ulaşmıyorsa, sebep çoğu zaman cümlelerinizde değil alan adınızın kimlik doğrulamasındadır. Google ve Yahoo 2024 başında, Microsoft ise 2025 ortasında kendi tüketici posta servislerinde toplu göndericiler için SPF, DKIM ve DMARC şartı getirdi. Bu kurallar yalnızca büyük markaları ilgilendirmiyor; küçük bir işletmenin de uyması gereken bir taban var ve alan adınızın DNS ayarlarına yıllardır bakılmamış olabilir.

SPF, DKIM, DMARC: üç kayıt, tek soru

Alıcı sunucu her gelen iletide aynı soruyu sorar: Bu posta gerçekten bu alan adının sahibinden mi geliyor? Üç DNS kaydı bu soruya farklı açılardan cevap verir.

• SPF: Alan adınızın DNS kaydında, hangi sunucuların sizin adınıza posta gönderebileceğini listeler. Alıcı, iletiyi teslim eden sunucunun bu listede olup olmadığına bakar.
• DKIM: Gönderen sunucu iletiyi gizli bir anahtarla imzalar, alıcı da DNS’teki açık anahtarla imzayı doğrular. İmza, iletinin yolda değişmediğini de gösterir.
• DMARC: SPF ya da DKIM sonucunun, kullanıcının ekranda gördüğü Kimden (From) alan adıyla uyumlu olup olmadığına bakar ve doğrulamayı geçemeyen iletilere ne yapılacağını alıcıya bildirir.

Asıl ayrıntı şurada: DMARC standardına (RFC 7489) göre, DMARC’ı geçmek için SPF ya da DKIM’den en az birinin hem başarılı olması hem de From alan adıyla hizalı çıkması gerekir. Yani SPF “geçti” dese bile, geçen alan adı sizin alan adınız değil de e-posta servisinin kendi alan adıysa DMARC yine başarısız sayılır.

Dikkat: Sık görülen tuzak, bir bülten aracı ya da web sitesi formu üzerinden sizin adresinizle posta göndermek, ama aracın iletiyi kendi alan adıyla imzalamasıdır. Tek tek kayıtlar çalışıyor görünür, hizalama tutmadığı için DMARC başarısız olur.

Üç büyük sağlayıcının kuralları

Google (Gmail)

Google’ın gönderici kuralları 1 Şubat 2024’te yürürlüğe girdi. Hacminiz ne olursa olsun SPF ya da DKIM gerekiyor; toplu gönderici sayılırsanız SPF, DKIM ve DMARC üçü birden isteniyor. Toplu gönderici, 24 saatte kişisel Gmail adreslerine yaklaşık 5.000 ya da daha fazla ileti gönderen taraf. Alt alan adlarından giden postalar da ana alan adının toplamına ekleniyor.

Az bilinen bir ayrıntı: Google’ın sık sorulan sorular sayfasına göre toplu gönderici statüsünün bir bitiş tarihi yok. Eşiği bir kez aştığınızda, sonradan gönderim hacmini düşürseniz de statü kalkmıyor. Tek seferlik büyük bir kampanya bile alan adınızı bu daha sıkı kurallara bağlayabilir; bu yüzden altyapıyı baştan düzgün kurmak sonradan yetişmeye çalışmaktan kolaydır.

Toplu göndericiler için Google’ın teknik şartları kısaca şunlar:

• SPF ya da DKIM’den en az biri From alan adıyla hizalı olmalı. Google ikisinin de hizalanmasını öneriyor ve bunun ileride zorunlu olabileceğini belirtiyor.
• DKIM anahtarı en az 1024 bit olmalı; sağlayıcınız destekliyorsa 2048 bit öneriliyor.
• Gönderen IP adresi için ters DNS (PTR) kaydı ve iletim sırasında TLS gerekiyor.
• Pazarlama ve abonelik iletilerinde tek tıkla abonelikten çıkma desteği gerekiyor: List-Unsubscribe ve List-Unsubscribe-Post başlıkları, bir HTTPS adresi ve gövdede görünür bir çıkış bağlantısı. Şifre sıfırlama gibi işlem iletileri bu kuralın dışında; mailin tanıtım mı işlem mi olduğuna alıcı karar veriyor.

Google’a göre spam şikâyeti oranı %0,30’un üzerine çıkan göndericiler, Google’ın hafifletme uygulamalarından yararlanamıyor. Uygulama tarafında ise Kasım 2025’ten itibaren Gmail’in uyumsuz trafikte denetimi artırdığı, bunun geçici ve kalıcı retleri de içerdiği belirtiliyor; uyumsuz iletiler ayrıca spam klasörüne düşebiliyor. Hata kodlarında 4.7.x geçici, 5.7.x kalıcı reddi gösteriyor. Örneğin SPF başarısızlığı için 4.7.27, DKIM başarısızlığı için 4.7.30 listelenmiş.

Yahoo

Yahoo’nun gönderici sayfası toplu gönderici için bir hacim eşiği vermiyor. Kurallar Şubat 2024’te başladı ve 2024’ün ilk yarısı boyunca kademeli olarak uygulandı. Toplu göndericiden SPF ve DKIM’in birlikte uygulanması, en az p=none bir DMARC politikası ve DMARC’ın geçmesi isteniyor. Rapor adresi (rua) güçlü biçimde öneriliyor ama zorunlu değil. Spam oranı %0,3’ün altında olmalı; Yahoo bunu gelen kutusuna teslim edilen posta üzerinden hesaplıyor.

Microsoft (Outlook.com, Hotmail, Live)

Microsoft’un destek sayfası yüksek hacimli göndericiyi, aynı From alan adıyla Microsoft’un tüketici posta servislerine 5.000 ya da daha fazla ileti gönderen taraf olarak tanımlıyor. Beklenti şu: SPF ve DKIM kayıtlarının yayımlanması ve geçmesi, en az p=none bir DMARC kaydı bulunması ve DMARC’ın, SPF ve/veya DKIM hizalamasıyla geçmesi. Tanım tüketici servislerine gönderimi esas alıyor. Duyuru 2 Nisan 2025’te yapıldı; Proofpoint’in aktardığına göre uygulama 5 Mayıs 2025’te başladı. Uyumsuz posta, 550 5.7.515 hata koduyla (gönderen alan adının gereken kimlik doğrulama seviyesine uymadığı bilgisiyle) geri dönüyor.

Not: Microsoft’un duyuru yazısı 29–30 Nisan 2025’te uygulanacak eylemle ilgili güncellendi. Üçüncü taraf kaynaklar ilk metinde uyumsuz postanın önce Gereksiz klasörüne yönlendirileceğini aktarıyor; destek sayfası ise doğrudan ret tarif ediyor. Güncel davranışı Microsoft’un resmî sayfalarından teyit edin.

Alan adınızın maili neden spam’e düşer?

Aşağıdakiler yapılandırmadan kaynaklanan sık senaryolar. İçerik ve itibar sorunları ayrı bir konu, ama önce kimliğin doğrulandığından emin olmak gerekir.

• Birden fazla aracın aynı alan adıyla posta göndermesi (ofis posta servisi, web sitesi formu, bülten aracı, CRM, e-ticaret platformu), ama SPF listesinde ya da DKIM imzasında yalnızca birinin tanımlı olması.
• SPF kaydının çok fazla “include” biriktirmesi. SPF standardı (RFC 7208), değerlendirme başına DNS sorgusu yapan terimlerin toplamını en fazla 10 ile sınırlıyor; aşılırsa sonuç permerror olur ve SPF geçmez.
• DKIM’in hiç açılmamış olması ya da aracın iletiyi kendi alan adıyla imzalaması; bu durumda DMARC hizalaması tutmaz.
• Toplu gönderici sayıldığınız halde DMARC kaydının bulunmaması. Bu, Google’ın tanımında doğrudan uyumsuzluk.
• Abonelikten çıkış bağlantısının saklanması. İnsanlar bağlantıyı bulamayınca Spam düğmesine basar ve spam şikâyeti oranınız yükselir.

Yönlendirilen iletiler (forward) ve e-posta listeleriyle ilgili bir istisna da var. Google’ın sık sorulan sorular sayfasına göre bu tür dolaylı iletilerde DMARC hizalaması şart koşulmuyor.

DMARC politikası neyi değiştirir: none, quarantine, reject

RFC 7489’a göre p etiketi, doğrulamayı geçemeyen iletiye alıcının ne yapmasını istediğinizi söyler:

• p=none: Alıcıdan özel bir işlem istenmez. Posta normal yoluna devam eder, siz yalnızca raporları alırsınız.
• p=quarantine: Başarısız ileti şüpheli kabul edilir. Pratikte spam klasörü ya da ek inceleme anlamına gelebilir.
• p=reject: Başarısız iletinin, mümkünse e-posta alışverişi sırasında reddedilmesi istenir.

Şaşırtıcı nokta şu: Google, Yahoo ve Microsoft toplu göndericiden yalnızca en az p=none istiyor. Yani en gevşek politika, gönderici kurallarını karşılamak için yeterli. Ama p=none, birinin alan adınızı taklit etmesini engellemez; yalnızca size rapor getirir. Sahte iletilerin spam klasörüne ya da reddedilmeye yönlendirilmesi için quarantine veya reject gerekir. Karşılığında riski de var: Yanlış yapılandırılmış meşru bir göndericiniz varsa onun postası da aynı akıbete uğrar. Bu yüzden önce rapor, sonra sıkılaştırma.

pct etiketi politikayı iletilerin yalnızca belirli bir yüzdesine uygular; kapsam dışında kalan başarısız iletiler bir alt politika gibi işlem görür (örneğin reject yerine quarantine). Google’ın Workspace rehberi de devreye almayı bu yöntemle önerir. Öte yandan 2026’da yayımlanan ve RFC 7489’un yerini alan RFC 9989 (Proposed Standard), pct etiketinin kaldırılmasına ilişkin bir ek bölüm içeriyor. Kayıt yazarken e-posta sağlayıcınızın güncel rehberine bakın.

İpucu: Logonuzun alıcının gelen kutusunda görünmesini sağlayan BIMI için Google, p değerinin quarantine ya da reject, pct değerinin 100 olmasını istiyor. Yani DMARC’ı none’da bırakmak bu seçeneği de kapatıyor.

Ne yapmalı? Adım adım

1. Gönderen envanterini çıkarın: ofis posta servisi, web sitesi formları, bülten ve SMS ya da e-posta araçları, CRM, e-ticaret ve muhasebe yazılımları, hosting’in kendi posta sunucusu.
2. SPF: Tüm meşru göndericileri tek bir SPF kaydında toplayın ve 10 sorgu sınırını aşmayın.
3. DKIM: Her gönderici için imzayı kendi alan adınızla açın. Sağlayıcı destekliyorsa 2048 bit anahtar seçin.
4. SPF ve DKIM’den sonra en az 48 saat bekleyin (Google’ın önerisi), ardından DMARC’ı p=none ve rua adresiyle yayımlayın. Raporlar için kişisel değil, ortak bir posta kutusu kullanın; Google rapor hacminin yüksek olabileceğini belirtiyor.
5. Raporları izleyin. Google’a göre bir hafta, günlük raporların tüm posta akışlarını temsil etmesi için genellikle yeterli. Tanımadığınız ya da hizalanmayan göndericileri düzeltin.
6. Sorun çıkmıyorsa quarantine ve düşük bir pct ile başlayın (Google örnekte pct=5 kullanıyor, küçük kuruluşlar için %10’u anıyor) ve kademeli artırın. reject isteğe bağlı, çünkü reddedilen ileti hiç teslim edilmez.
7. Pazarlama iletilerine tek tıkla abonelikten çıkma ekleyin ve talepleri 2 gün içinde işleyin. Türkiye’de ticari elektronik iletiler için ayrıca 6563 sayılı Kanun ve ilgili yönetmelik ile İleti Yönetim Sistemi geçerli; gönderici kuralları bunların yerini tutmaz. Ayrıntı için hukuk danışmanınıza başvurun.
8. Google Postmaster Tools’ta spam oranını izleyin ve Gmail’deki iletinin ham başlığında SPF, DKIM ve DMARC sonuçlarını düzenli kontrol edin.

Kaynaklar

Aşağıdaki bağlantılar yazıdaki rakam ve iddiaların dayandığı kaynaklardır; yazı 28 Ekim 2026 itibarıyla hazırlanmıştır. Resmî düzenlemeler ve platform politikaları değişebilir; karar vermeden önce güncel hâlini kaynağından kontrol edin.

1. Google: E-posta göndericisi yönergeleri (Email sender guidelines)
2. Google: E-posta göndericisi yönergeleri sık sorulan sorular
3. Google Blog: New Gmail protections for a safer, less spammy inbox (3 Ekim 2023)
4. Yahoo Sender Hub: Sender best practices
5. Microsoft Destek: Fix NDR error 550 5.7.515 in Outlook.com
6. Proofpoint: Microsoft’un yeni e-posta kimlik doğrulama gereksinimleri
7. Google Workspace: DMARC kurulumu
8. RFC 7208: Sender Policy Framework (SPF), bölüm 4.6.4
9. RFC 7489: DMARC
10. Google Workspace: Önerilen DMARC devreye alma planı
11. RFC 9989: DMARC (RFC 7489’un yerini alan standart)
12. T.C. Ticaret Bakanlığı: İleti Yönetim Sistemi (İYS)
13. Microsoft Community Hub: Outlook’un yüksek hacimli göndericiler için yeni gereksinimleri (2 Nisan 2025, 29–30 Nisan güncellemeleri)