E-posta kimlik doğrulama, gönderen alan adı ve mesajın imzalanan içeriği hakkında kontrol sağlayan SPF, DKIM ve DMARC mekanizmalarını kapsar. Spam klasörüne düşmenin tek nedeni kimlik doğrulama değildir; IP/alan adı itibarı, şikâyetler, içerik ve gönderim altyapısı da incelenmelidir. Bu rehber DNS kayıtlarının kurulumu ve kontrolüne odaklanır.
E-posta Kimlik Doğrulama Nedir, Neden Gerekli?
Klasik SMTP protokolü, bir e-postanın “kimden” alanına istediğiniz adresi yazabilmenize izin verecek kadar eskidir; bu da spam gönderenlerin başkalarının alan adını taklit etmesini (spoofing) çok uzun süre kolaylaştırdı. E-posta kimlik doğrulama, alıcı sunucuya “bu e-posta gerçekten bu alan adının yetkili sunucusundan gönderildi” bilgisini kriptografik ve DNS tabanlı yöntemlerle kanıtlayarak bu boşluğu kapatıyor. Sistem üç ayrı standardın bir araya gelmesiyle çalışıyor: SPF gönderen sunucunun IP’sini doğrular, DKIM mesaj içeriğinin değişmediğini imzayla kanıtlar, DMARC ise bu ikisinin sonucuna göre alıcı sunucunun ne yapması gerektiğini (kabul et, karantinaya al, reddet) belirtir.
SPF, DKIM ve DMARC Arasındaki Fark Ne?
SPF (Sender Policy Framework) Nedir?
SPF, alan adınız adına e-posta göndermeye yetkili sunucuların IP adreslerini listeleyen bir DNS TXT kaydıdır. Alıcı sunucu bir e-posta aldığında, gönderen IP’nin bu listede olup olmadığını kontrol eder. Listede yoksa e-posta şüpheli olarak işaretlenebilir veya doğrudan reddedilebilir.
DKIM (DomainKeys Identified Mail) Nedir?
DKIM, gönderilen her e-postaya sunucunuzun özel anahtarıyla oluşturulmuş dijital bir imza ekler. Alıcı sunucu, DNS üzerinde yayınlanan genel anahtarla bu imzayı doğrular; imza geçerliyse mesajın yolda değiştirilmediği kriptografik olarak kanıtlanmış olur.
DMARC (Domain-based Message Authentication) Nedir?
DMARC, görünen From alan adıyla hizalı en az bir başarılı SPF veya DKIM sonucu arar. İkisinin birden başarılı olması DMARC için zorunlu değildir. Hiçbir hizalı doğrulama geçmezse yayınlanan politika alıcının kararına girdi sağlar; alıcı kendi politikasıyla farklı işlem uygulayabilir.
| Standart | Ne Yapar | Kayıt Türü | Tek Başına Yeterli mi? |
|---|---|---|---|
| SPF | Gönderen sunucu IP’sini doğrular | DNS TXT | Hayır, yönlendirmede kolayca bozulur |
| DKIM | Mesaj bütünlüğünü imzayla kanıtlar | DNS TXT (CNAME/anahtar çifti) | Hayır, alan adı hizalamasını garanti etmez |
| DMARC | SPF/DKIM sonucuna göre politika belirler | DNS TXT | Sadece SPF/DKIM ile birlikte anlamlı |
Alan Adı Hizalaması (Alignment) Nasıl Çalışır?
SPF ve DKIM’in kendisi geçse bile, DMARC’ın bunu “geçerli” sayması için ek bir koşul var: hizalama (alignment). Hizalama, e-postanın “Kimden” (From) alanındaki görünen alan adı ile SPF veya DKIM kontrolünde doğrulanan alan adının eşleşmesi anlamına gelir. Örneğin bir e-posta siparis@magazaniz.com adresinden gönderilmiş görünüyor ama SPF kontrolü sendgrid.net alanını doğruluyorsa, bu iki alan adı birbiriyle hizalı değildir ve DMARC bu e-postayı başarısız sayabilir.
Bu sorunu çözmek için e-posta gönderim servisinizde “özel alan adı gönderimi” (custom domain sending) veya “marka gönderimi” özelliğini etkinleştirmeniz gerekir; bu özellik, servis sağlayıcının kendi alt alan adınız üzerinden (örneğin mail.magazaniz.com) DKIM imzası atmasını sağlar ve böylece görünen alan adıyla imzalayan alan adı eşleşir. DMARC’ta iki hizalama modu bulunur: strict (tam eşleşme ister) ve relaxed (alt alan adı farkına izin verir, varsayılan ve pratikte önerilen mod).
Popüler Hosting ve DNS Sağlayıcılarında Kayıt Ekleme İpuçları
DNS kaydı ekleme adımları sağlayıcıdan sağlayıcıya küçük farklılıklar gösterir; en yaygın üç senaryoyu özetleyelim:
cPanel Tabanlı Paylaşımlı Hosting
cPanel kullanan hosting hesaplarında “Zone Editor” veya “DNS Yönetimi” bölümünden yeni bir TXT kaydı ekleyebilirsiniz. Bazı cPanel sürümleri, e-posta hesabı oluşturduğunuzda SPF ve DKIM kayıtlarını otomatik önerir; bu öneriyi kabul etmeden önce mevcut bir SPF kaydınız varsa çakışma olmaması için mutlaka birleştirin, ayrı bir kayıt olarak eklemeyin.
Cloudflare DNS Kullanıyorsanız
Cloudflare’de TXT kayıtları proxy edilemez; bu kayıtlar için gri/turuncu bulut seçimi yoktur. DKIM CNAME kaydında ise sağlayıcının DNS only talimatını izleyin. Uzun TXT değeri tek kayıt içinde birden fazla tırnaklı karakter dizisine bölünebilir; bu geçerli bir gösterimdir.
Google Workspace veya Microsoft 365
Bu servislerin yönetici panelinde genellikle “Kimlik doğrulama” veya “DKIM’i etkinleştir” gibi bir bölüm bulunur; buradan alacağınız CNAME veya TXT değerini kendi DNS sağlayıcınıza eklersiniz. Servis tarafında “etkinleştir” düğmesine basmadan önce DNS kaydının yayıldığından emin olun, aksi halde etkinleştirme işlemi başarısız olabilir.
BIMI: Gelecek Adım Olarak Marka Logosu Gösterimi
DMARC kaydınızı quarantine veya reject seviyesine taşıdıktan sonra değerlendirebileceğiniz bir sonraki adım BIMI (Brand Indicators for Message Identification) standardıdır. BIMI, DMARC uygulaması güçlü olan alan adlarının, Gmail ve Yahoo gibi bazı e-posta istemcilerinde gönderen logosunun gelen kutusunda görünmesini sağlar. Bu, doğrudan bir güvenlik özelliği olmasa da güçlü bir DMARC kurulumunun “ödülü” gibi düşünülebilir ve marka güvenilirliğini görsel olarak artırır. BIMI kurulumu, ayrı bir DNS TXT kaydı ve genellikle bir Doğrulanmış Marka İşareti (VMC) sertifikası gerektirdiğinden, bu rehberin kapsamı dışında ayrı bir konu olarak ele alınmalı.
2026’da Neden Artık Zorunlu? Google ve Yahoo Kuralları
Gmail’in kuralları 1 Şubat 2024’te başladı. Kişisel Gmail adreslerine gönderimde tüm gönderenler için SPF veya DKIM; toplu gönderenler için SPF, DKIM ve en az p=none DMARC gerekir. 5.000 günlük mesaj eşiği alıcı kapsamıyla değerlendirilir, tek bir kullanıcı hesabı eşiği değildir. Doğrudan gönderimde en az bir hizalı doğrulama geçmelidir. Pazarlama/abonelik mesajlarında tek tıkla çıkış, geçerli DNS/PTR ve TLS de kuralların parçasıdır. Yahoo’nun koşulları ayrıca kendi kılavuzundan kontrol edilmelidir. Gmail gönderici kuralları
Bu değişim, küçük bir WordPress sitesinden bile günde birkaç yüz sipariş onayı e-postası gönderiliyorsa artık göz ardı edilemeyecek bir konu haline geldi; çünkü eşik, “büyük şirket” olmayı değil, “günlük 5.000 e-posta” hacmini baz alıyor. Özellikle paylaşımlı hosting üzerinden e-posta gönderen siteler için bu kayıtları doğru kurmak daha da kritik; farklı hosting türleri arasında SMTP ve DNS yönetim panellerinin arayüzü değişebiliyor, bu yüzden kendi sağlayıcınızın DNS kayıt ekleme adımlarını önceden kontrol etmenizi öneririz.
SPF Kaydı Nasıl Oluşturulur? Adım Adım
- Alan adınızı e-posta gönderen tüm servisleri listeleyin: Hosting sunucunuz, WordPress SMTP eklentiniz (örneğin SendGrid, Mailgun, Amazon SES) ve varsa Google Workspace gibi servisleri not edin.
- Hosting kontrol panelinizde veya DNS sağlayıcınızda yeni bir TXT kaydı oluşturun.
- Aşağıdaki formatta bir SPF kaydı yazın (örnek, Google Workspace ve SendGrid kullanan bir alan adı için):
Tip: TXT
Ad: @
Değer: v=spf1 include:_spf.google.com include:sendgrid.net ~allBuradaki ~all ifadesi “soft fail” anlamına gelir; listede olmayan sunuculardan gelen e-postalar tamamen reddedilmez ama şüpheli işaretlenir. Daha katı bir kural için -all (“hard fail”) kullanılabilir; ancak bunu yapmadan önce e-posta gönderen tüm servislerin listede olduğundan kesinlikle emin olun, aksi halde kendi meşru e-postalarınız da reddedilebilir.
DKIM Nasıl Kurulur?
DKIM kurulumu, kullandığınız e-posta gönderim servisine göre değişir. WordPress üzerinde WP Mail SMTP veya benzeri bir eklenti kullanıyorsanız, genellikle eklenti size bir CNAME veya TXT kaydı verir ve siz bunu DNS’e eklersiniz. Örneğin bir DKIM CNAME kaydı şu şekilde görünebilir:
Tip: CNAME
Ad: s1._domainkey
Değer: s1.domainkey.u12345.wl123.sendgrid.netHosting tarafında kendi mail sunucunuzu (örneğin Postfix + OpenDKIM) çalıştırıyorsanız, DKIM anahtar çiftini sunucuda üretip genel anahtarı DNS’e TXT kaydı olarak eklemeniz gerekir:
# OpenDKIM ile anahtar çifti üretme
opendkim-genkey -s mail -d siteniz.com
# Oluşan mail.txt dosyasının içeriği DNS'e TXT kaydı olarak eklenirKaydı ekledikten sonra doğrulamayı mutlaka bir test aracıyla (örneğin mail-tester.com) yapın; DKIM imzasının “pass” durumunda görünmesi gerekir.
DMARC Kaydı Nasıl Yazılır? Politika Seviyeleri
DMARC kaydı da bir DNS TXT kaydıdır ve _dmarc alt alan adına eklenir. Örnek bir başlangıç kaydı:
Tip: TXT
Ad: _dmarc
Değer: v=DMARC1; p=none; rua=mailto:dmarc-raporlari@siteniz.com; pct=100Politika seviyeleri, sıkılık derecesine göre üç kademeye ayrılır:
| Politika | Anlamı | Ne Zaman Kullanılır |
|---|---|---|
| p=none | DMARC kaynaklı yaptırım talep edilmez; alıcının spam kontrolleri sürer | İlk kurulum ve izleme aşaması |
| p=quarantine | Başarısız e-postalar spam klasörüne yönlendirilir | Raporlar temiz göründükten sonra |
| p=reject | Başarısız e-postalar tamamen reddedilir | Tüm gönderim kaynakları doğrulandıktan sonra |
Doğrudan p=reject ile başlamak, henüz listelemediğiniz meşru bir gönderim servisi varsa müşterilerinize giden faturaların veya sipariş bildirimlerinin kaybolmasına neden olabilir. Bu yüzden p=none ile başlayıp, birkaç hafta rapor toplayıp tüm meşru kaynakları doğruladıktan sonra kademeli olarak quarantine ve ardından reject‘e geçmek en güvenli yoldur.
Kurulum Sonrası İzleme: Raporları Nasıl Okumalısınız?
DMARC kaydınızdaki rua=mailto:... etiketi sayesinde, alıcı sunucular (Google, Yahoo, Microsoft dahil) size düzenli aralıklarla toplu XML raporları gönderir. Bu raporlar, alan adınız adına gönderilen tüm e-postaların hangi IP’den geldiğini, SPF/DKIM sonucunu ve hizalama durumunu özetler. Ham XML dosyalarını elle okumak pratik olmadığından, ücretsiz veya düşük maliyetli bir DMARC rapor ayrıştırıcı panel kullanmanızı öneririz; bu panellerin çoğu raporları otomatik olarak toplayıp size görsel bir özet (hangi kaynaklar geçti, hangileri başarısız oldu) sunar.
İlk birkaç hafta boyunca bu raporları düzenli incelemek, hiç haberdar olmadığınız ama sizin adınıza e-posta gönderen meşru bir servisin (örneğin muhasebe yazılımınızın fatura gönderim modülü) ortaya çıkmasını sağlayabilir. Bu tür “unutulmuş” gönderim kaynaklarını SPF kaydınıza eklemeden p=reject‘e geçerseniz, o servisin gönderdiği tüm e-postalar sessizce kaybolur; bu yüzden politika sıkılaştırmadan önce en az 2-3 haftalık temiz rapor geçmişi görmenizi öneririz.
Ayrıca Google Postmaster Tools’u alan adınız için ücretsiz olarak kaydettirmek, spam şikâyet oranınızı, itibar puanınızı ve teslim edilebilirlik istatistiklerinizi doğrudan Gmail’in gözünden takip etmenizi sağlar; bu araç, yukarıda bahsedilen %0,10 ve %0,3 şikâyet oranı eşiklerini kendi hesabınız için izlemenin en doğrudan yolu.
Sık Yapılan Hatalar ve Çözümleri
1. Birden Fazla SPF Kaydı Oluşturmak
Bir alan adı için yalnızca tek bir SPF TXT kaydı olabilir. Yeni bir servis eklerken ayrı bir SPF kaydı oluşturmak yerine, mevcut kaydı düzenleyip include: ifadesini eklemeniz gerekir; birden fazla SPF kaydı, doğrulamanın tamamen başarısız olmasına yol açar.
2. SPF’de 10 DNS Sorgusu Limitini Aşmak
SPF standardı, bir kayıttaki include: zincirlerinin toplamda 10 DNS aramasını aşmamasını şart koşar. Çok fazla servis eklediğinizde bu limit aşılabilir ve SPF kontrolü “permerror” ile başarısız olur; gereksiz include’ları temizleyin veya SPF düzleştirme (flattening) araçları kullanın.
3. DKIM Anahtarını DNS’e Doğru Eklememek
DKIM TXT değerinin tek DNS kaydı içinde birden çok tırnaklı parçaya ayrılması normaldir; parçalar birleştirilerek okunur. Değerin eksilmesi veya ayrı çakışan kayıtlar ise doğrulamayı bozabilir. Sağlayıcıdaki değerle DNS cevabını karşılaştırın.
4. DMARC’ı Hiç Kurmadan Sadece SPF/DKIM’e Güvenmek
SPF ve DKIM tek başına alan adı hizalamasını garanti etmez; bir saldırgan farklı bir alan adından SPF/DKIM’i geçen bir e-posta gönderebilir. DMARC bu hizalamayı kontrol eder; zorunluluk, alıcının toplu gönderim kurallarına göre değişir.
5. Rapor E-postalarını Hiç İncelememek
DMARC’ın rua etiketiyle gönderdiği günlük raporları hiç açmamak, kurulumun gerçekte işe yarayıp yaramadığını bilmemeniz anlamına gelir. Bu raporları okumak için ücretsiz bir DMARC rapor ayrıştırıcı (parser) aracı kullanmanızı öneririz; ham XML dosyalarını elle okumak pratik değildir.
6. Alt Alan Adlarını (Subdomain) Unutmak
Alt alan adı kendi DMARC kaydı yoksa organizasyon alanının politikasından etkilenebilir. SPF kaydı ise alt alan adına otomatik miras kalmaz; SPF’nin kontrol ettiği zarf gönderen alanı için ayrıca tanımlanmalıdır. Hizalı DKIM de DMARC geçişini sağlayabilir.
Kime, Hangi Durumda Uygun?
E-posta kimlik doğrulama kurulumu; WooCommerce siparişi onayı gönderen bir e-ticaret sitesinden, aylık bültenini kendi alan adından gönderen bir blogdan, kurumsal SaaS ürününden fatura gönderen bir yazılım şirketine kadar kendi alan adından herhangi bir hacimde e-posta gönderen her site için artık temel bir gereklilik. Günlük gönderim hacminiz binlerin altında olsa bile, SPF ve DKIM kurmak size neredeyse hiçbir maliyet getirmez ve e-postalarınızın spam klasörüne düşme riskini önemli ölçüde azaltır. DMARC’ı p=reject seviyesine kadar götürmek ise daha fazla dikkat ve izleme gerektirir; bu adımı yalnızca tüm meşru gönderim kaynaklarınızı doğruladıktan sonra atmanızı öneririz.
Öte yandan sadece kişisel, düşük hacimli bir e-posta hesabı kullanıyorsanız (örneğin ayda birkaç kez arkadaşlarınıza e-posta gönderdiğiniz bir Gmail hesabı gibi) bu rehberdeki adımların çoğu sizi doğrudan ilgilendirmez; Google ve Yahoo’nun 2026 kuralları özellikle kendi alan adından toplu veya otomatik e-posta gönderen işletmeleri ve web sitelerini hedefliyor. Yine de kendi alan adınızdan (örneğin isim@sirketiniz.com) tek bir e-posta bile gönderiyorsanız, temel bir SPF ve DKIM kurulumu yapmanız, o e-postanın spam klasörüne düşme riskini önemli ölçüde azaltır.
Sık Sorulan Sorular
SPF, DKIM ve DMARC kurmak ücretsiz mi?
Evet, üçü de DNS TXT kaydı olarak eklenir ve DNS sağlayıcınız veya hosting panelinizde ek bir ücret ödemeden oluşturulabilir; maliyet yalnızca DKIM anahtarı üreten bir e-posta servisi kullanıyorsanız o servisin kendi ücretinden kaynaklanabilir.
Sadece SPF kurmak yeterli mi?
Hayır, SPF tek başına yönlendirme (forwarding) senaryolarında kolayca bozulabilir ve alan adı hizalamasını garanti etmez; DKIM ve DMARC ile birlikte kullanılması gerekir.
DMARC kaydını p=reject yaparsam ne olur?
p=reject, hizalı SPF veya DKIM doğrulamasından hiçbirini geçemeyen mesajların reddedilmesini talep eder. Tek bir hizalı başarılı doğrulama DMARC geçişi için yeterlidir. Alıcı yerel politikasını da uygulayabilir.
Değişikliklerin etkili olması ne kadar sürer?
DNS kayıtları genellikle dakikalar içinde yayılır, ancak bazı DNS sağlayıcılarında ve önbelleklerde bu süre 24-48 saate kadar uzayabilir; bu yüzden büyük politika değişikliklerini (örneğin reject’e geçişi) sakin bir dönemde yapmanızı öneririz.
Kurulumu nasıl test edebilirim?
mail-tester.com veya benzeri ücretsiz araçlara test e-postası göndererek SPF, DKIM ve DMARC durumunuzu ve genel spam puanınızı anında görebilirsiniz.
Google Workspace veya Microsoft 365 kullanıyorsam SPF/DKIM’i onlar mı kuruyor?
Bu servisler size gerekli DKIM anahtarını ve SPF include ifadesini sağlar, ancak kaydı kendiniz alan adınızın DNS yönetim panelinden eklemeniz gerekir; otomatik kurulum yapılmaz.
WordPress’te varsayılan mail gönderimi neden spam’e düşüyor?
WordPress’in varsayılan PHP mail() fonksiyonu genellikle sunucunun paylaşımlı IP’sinden gönderim yapar ve bu IP’nin SPF kaydınızda listeli olmama ihtimali yüksektir; bu yüzden WP Mail SMTP gibi bir eklentiyle özel bir SMTP servisi üzerinden gönderim yapmak ve o servisi SPF/DKIM kayıtlarınıza eklemek, teslim edilebilirliği belirgin şekilde artırır.
Standart kaynakları
