Mayıs 2026’da IETF, e-posta yöneticilerinin yıllardır beklediği bir adımı attı: RFC 9989, RFC 9990 ve RFC 9991 toplu olarak “DMARCbis” adıyla yayımlandı. Bu üç belge, 2015’ten bu yana DMARC’ın temel kaynağı olan RFC 7489’un yerini alıyor.

Önemli değişiklik teknik değil, statü açısından. Orijinal RFC 7489, Bilgilendirici (Informational) bir belge olarak yayımlanmıştı; yani sektörün hâlihazırda ne yaptığını anlatıyordu, zorunluluk getirmiyordu. DMARCbis ise IETF Standartlar Takibi’nde Önerilen Standart (Proposed Standard) olarak geliyor — resmi bir İnternet Standardına giden yolun ilk adımı. Kısaca söylemek gerekirse: DMARC, “endüstrinin güçlü tavsiyesi” olmaktan çıkıp “resmi protokol” statüsüne geçti.

Üç RFC Ne Kapsiyor?

Çalışma üç belgeye net biçimde ayrılmış durumda:

  • RFC 9989 temel spesifikasyon. Gönderenlerin DNS’e nasıl DMARC politikası yayımladığını, alıcı posta sunucularının gelen mesajları bu politikaya göre nasıl değerlendirdiğini ve kimlik doğrulama başarısız olduğunda ne yapılacağını tanımlıyor.
  • RFC 9990 toplu raporlamayı standartlaştırıyor. Gelen kutusu sağlayıcılarının alan adı sahiplerine günlük olarak gönderdiği XML özetleri; hangi IP adreslerinin adınıza posta gönderdiğini ve SPF, DKIM, DMARC kontrollerinden nasıl geçtiğini gösteriyor.
  • RFC 9991 hata raporlamasını ele alıyor. Belirli bir mesaj kimlik doğrulamayı geçemediğinde tetiklenen, mesaj başına gerçek zamanlıya yakın raporlar. DMARC kaydınızdaki ruf etiketiyle talep ediliyor.

Aslında Ne Değişti?

Önce iyi haber: Mevcut DMARC kayıtları geçerliliğini koruyor. Protokol tanımlayıcısı hâlâ v=DMARC1 ve yeni spesifikasyona uyum sağlamak için herhangi bir değişiklik yapmanız gerekmiyor.

Bununla birlikte birkaç şey değişti.

Kaldırılan etiketler. Üç etiket kullanımdan kaldırıldı: pct, rf ve ri. pct etiketi zaten başlı başına bir sorundu — gönderenlerin DMARC politikasını yalnızca başarısız postaların belirli bir yüzdesine uygulamasına izin veriyordu; bu da alıcılar arasında tutarsız uygulamaya yol açıyordu. Yeni spesifikasyon, bu kullanım durumunun daha temiz bir yedeği olarak t etiketini (test modu) sunuyor.

Genel Sonek Listesi yerini DNS Ağaç Yürüyüşü’ne bırakıyor. Daha önce alıcılar, hizalama kontrolleri için bir mesajın Kurumsal Alan Adı’nı belirlemek amacıyla harici ve elle tutulan bir liste olan Genel Sonek Listesi’ni (Public Suffix List) kullanıyordu. DMARCbis, bunu DNS’te genel sonek operatörünün kendi girişini doğrudan kontrol ettiği bir DNS Ağaç Yürüyüşü algoritmasıyla değiştiriyor. Bu yaklaşım doğruluğu artırıyor ve liste güncellemeleri ile alıcı adaptasyonu arasındaki gecikmeyi ortadan kaldırıyor.

Genel Sonek Alan Adları için daha iyi destek. .bank, .gov, ülke kodu yapıları gibi Genel Sonek Alan Adları artık yeni psd etiketi ve DNS Ağaç Yürüyüşü mekanizması aracılığıyla DMARC uygulamasına resmi olarak katılabiliyor.

E-posta listeleri hâlâ karmaşık bir mesele. Yeni spesifikasyonun tam olarak çözemediği bir sorun var: e-posta listesi ve iletme sorunu. RFC 9989 bunu açıkça kabul ediyor ve önemli mailing list trafiğinin söz konusu olduğu ortamlarda agresif p=reject politikalarına karşı çıkıyor. Alan adınız çok sayıda liste trafiğine katılıyorsa, bunu göz önünde bulundurmanız gerekiyor.

Raporlama Tarafı Daha Düzenli Hale Geldi

RFC 9990, toplu XML biçimini öncekinden çok daha katı biçimde standartlaştırıyor; bu da rapor ayrıştırıcılarının ve DMARC izleme araçlarının daha net uyum hedeflerine sahip olacağı anlamına geliyor. Farklı sağlayıcılardan gelen DMARC raporlarının neden birbirinden hafifçe farklı göründüğünü hiç merak ettiyseniz, nedenlerinden biri de buydu — orijinal spesifikasyon tutarsızlığa yeterince zemin bırakıyordu.

RFC 9991 kapsamında hata raporlarına eklenen sıkılaştırma, açık bir gizlilik notu içeriyor: bu raporlar kişisel veri içerebilecek tam mesaj başlıkları ve içerik barındırabilir. ruf URI’leri kullanıyor ve hata raporları topluyorsanız, bu verilerin işlenme biçiminin gizlilik yükümlülüklerinizle uyumlu olduğundan emin olun.

kalfaoglu.net Müşterileri İçin Ne Anlama Geliyor?

Bizde barındırılan alan adları için acil bir değişiklik söz konusu değil. DMARC politikanız zaten p=quarantine ya da p=reject düzeyindeyse, ek bir işlem yapmanıza gerek yok.

Bununla birlikte, henüz yapmadıysanız yapılması gereken iki şey var:

Birincisi, DMARC kaydınızda pct etiketi varsa kaldırın. Bu etiket her zaman geçici bir çözümdü ve artık resmi olarak kullanımdan kaldırıldı. Tam uygulamaya geçin ya da gerçekten test moduna ihtiyacınız varsa yeni t etiketini kullanın.

İkincisi, yıllarca p=none yani izleme modunda kalıyorsanız — yeni spesifikasyon sektörün bu tutumdan uzaklaşmaya devam ettiğini açıkça ortaya koyuyor. Büyük gelen kutusu sağlayıcıları toplu göndericiler için bunu zaten zorunlu kılıyor. En azından p=quarantine‘e geçmeyi planlarınıza eklemekte fayda var.

Daha Büyük Resim

IETF’in DMARCbis’i yayımlaması, yarın gelen kutusu teslim edilebilirliğinizi değiştirmez. Ama önemli bir sinyal veriyor: DMARC artık yalnızca “büyük sağlayıcıların üzerinde anlaştığı şey” değil. Resmi olarak standartlaştırılmış bir protokol ve İnternet Standardı statüsüne giden yolda net bir yol haritasına sahip. Bu durum, düzenleyiciler, denetçiler (PCI DSS v4.0 zaten DMARC’a atıfta bulunuyor) ve giderek daha fazla gönderen itibarını değerlendiren kurumsal posta sistemleri açısından önem taşıyor.

Mevcut DMARC, SPF ve DKIM kurulumunuzun kontrolünü yaptırmak isterseniz bir destek talebi açın — yaklaşık on dakika alan bu inceleme ücretsiz.