SPF, DKIM ve DMARC Kurulum Rehberi

Alan Hattı editoryal ekibi · 19 Eylül 2026'da güncellendi

SPF, DKIM ve DMARC birbirinin alternatifi değil, aynı e-posta kimlik doğrulama zincirinin farklı parçalarıdır. SPF bir iletinin hangi sunucudan gönderilebileceğini, DKIM iletinin yetkili bir sistem tarafından kriptografik olarak imzalanıp imzalanmadığını kontrol etmeye yardımcı olur. DMARC ise görünen gönderen alan adıyla bu sonuçların uyumunu değerlendirir ve başarısız iletiler için izleme, karantina veya reddetme politikası bildirir.

Doğru yapılandırma alan adının taklit edilmesini zorlaştırır ve alıcı sistemlere güçlü sinyaller verir; buna karşın gelen kutusuna teslim garantisi sağlamaz. İçerik kalitesi, alıcı etkileşimi, IP ve alan adı itibarı, gönderim hacmi ve şikâyet oranı gibi başka etkenler de teslimatı belirler. Bu nedenle kayıtları kopyalayıp bırakmak yerine bütün gerçek gönderim kaynaklarını envanterleyerek ilerlemek gerekir.

Üç mekanizma birlikte nasıl çalışır?

Bir e-postada kullanıcının gördüğü From: adresi, SMTP zarfındaki dönüş yolu ve DKIM imzasındaki alan adı aynı olmak zorunda değildir. SPF genellikle zarf gönderen alanı ile gönderen IP'yi ilişkilendirir. DKIM, seçilen başlıkları ve gövdeyi özel anahtarla imzalar; alıcı, DNS'teki açık anahtarla imzayı doğrular. DMARC başarılı sayılmak için SPF veya DKIM'den en az birinin geçmesini ve geçen yöntemin alan adının görünür From: alanıyla “hizalı” olmasını bekler.

Önemli ayrım: “SPF geçti” ifadesi tek başına DMARC'ın geçeceği anlamına gelmez. SPF'nin doğruladığı alan adı, kullanıcıya görünen gönderen alanıyla hizalı değilse DMARC açısından kullanılamayabilir. Benzer şekilde DKIM imzası geçerli olsa da imzadaki d= alanı hizalı değilse sonuç yetersiz kalabilir.

Kurulumdan önce gönderici envanteri çıkarın

İlk adım DNS kaydı yazmak değil, alan adınız adına e-posta gönderen her sistemi bulmaktır. Personelin posta hizmeti dışında web sitesi iletişim formu, e-ticaret siparişleri, fatura yazılımı, destek masası, bülten sistemi, CRM, parola sıfırlama ve izleme alarmı gibi kaynaklar olabilir. Eski ama hâlâ çalışan bir uygulamayı unutmak, sıkı politikaya geçtiğinizde meşru iletilerin reddedilmesine yol açabilir.

Her hizmetin hangi From: alanını ve zarf gönderen alanını kullandığını kaydedin.
Gönderim IP'sini doğrudan SPF'ye eklemek yerine sağlayıcının güncel talimatını izleyin.
DKIM desteğini, selector adını ve anahtar döndürme yöntemini sağlayıcıdan öğrenin.
Artık kullanılmayan göndericileri hem uygulamadan hem DNS politikasından çıkarın.
Alt alan adlarını ayrı gönderim akışlarına ayırmanın raporlamayı kolaylaştırıp kolaylaştırmayacağını değerlendirin.

1. SPF kaydını hazırlama

SPF politikası alan adının TXT kaydında yayınlanır ve v=spf1 ile başlar. Yalnızca Google Workspace kullanan örnek bir alan için sağlayıcı belgesinde v=spf1 include:_spf.google.com ~all gösterilebilir. Bu örnek her kuruluş için doğru değildir: kendi posta sağlayıcınızın verdiği mekanizmaları eklemeli, gerçek göndericilerinizi temsil etmeyen parçaları kullanmamalısınız.

