Bu rehber, Mayıs 2026'da yayımlanan yeni standart RFC 9989 temelinde hazırlanmıştır. RFC 9989, eski RFC 7489'u geçersiz kılar; toplu raporları RFC 9990'a, mesaj başına hata raporlarını RFC 9991'e ayırır. Yeni standartta pct, rf ve ri etiketleri tarihsel duruma alınmış; test modu için t, var olmayan alt alan adları için np etiketi etkinleştirilmiştir.
SPF, DKIM ve DMARC bir spam filtresi değildir. Mesajın içeriğinin iyi niyetli olduğunu kanıtlamaz; gönderen alan adının kullanımını doğrular, politika ve raporlama sağlar. Zararlı içerik taraması, kullanıcı farkındalığı, güvenli e-posta ağ geçidi ve hesap güvenliği yine gereklidir.
SPF, DKIM ve DMARC arasındaki fark
| Mekanizma | Neyi doğrular? | Nerede yayımlanır? | Temel sınır |
|---|---|---|---|
| SPF | Gönderen IP'nin SMTP MAIL FROM/Return-Path alan adını kullanma yetkisi | Alan adında DNS TXT | Yönlendirmede bozulabilir; görünen From alanını tek başına korumaz |
| DKIM | Mesajın seçili başlık ve gövde bölümlerinin imza sonrası değişmediği ve d= alanının imzayı doğruladığı | selector._domainkey alanında DNS TXT | İmza alanı görünen From ile hizalanmazsa DMARC'ı geçirmeyebilir |
| DMARC | Görünen From alanının SPF veya DKIM ile hizalanmış geçerli kimliğe sahip olup olmadığı | _dmarc alanında DNS TXT | SPF/DKIM doğru kurulmadan etkili olmaz; alıcı son kararı kendi politikasıyla verebilir |
Basit ifade ile SPF “bu IP bu zarf alan adı adına e-posta gönderebilir mi?”, DKIM “mesaj bu alan adının anahtarıyla imzalanmış ve imza bozulmamış mı?”, DMARC ise “kullanıcının gördüğü From alanı, başarılı SPF veya DKIM kimliğiyle hizalı mı ve başarısızsa ne yapılmalı?” sorularını yanıtlar.
SPF nasıl çalışır?
RFC 7208'e göre SPF, alan adı sahibinin hangi sunucuların o alan adını SMTP MAIL FROM veya HELO/EHLO kimliği olarak kullanabileceğini DNS'te ilan etmesini sağlar. Alıcı posta sunucusu gönderen IP'yi SPF kaydındaki mekanizmalarla karşılaştırır.
Basit örnek:
CODE TERMINAL
example.com. 3600 IN TXT "v=spf1 ip4:192.0.2.10 include:_spf.provider.example -all"Bu kayıt 192.0.2.10 adresine ve sağlayıcının include kaydında yetkilendirdiği sunuculara izin verir; diğer kaynaklar için -all hard fail sonucu ister.
| SPF öğesi | Anlamı |
|---|---|
| v=spf1 | SPF sürüm 1 kaydı |
| ip4 / ip6 | Belirli IP veya CIDR aralığını yetkilendirir |
| a | Belirtilen alanın A/AAAA adreslerini yetkilendirir |
| mx | Alanın MX sunucularını yetkilendirir |
| include | Başka bir alanın SPF politikasını yetkili kaynak kümesine ekler |
| redirect | Değerlendirmeyi başka bir SPF kaydına devreder |
| all | Kalan bütün kaynakları eşleştirir |
| + | pass; varsayılan niteleyici |
| ~ | softfail |
| - | fail |
| ? | neutral |
SPF için kritik kurallar
[LIST]
[*]Bir alan adında yalnızca bir SPF kaydı bulunmalıdır. İki ayrı v=spf1 TXT kaydı permerror oluşturabilir.
[*]include, a, mx, exists ve redirect gibi DNS sorgusu üreten terimler toplamda RFC sınırlarını aşmamalıdır. Yaygın “10 DNS lookup” hatası, çok sayıda sağlayıcının kontrolsüz eklenmesinden doğar.
[*]Kullanılmayan eski sağlayıcılar ve IP aralıkları kayıttan çıkarılmalıdır.
[*]SPF görünen From alanını değil çoğunlukla Return-Path/MAIL FROM alanını doğrular. DMARC hizalaması olmadan saldırgan farklı bir görünen From kullanabilir.
[*]E-posta yönlendirme, ileten sunucunun IP'si özgün gönderenin SPF kaydında olmadığı için SPF'yi bozabilir. DKIM bu akışta daha dayanıklı olabilir.
[*]Park edilmiş veya e-posta göndermeyen alan adları için açık bir deny politikası değerlendirilebilir:
CODE TERMINAL
v=spf1 -all[/LIST]
DKIM nasıl çalışır?
DKIM, RFC 6376'da tanımlanan alan adı tabanlı dijital imza mekanizmasıdır. Gönderen posta sistemi mesaj gövdesinin ve seçilen başlıkların özetini özel anahtarla imzalar; alıcı sistem imzadaki d= alanı ve s= selector değeriyle DNS'teki genel anahtarı bulur.
Örnek DNS kaydı:
CODE TERMINAL
selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."Örnek imza başlığındaki önemli alanlar:
| DKIM alanı | İşlev |
|---|---|
| v=1 | DKIM sürümü |
| a= | İmza algoritması; örneğin rsa-sha256 |
| d= | İmzayı üstlenen alan adı |
| s= | DNS anahtar selector'ı |
| c= | Başlık/gövde canonicalization yöntemi |
| h= | İmzalanan başlık alanları |
| bh= | Gövde özeti |
| b= | Dijital imza değeri |
| t= | İmza zaman damgası |
| x= | Varsa imza sona erme zamanı |
Selector kullanımı anahtar döndürmeyi kolaylaştırır. Örneğin selector1 ve selector2 paralel tutulabilir; yeni anahtar bütün gönderenlerde etkinleştirildikten ve DNS önbellek süresi geçtikten sonra eski özel anahtar devreden çıkarılır.
DKIM anahtar yönetimi
- Özel anahtarı DNS'e veya uygulama koduna koymayın; yalnızca imzalayan posta sisteminde, sınırlı erişimle saklayın.
- Sağlayıcı destekliyorsa RSA için 2048 bit anahtar kullanın. Gmail, kişisel hesaplara gönderimde en az 1024 bit ister ve 2048 biti önerir.
- Her sağlayıcı veya gönderim sınıfı için ayrı selector kullanmak olay müdahalesini ve anahtar iptalini kolaylaştırır.
- Anahtarları düzenli döndürün; eski selector'ı DNS TTL ve gecikmiş posta teslimi hesaba katılmadan silmeyin.
- From, Date, Subject, Message-ID ve MIME başlıkları gibi kritik alanların uygun biçimde imzalandığını doğrulayın.
- Posta listesinin konu etiketi eklemesi veya gövde altbilgisi değiştirmesi DKIM imzasını bozabilir. Gerçek akışı test edin.
DMARC nasıl karar verir?
DMARC, RFC 5322 From başlığındaki kullanıcıya görünen alan adını “Author Domain” olarak alır. Mesajın DMARC'tan geçmesi için şu iki yoldan en az biri başarılı olmalıdır:
- SPF sonucu pass olmalı ve SPF ile doğrulanan MAIL FROM alan adı görünen From alanıyla hizalanmalıdır.
- DKIM imzası geçerli olmalı ve imzadaki d= alan adı görünen From alanıyla hizalanmalıdır.
SPF ve DKIM'in ikisinin birden geçmesi zorunlu değildir; hizalı tek bir başarılı mekanizma DMARC pass için yeterlidir. Bununla birlikte iki mekanizmayı da doğru kurmak yönlendirme, sağlayıcı hatası ve anahtar sorunlarına karşı dayanıklılık sağlar.
Relaxed ve strict alignment
RFC 9989 iki hizalama modu tanımlar:
| Mod | Örnek | Sonuç |
|---|---|---|
| Relaxed (r) | From: news.example.com, DKIM d=example.com | Aynı organizasyon alanını paylaştığı için hizalı |
| Strict (s) | From: news.example.com, DKIM d=news.example.com | Alan adları birebir aynı olduğu için hizalı |
| Hizasız | From: news.example.com, DKIM d=provider.example | Farklı organizasyon alanları; DMARC için hizalı değil |
adkim ve aspf etiketlerinin varsayılanı relaxed moddur. Çoğu alan sahibi için relaxed hizalama yeterlidir. Strict moda geçmeden önce bütün üçüncü taraf göndericilerin From, Return-Path ve DKIM d= alanlarını doğru alt alanlarla yönetebildiği doğrulanmalıdır.
RFC 9989 DMARC kaydı örnekleri
İzleme başlangıcı:
CODE TERMINAL
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"Zorlayıcı politika:
CODE TERMINAL
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:[email protected]"Yeni test modu:
CODE TERMINAL
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; t=y; rua=mailto:[email protected]"t=y, alan sahibinin ilan edilen politikayı test ettiğini belirtir. RFC 9989'a göre alıcıdan politikayı bir seviye aşağı uygulaması beklenir: p=reject için quarantine, p=quarantine için none. Ancak yeni etiketin alıcı desteği kademeli olabileceğinden en geniş uyumluluk için ilk envanter aşamasında p=none kullanılmalıdır.
DMARC etiketleri
| Etiket | Durum ve işlev |
|---|---|
| v | Zorunlu ve ilk etiket; değeri büyük/küçük harfe duyarlı DMARC1 olmalıdır |
| p | Ana alan için none, quarantine veya reject politikası |
| sp | Var olan alt alanlar için ayrı politika |
| np | RFC 9989 ile etkin; var olmayan alt alanlar için politika |
| adkim | DKIM hizalaması: r relaxed, s strict |
| aspf | SPF hizalaması: r relaxed, s strict |
| rua | RFC 9990 toplu raporlarının gönderileceği URI'ler |
| ruf | RFC 9991 mesaj başına hata raporlarının gönderileceği URI'ler |
| fo | Hangi koşullarda hata raporu istendiği |
| t | RFC 9989 test modu: y veya varsayılan n |
Eski rehberlerde sık görülen pct, rf ve ri etiketleri RFC 9989 kayıt defterinde tarihsel durumdadır. Yeni kurulumlar yüzdesel dağıtıma güvenmemeli; gönderim akışlarını alt alan, sağlayıcı veya aşamalı operasyon planıyla bölmeli ve p=none → quarantine → reject geçişini rapor verisine göre yapmalıdır.
Toplu DMARC raporları: rua ve RFC 9990
rua adresine gelen toplu raporlar genellikle sıkıştırılmış XML dosyalarıdır. Her rapor; gönderen IP, mesaj sayısı, uygulanan politika, SPF/DKIM sonucu ve hizalama bilgisini özetler. Bunlar ileti içeriğini okumak için değil, hangi sistemlerin alan adınızı kullandığını ve hangi akışların kimlik doğrulamada başarısız olduğunu görmek için tasarlanır.
Bir raporda şu sorular sorulmalıdır:
- IP veya sağlayıcı kuruluş envanterinde var mı?
- DKIM pass olsa bile d= alanı From ile hizalı mı?
- SPF pass sonucu kendi Return-Path alanınız için mi, sağlayıcının alanı için mi?
- Aynı kaynak neden bazı günler veya bazı mesajlarda fail oluyor?
- Forwarder, posta listesi ya da güvenlik ağ geçidi mesajı değiştirmiş olabilir mi?
- Politika override nedeni ve alıcının uyguladığı disposition nedir?
- Beklenmeyen kaynak gerçek bir spoofing girişimi mi, unutulmuş meşru bir uygulama mı?
Rapor posta kutusu yüksek hacim ve kötü biçimlendirilmiş ekler alabilir. Ayrı posta kutusu, boyut sınırı, zararlı ek taraması, otomatik ayrıştırma, saklama süresi ve kişisel veri değerlendirmesi uygulanmalıdır. rua başka bir kuruluşun alanına yönlendirilecekse RFC'nin öngördüğü dış hedef yetkilendirme kaydı gerekir.
Hata raporları: ruf ve RFC 9991
ruf, belirli başarısızlık koşullarında mesaj başına ayrıntılı rapor ister. Tüm alıcılar bu raporları göndermez. Raporlar başlık veya içerik parçaları içerebileceği için kişisel veri, ticari sır ve düzenleyici yükümlülük riski taşır.
ruf kullanmadan önce hukuk, gizlilik ve veri saklama ekipleriyle kapsam belirlenmeli; hedef posta kutusu sıkı erişim kontrolüne alınmalıdır. Çoğu kuruluş için güvenli başlangıç, yalnızca rua toplu raporlarıyla envanter çıkarmaktır.
Adım adım güvenli kurulum planı
- Bütün göndericileri envantere alın: Microsoft 365/Google Workspace, CRM, yardım masası, pazarlama, faturalama, izleme, yazıcı, web formu ve özel SMTP uygulamalarını bulun.
- Gönderim alanlarını ayırın: Kurumsal posta, işlem bildirimi ve pazarlama için gerektiğinde ayrı alt alanlar kullanın.
- Tek SPF kaydı oluşturun: Yalnızca etkin kaynakları ekleyin, DNS lookup ve karakter sınırlarını test edin.
- Her kaynakta DKIM'i etkinleştirin: d= alanının görünen From ile relaxed veya strict olarak hizalandığını doğrulayın.
- Test mesajlarını inceleyin: Authentication-Results, Return-Path, DKIM-Signature ve From alanlarını karşılaştırın.
- p=none ve rua yayımlayın: En az bir tam iş döngüsü boyunca raporları toplayın; aylık/seyrek sistemleri de kapsayın.
- Meşru hataları düzeltin: Unutulmuş sağlayıcıları, bozuk DKIM'i, yanlış Return-Path'i ve yönlendirme akışlarını çözün.
- Quarantine aşamasına geçin: Kritik gönderenler doğrulandıktan sonra politika değişikliğini düşük riskli alan veya gönderim sınıfında deneyin.
- Reject uygulayın: Meşru trafik DMARC pass oranı ve raporlar yeterli güven sağladığında sahte trafiği reddetme isteği yayımlayın.
- Sürekli izleyin: Yeni SaaS sözleşmelerini DNS/e-posta güvenliği onayına bağlayın; eski kaynakları ve selector'ları kaldırın.
Yaygın yapılandırma hataları
- Aynı alan adında iki SPF kaydı yayımlamak
- SPF include zincirinde DNS sorgu sınırını aşmak
- Sağlayıcının SPF'si geçiyor diye DMARC hizalamasını kontrol etmemek
- DKIM d= alanını sağlayıcının alanında bırakmak
- Selector genel anahtarını yanlış ad altında yayımlamak
- Eski veya sızmış DKIM özel anahtarını döndürmemek
- p=reject politikasına rapor toplamadan geçmek
- Alt alanların p politikasından etkileneceğini unutmak
- E-posta göndermeyen park alanlarında SPF/DKIM/DMARC koruması bırakmamak
- pct etiketini RFC 9989'a uygun kademeli geçiş sanmak
- rua posta kutusunu rapor hacmi ve ek riskine hazırlamamak
- Yönlendirme ve posta listesi akışlarını gerçek alıcılarda test etmemek
Sorun giderme: Authentication-Results nasıl okunur?
Bir test mesajının kaynak başlıklarında şu örneğe benzer satır aranır:
CODE TERMINAL
Authentication-Results: mx.example.net;
spf=pass smtp.mailfrom=bounce.example.com;
dkim=pass header.d=example.com;
dmarc=pass header.from=example.comBurada SPF bounce.example.com için geçer ve relaxed hizalamada example.com ile aynı organizasyon alanını paylaşır. DKIM d=example.com imzası da geçer. Bu nedenle DMARC pass sonucunun iki bağımsız yolu vardır.
DKIM pass, DMARC fail görülüyorsa ilk kontrol d= ile From alanlarının hizalanmasıdır. SPF pass, DMARC fail görülüyorsa Return-Path alanının sağlayıcıya ait farklı bir alan olma ihtimali yüksektir. İkisi de fail ise gönderen IP yetkisi, DNS yayılımı, selector, mesaj değişikliği ve anahtar durumu incelenmelidir.
E-posta yönlendirme ve ARC
Klasik yönlendirme gönderen IP'yi değiştirdiği için SPF'yi bozabilir. Mesaj gövdesi ve imzalanan başlıklar değişmiyorsa DKIM geçmeye devam edebilir. Posta listeleri konu satırı veya altbilgi eklediğinde DKIM de bozulabilir.
ARC (Authenticated Received Chain), aracıların önceki kimlik doğrulama sonuçlarını zincir hâlinde taşımasına yardımcı olur; fakat alan sahibinin SPF, DKIM ve DMARC kurma sorumluluğunu ortadan kaldırmaz. Alıcıların ARC zincirine güvenip güvenmemesi yerel değerlendirmeye bağlıdır.
Gönderim gereksinimleri ve teslim edilebilirlik
Gmail'in güncel gönderici yönergeleri bütün gönderenler için SPF veya DKIM, günde 5.000'den fazla ileti gönderenler için SPF, DKIM ve DMARC ister. Doğrudan gönderimde From alanının SPF veya DKIM alanıyla hizalanması gerekir. Gmail ayrıca TLS, geçerli ileri/ters DNS, RFC 5322 biçimi, düşük spam oranı ve pazarlama iletilerinde tek tıkla abonelikten çıkmayı şart koşar.
Bu gereksinimler DMARC'ın yalnızca güvenlik kontrolü olmadığını gösterir: yanlış kimlik doğrulama teslimatın ertelenmesine, spam klasörüne düşmesine veya reddedilmesine yol açabilir. Ancak geçerli SPF/DKIM/DMARC, kötü gönderim itibarı veya istenmeyen içerik için otomatik teslimat garantisi değildir.
Sonuç
SPF yetkili gönderen altyapısını, DKIM mesaj bütünlüğü ve imzalayan alanı, DMARC ise kullanıcıya görünen From alanıyla kimlik doğrulama hizalamasını, politika ve raporlamayı yönetir. Etkili koruma için üçü birlikte kurulmalı ve gerçek gönderim akışları üzerinden test edilmelidir.
2026 tarihli RFC 9989 ile eski RFC 7489 yaklaşımındaki pct, rf ve ri etiketleri tarihsel duruma geçti; t test modu ve np var olmayan alt alan politikası standart hâline geldi. Güvenli geçiş; eksiksiz envanter, tek SPF kaydı, hizalı DKIM, p=none ile rapor analizi ve veriye dayalı quarantine/reject uygulamasından oluşur.
Kaynaklar
- IETF RFC 9989 – DMARC temel protokolü
- IETF RFC 9990 – DMARC Aggregate Reporting
- IETF RFC 9991 – DMARC Failure Reporting
- IETF RFC 7208 – Sender Policy Framework (SPF)
- IETF RFC 6376 – DomainKeys Identified Mail (DKIM)
- Google – E-posta gönderici yönergeleri
- Microsoft Learn – SPF, DKIM ve DMARC birlikte nasıl çalışır?
TR Siber Ekibi