DMARC'ın RFC 9989 güncellemesi pct etiketini kaldırıyor; yani etiketi silmek kayıtları sessizce sıkılaştırıyor

DMARC, 19 Mayıs 2026'da RFC 9989 olarak yayımlandı; yaklaşık on yıllık salt bilgilendirme niteliğindeki belge geçmişi sona erdi ve DMARC IETF Standards Track'e alındı. Steven Browning'ın dev.to'daki yazısına göre yeni belge RFC 7489 ve RFC 9091'in yerini alıyor, raporlamayı iki ayrı belgeye bölüyor (toplu raporlar için RFC 9990, ileti başına hata raporları için RFC 9991) ve pct etiketini tamamen kaldırıyor. Son değişiklik asıl tuzak: sahada kullanılan çok sayıda kayıt hâlâ pct içeriyor ve artık ölü bir etiketi temizlemek için bu kayıtları düzenlemek, sessizce ne yaptıklarını değiştiriyor.

pct'nin kaldırılması nötr bir düzenleme değil

pct etiketi, kademeli geçişlerin klasik aracıydı: p=quarantine yayımlayıp yanına pct=25 koyduğunuzda, raporları izlerken ve değeri yükseltirken başarısız iletilerin yalnızca dörtte biri karantinaya alınıyordu. RFC 9989, alıcıların etiketi ne kadar tutarsız yorumladığına atıfta bulunarak onu kaldırıyor ve bu çıkarmayı özel bir ekte belgeliyor.

İnce nokta, temizliğin ne yaptığında. Browning'in açıkladığı gibi, pct'yi hiç tanımayan alıcılar zaten yayımlanan politikayı tüm başarısız postalara uyguluyordu; dolayısıyla pct=25'i silmek hatırlanan bir çeyrek örnekleme davranışını geri getirmez. Tam tersine, tam zorunluluğu açık hale getirir: başarısızlıkların bir örneğini karantinaya alan bir etki alanı artık hepsini karantinaya alır. Bu amaçlanan son varış noktası olabilir; ancak yazıya göre bu sonuca geri dönen postalar üzerinden keşfedilmek yerine bilinçli olarak varmak daha iyidir.

Yüzde rampasının yerini bir test modu alıyor

Yerine gelen etiket t. t=y ile alıcılardan, yayımlanan politikadan bir adım yumuşak davranmaları isteniyor — p=reject karantina gibi, p=quarantine ise none gibi değerlendiriliyor — ve toplu raporlar gelmeye devam ediyor. Bu, istatistiksel örneklemeye göre daha temiz bir mekanizma; ama kademeli yüzde rampası artık yok: seçenekler bir test modu ya da politikanın kendisi.

p=reject'in yanlış varış noktası olduğu durumlar

RFC 9989 ayrıca p=reject'in nihai hedef olduğu varsayımına karşı çıkıyor. Bölüm 7.4, kullanıcıları e-posta listelerine yazan etki alanlarının p=reject yayımlamaması gerektiğini söylüyor. E-posta listeleri ve yönlendiriciler iletileri, özgün kimlik doğrulamayı bozan biçimlerde aktarıp yeniden yazıyor; bu yüzden reject politikası kendi kullanıcılarınızın meşru postasını geri döndürüyor ve liste yazılımları bu geri dönenlere genellikle kullanıcıyı abonelikten çıkararak karşılık veriyor. Salt işlem amaçlı bir etki alanı reject'te makul biçimde sonlanabilir; insanların kullandığı bir etki alanı quarantine'de durmak isteyebilir.

Küçüken üç belge değişikliği

Kurumsal etki alanı keşfi artık Public Suffix List'e danışmıyor. RFC 9989, DNS Tree Walk adını verdiği bir dizi DNS sorgusu tanımlıyor — çok katmanlı bir etki alanında bir şey tuhaf davrandığında hatırlamaya değer bir ad. RFC 9091'den devralınan np etiketi, hiç var olmayan alt etki alanları için politika yayımlamanıza izin veriyor; var olmayan alt etki alanları sahtecilikte sıkça istismar edildiğinden bu yararlı. np olmadan bunlar sp'yi, o da yoksa p'yi miras alıyor. Ayrıca sp, kurumsal etki alanı düzeyinin altında yayımlanan kayıtlarda artık yok sayılıyor; bu da hiçbir işe yaramıyor gibi görünen alt etki alanı sp ayarlarını açıklıyor.

Aynı kayıtlardaki SPF ve DKIM tuzakları

Bir SPF kaydı kısa görünebilir ama değerlendirme başına RFC 7208'ın üst sınırı olan on DNS sorgusu yapan terime yakın olabilir; çünkü her include:, sağlayıcının yayımladığı şeyi özyinelemeli olarak içine çeker. Sınırın aşılması permerror döndürür — yalnızca raporlarda görünen sert bir hata — ve belge ayrıca en fazla iki void lookup öneriyor; bu da uzun zaman önce terk edilmiş hizmetler için include'ları çıkarmanın bir nedeni. Ayrıca, yalın all ile biten bir kayıt her göndereni yetkilendirir; çünkü niteliksiz bir mekanizma varsayılan olarak + olur; neredeyse kesinlikle ~all veya -all kastedilmiştir. Aynı adda iki SPF kaydı da permerror'dır ve ikisinin tek bir kayıtta birleştirilmesiyle düzeltilir.

DKIM tarafında, eksik anahtar bildiren bir denetleyici çoğu zaman yalnızca yaygın selector'ları tahmin edip sizinkini kaçırmış demektir; çünkü onları listeleyen standart bir sorgu yoktur. Gerçek imzalı bir ileti işi bitirir: DKIM-Signature başlığında s= selector, d= ise imzalayan etki alanıdır ve bu sıkça gönderim platformuna aittir, From adresiyle örtüşmez. Boş bir p= değerine sahip anahtar kaydı, anahtarın yok olduğunu değil, iptal edildiğini gösterir.

Bir şeye dokunmadan önce kontrol edilecekler

Yazı üç adım öneriyor: kendi etki alanınızdan harici bir alıcıya gönderilmiş gerçek bir ileti başlığına bakın — bu size DKIM selector'ını ve imzalayan etki alanını verir; SPF kaydınızın sonunu okuyun ve include'ları sayın; ve herhangi bir şeyi sıkılaştırmadan önce bir haftalık toplu raporları gözden geçirin, çünkü neredeyse her zaman kimsenin hatırlamadığı meşru bir gönderici vardır.

Neden önemli

E-posta kimlik doğrulama kayıtları bir kez yapılandırılır ve yıllarca dokunulmaz; bir belge revizyonu bir kaydın hâlâ referans verdiği bir şeyi emekliye ayırdığında DNS hiçbir uyarı vermez. pct'nin kaldırılması, rutin temizliği bir politika değişikliğine dönüştürür: iyi niyetli bir temizlik, zorunluluğu örneklenmiş bir paydan tüm başarısız iletilere genişletir ve hiçbir yerde bir hata mesajı görünmez. Zarar, aniden karantinaya alınan veya reddedilen meşru postaya — e-posta listesi iletileri, yönlendirilmiş mesajlar — düşer. Düzenlemeden önce raporları okumak ucuz sigortadır. Belirtmeye değer bir sınır: bu kayıtlar başkalarının sizin etki alanınız adına göndermesini engeller; gelen postayı süzmez ve benzer görünümlü etki alanlarını önleyemez.