Aynı alan adı için iki ayrı v=spf1 kaydı yayınlamak yerine tüm yetkili kaynakları tek politikada birleştirin. include, a, mx, exists ve yönlendirme gibi mekanizmalar değerlendirme sırasında DNS sorgularına yol açabilir; SPF standardındaki sorgu sınırı aşılırsa kalıcı hata oluşabilir. Gereksiz sağlayıcıları silmek ve politikayı yalın tutmak bu nedenle önemlidir. ~all ile -all seçimi de gelişigüzel yapılmamalıdır: önce bütün kaynakları doğrulayın, sonra sağlayıcınızın önerdiği uygulama planına göre sıkılaştırın.

SPF teşhis adımları

Alan Hattı E-posta Güvenliği aracında alan adının SPF kaydını görüntüleyin.
DNS'te tek bir SPF politikası bulunduğunu ve sözdiziminin eksiksiz olduğunu kontrol edin.
Her gerçek gönderim hizmetinin politikada kapsandığını sağlayıcı belgeleriyle karşılaştırın.
Test iletisinin tam başlığında SPF'nin hangi alan adı ve IP için değerlendirildiğine bakın.
Yönlendirme ve posta listelerinin SPF sonucunu bozabileceğini; DKIM'in bu senaryolarda ayrı değer taşıdığını hesaba katın.

2. DKIM imzasını etkinleştirme

DKIM'de posta sistemi özel anahtarı saklar; açık anahtar DNS'te genellikle selector._domainkey.ornek.com adlı TXT kaydında yayınlanır. Selector, aynı alan için birden fazla anahtar kullanılmasını ve anahtarların sırayla yenilenmesini sağlar. Anahtar çiftini rastgele bir çevrim içi araçta üretmek yerine posta sağlayıcınızın yönetim panelini ve resmî kurulum adımlarını kullanın; özel anahtarı DNS'e veya herkese açık bir depoya koymayın.

DNS kaydını eklemek tek başına imzalamayı başlatmayabilir. Sağlayıcı panelinde “kimlik doğrulamayı başlat” veya benzeri adım gerekebilir. Test iletisinin tam başlığında DKIM-Signature bulunduğunu, doğrulama sonucunun geçtiğini ve d= alanının beklenen alanla hizalandığını kontrol edin. Anahtar değişiminde yeni selector'ı yayınlayıp doğruladıktan sonra gönderimi ona taşıyın; eski anahtarı, eski iletilerin doğrulanmasına yetecek geçiş süresinden sonra kaldırın.

3. DMARC'ı gözlemden uygulamaya geçirmek

DMARC kaydı _dmarc.ornek.com altında TXT olarak yayınlanır. Güvenli başlangıç örneği v=DMARC1; p=none; rua=mailto:dmarc@ornek.com biçiminde olabilir. p=none başarısız iletileri otomatik reddetmez; rapor toplayarak gerçek gönderim akışlarını görmenize yardım eder. Raporda IP adresleri ve kimlik doğrulama sonuçları yer alabileceği için özel bir posta kutusu veya güvenilir rapor işleme hizmeti kullanın ve veri işleme koşullarını değerlendirin.

Raporlarda meşru kaynakların SPF veya DKIM ile hizalı geçtiğinden emin olduktan sonra p=quarantine ve gerektiğinde pct ile sınırlı bir yüzdede uygulama denenebilir. Son aşamada p=reject, DMARC'ı geçemeyen iletilerin alıcı tarafından reddedilmesini ister. Alıcı sistem nihai kararı kendi politikasıyla verir; yayınlanan politika matematiksel bir teslimat garantisi değildir. Google'ın yönlendirmesi de SPF ve DKIM'i önce kurmayı, raporları izlemeyi ve politikayı kademeli sıkılaştırmayı önerir.

Pratik örnek: üç farklı gönderim kaynağı

Bir işletmenin personel postası, e-ticaret bildirimleri ve bülteni farklı sağlayıcılardan çıksın. Personel hizmetinin SPF include değeri ve DKIM selector'ı ana alana eklenir. E-ticaret sağlayıcısı mümkünse bildirim.ornek.com, bülten sağlayıcısı haber.ornek.com gibi ayrılmış alt alanlar kullanır. Her hizmet için sağlayıcının önerdiği SPF veya özel dönüş yolu ile DKIM doğrulanır. DMARC önce raporlama modunda çalıştırılır; raporlar beklenmeyen dördüncü bir kaynağı gösterirse bunun unutulmuş meşru uygulama mı, yetkisiz kullanım mı olduğu araştırılır. Ancak envanter temizlendikten sonra karantina veya reddetme politikasına geçilir.

Yaygın hatalar ve çözüm yaklaşımı

Birden fazla SPF kaydı: Politikaları tek kayıtta birleştirin; rastgele birini silmeden önce tüm kaynakları envanterle eşleştirin.
SPF sorgu sınırı: Kullanılmayan include mekanizmalarını kaldırın. “Flatten” işleminin IP değişikliklerini takip etme yükü getirebileceğini unutmayın.
DKIM kaydı var ama imza yok: Sağlayıcı panelinde imzalamanın etkin olup olmadığını ve doğru selector'ın kullanıldığını inceleyin.
DKIM body hash hatası: İleti gönderimden sonra ağ geçidi veya liste yazılımı tarafından değiştiriliyor olabilir.
DMARC raporu gelmiyor: rua adresini, DNS sözdizimini, harici rapor adresi yetkilendirmesini ve posta kutusu kapasitesini kontrol edin.
Meşru e-posta karantinada: Başlık analizinde hangi yöntemin neden hizalanmadığını bulun; politikayı körlemesine gevşetmek yerine ilgili göndericiyi düzeltin.

Bir örnek iletinin Authentication-Results, Received-SPF ve DKIM-Signature alanlarını birlikte okumak sorunu hızla daraltır. Kişisel veri veya gizli içerik barındıran tam başlıkları herkese açık yerlere yapıştırmayın. Alan Hattı'nın E-posta Başlık Analizi aracına veri girmeden önce hassas adresleri maskelemek uygun olabilir.

Sınırlamalar ve operasyonel gerçekler

SPF, DKIM ve DMARC hesabınız ele geçirildiğinde kötü niyetli fakat teknik olarak doğrulanmış gönderimi durdurmaz. Yönetici hesaplarında çok faktörlü kimlik doğrulama, en az ayrıcalık, API anahtarı rotasyonu ve gönderim hacmi uyarıları ayrıca gerekir. DMARC da benzer görünen başka bir alan adının kaydedilmesini veya görünen adın taklit edilmesini tek başına engellemez. Kullanıcı eğitimi ve marka alan adı izlemesi savunmayı tamamlar.

Uygulama kontrol listesi

İnsan, uygulama ve üçüncü taraf dâhil tüm göndericileri belgeleyin.
Tek ve geçerli SPF kaydı yayınlayıp DNS sorgu sınırını kontrol edin.
Her gönderim hizmetinde DKIM'i etkinleştirip gerçek bir iletiyle doğrulayın.
SPF/DKIM alanlarının görünür From: alanıyla DMARC hizalamasını inceleyin.
DMARC'a p=none ile başlayıp toplu raporları düzenli gözden geçirin.
Meşru kaynaklar temizlendikçe karantina ve reddetme politikasına aşamalı geçin.
Yeni hizmet eklendiğinde ve hizmet sonlandırıldığında DNS politikalarını güncelleyin.
Yılda birkaç kez anahtar rotasyonu, hesap güvenliği ve teslimat metriklerini gözden geçirin.

Kısa SSS

SPF ve DKIM varsa DMARC şart mı?

DMARC görünür gönderen alanıyla hizalamayı, raporlamayı ve başarısız iletiler için politika bildirimini sağlar. SPF ve DKIM tek başına bu yönetim katmanını sunmaz.

DMARC'ı doğrudan `p=reject` yapmalı mıyım?

Gönderici envanteri ve rapor analizi yapılmadan sert politikaya geçmek meşru iletileri etkileyebilir. Önce gözlem, sonra kontrollü karantina ve son olarak uygun görülürse reddetme daha güvenli bir yoldur.

DNS değişikliği hemen çalışır mı?

Yetkili sunucudaki kayıt hızlı güncellense de çözümleyici önbellekleri TTL dolana kadar eski cevabı tutabilir. Süreci DNS yayılımı rehberindeki adımlarla kontrol edin.

Resmî ve teknik kaynaklar

Kayıt taslağı hazırlarken SPF ve DMARC kayıt üreticilerini başlangıç noktası olarak kullanabilirsiniz; üretilecek metni posta sağlayıcınızın resmî belgesi ve gerçek gönderici envanterinizle doğrulamadan yayınlamayın.

SPF, DKIM ve DMARC nasıl kurulur?