DMARC Kaydı Denetleyicisi, gerçek postalar kaybolmaya, spama düşmeye veya markanıza davet etmediğiniz kişiler tarafından sahteciliği yapılmaya başlayana kadar kulağa soyut gelen bir e-posta altyapısı parçası içindir. Bir alan adı girersiniz, denetleyici _dmarc.alanadiniz.com adresindeki TXT kaydını arar, politikayı ayrıştırır ve bu alan adının alıcı posta sistemlerine gerçekte ne yapmalarını söylediğini gösterir. Buna none, quarantine veya reject gibi ana politika, SPF ve DKIM için uyum (alignment) kuralları, rua ve ruf içindeki rapor adresleri, yüzde etiketi pct, raporlama aralığı ri ve insanların genellikle yalnızca pahalı bir şeyler ters gittikten sonra keşfetme eğiliminde olduğu diğer ayrıntılar dahildir.
Bu terimi ilk kez duyan biri için harfler harika bir şekilde lafzidir. DMARC, Domain-based Message Authentication, Reporting, and Conformance (Alan Adı Tabanlı İleti Kimlik Doğrulaması, Raporlama ve Uygunluk) anlamına gelir. Bu kelimeler şairler tarafından seçilmemiştir ve çekiciliklerinin bir parçası da budur. Domain-based (Alan Adı Tabanlı), sistemin görünür gönderen alan adına bağlı olduğu anlamına gelir. Message Authentication (İleti Kimlik Doğrulaması), SPF ve DKIM gibi teknik kontrollere dayandığı anlamına gelir. Reporting (Raporlama), alıcıların gördükleri hakkında geri bildirim gönderebilecekleri anlamına gelir. Conformance (Uygunluk) ise gönderen alan adının kimliği doğrulanmamış veya uyumsuz postaların nasıl ele alınması gerektiğini belirten bir politika yayınlayabileceği anlamına gelir. Yavaşça okunduğunda kısaltma neredeyse bürokratik bir palto giymiş eksiksiz bir kullanım kılavuzudur.
Bu görünür alan adı kısmı birçok insanın fark ettiğinden daha önemlidir. SPF ve DKIM, DMARC'tan önce zaten vardı. SPF, bir alan adının kendisi için hangi sistemlerin posta göndermesine izin verildiğini yayınlamasını sağlar. DKIM, bir imzalayıcının DNS'teki bir genel anahtarla doğrulanabilen kriptografik bir imza eklemesine olanak tanır. Yararlıdır, evet. Kendi başlarına her zaman yeterli mi, hayır. Daha derin sorun uyumdu (alignment). Bir ileti arka planda bir yerde SPF veya DKIM'den geçebilir ve yine de onu okuyan kişiye farklı bir görünür Kimden (From) alan adı gösterebilirdi. Bu boşluk sahtecilik (spoofing), kimlik avı (phishing), marka suistimali ve genel bir teknik belirsizlik karnavalı için verimli bir topraktı. DMARC bu boşluğu daraltmak için geldi. Daha disiplinli bir soru sorar: Kimliği doğrulanmış tanımlayıcılar, insan alıcıya gösterilen alan adıyla uyumlu mu?
İşte bu yüzden DMARC yalnızca "bir DNS kaydı daha" değildir. SPF ve DKIM'in üzerinde oturan bir politika katmanıdır. DMARC genel bakışı bunu alıcıların bir iletinin iddia edilen gönderici hakkında bildikleriyle uyumlu olup olmadığını belirlemelerine yardımcı olan bir mekanizma olarak açıklar ve uymuyorsa yayınlanan politika alan adı sahibinin bu tür postaların nasıl işlenmesini istediğini onlara bildirir. Pratik terimlerle DMARC e-posta kimlik doğrulamasını alır ve sonuçlar ekler. Bir alan adı izleme modu olan p=none ile temkinli bir şekilde başlayabilir. Başarısız olan postaların şüpheyle ele alınmasını alıcılardan isteyen quarantine'e geçebilir. Ve "Uyum yeterince kötü başarısız olursa içeri alma" demenin yetişkin versiyonu olan reject'e geçebilir.
Arkasındaki tarih her zamanki internet hikayesidir: Önce güven, sonra onar, hasar yeterince pahalı hale geldikten sonra standartlaştır. E-posta, gönderen dürüstlüğüne modern gerçekliğin hak ettiğinden çok daha fazla inancı olan bir çağda inşa edildi. Sahtecilik kolaylaştı, kimlik avı karlı hale geldi ve marka taklidi istikrarlı bir endüstriyel egzersiz oldu. SPF ve DKIM bulmacanın birer parçasını çözdü, ancak kuruluşların görünür Kimden alan adının nasıl değerlendirilmesi gerektiğini ve hangi geri bildirimlerin gelmesi gerektiğini tek bir net politikada söylemenin bir yoluna hala ihtiyaçları vardı. Bu ihtiyaç RFC 7489'da yayınlanan DMARC'ı doğurdu. Standartlar dili ölçülü olma eğilimindedir, ancak altta yatan neden açıktır: İnternet absürt ölçekte küresel ileti alışverişine izin vermekte ısrar ediyorsa, bir iletinin arkasında gerçekte kimin durduğunu ve bu iddia çöktüğünde ne olması gerektiğini söylemenin bir yolu olsa iyi olur.
DNS ana bilgisayar adının kendi içinde gizlenmiş küçük bir idari komedi vardır. DMARC kayıtları _dmarc altında yayınlanır. Çıplak alan adında değil, bazı mistik "güvenlik ayarları" bulutunda değil, yıllar önce yapılandırdığına yemin eden son sistem yöneticisinin duygusal hafızasında değil. Politikanın _dmarc.example.com gibi özel bir etikette olması beklenir. Bu sabit yerleşim vardır çünkü standart yazarları hazine avları yerine tekrarlanabilir sistemleri tercih eder. Alıcı bir sunucu politika kaydınızı bulmak için sezgiye, kehanete veya ekip sohbetinize erişime ihtiyaç duymamalıdır.
Kaydın grameri de sıradan kopyala-yapıştır kültürünün tercih edeceğinden daha az bağışlayıcıdır. RFC 7489, kaydın v=DMARC1 ile başlamasını gerektirir ve p etiketi zorunludur ve sürüm etiketinden hemen sonra gelmelidir. Aynı konumda birden fazla DMARC kaydı yayınlanırsa, sonuç "ekstra güvenlik" değildir. Başarısızlıktır. RFC, birden fazla DMARC kaydı görünürse Posta Alıcısının o konumda keşfedilen politikayı göz ardı edeceğini söyler. Bu, protokolün yaratıcı aşırı yapılandırmaya soğukkanlı bir katılımsızlıkla yanıt verdiği nadir alanlardan biridir.
Sonra insanların DNS yönetim panellerinde karşılaşıp yalnızca kas hafızasından anladığını varsaydığı etiketler gelir. p ana politikadır. sp alt alan adları için ayrı bir politika tanımlayabilir. adkim ve aspf DKIM ve SPF için uyum katılığını kontrol eder. Esnek (relaxed) uyum daha bağışlayıcıdır. Katı (strict) uyum daha kesindir. pct bir alan adının politikayı başarısız olan postaların yalnızca bir yüzdesine uygulamasını sağlar; bu aşamalı dağıtım için yararlıdır ve süresiz tereddüt için de son derece yararlıdır. ri toplu raporların ne sıklıkla gönderilmesi gerektiğini önerir. rua toplu rapor hedeflerini tutar. ruf hata raporu hedeflerini tutar. fo hata raporlarının ne zaman talep edildiğini hassaslaştırır. rf hata raporu formatlarını adlandırır. Bunların hiçbiri dekoratif değildir. Her etiket vardır çünkü bir yerlerde biri bir şey için bir alan talep edecek kadar belirsizlikten fena halde yanmıştır.
Raporlama, DMARC'ın bir geçti/kaldı damgasından çok daha fazlası haline geldiği yerdir. Genellikle rua'da listelenen adreslere gönderilen toplu raporlar, bir alan adı sahibinin internet genelinde kimin bu alan adını kullanarak posta gönderdiğini ve alıcıların bunu nasıl değerlendirdiğini görmesini sağlar. DMARC taslakları ve genel bakışı, raporlamanın dağıtımın merkezinde olduğunu açıkça belirtir, çünkü alan adı sahibinin hem yetkisiz kullanımı hem de hala uygun kimlik doğrulamasına ihtiyaç duyan meşru posta akışlarını keşfetmesini sağlar. Yalın sözlerle raporlar size alan adınızın posta ekolojisinin sağlıklı olup olmadığını veya "meşru" postalarınızın yarısının imzasız, uyumsuz veya herkesin bir başkasının belgelediğini varsaydığı unutulmuş üçüncü taraf platformlar tarafından başlatılıp başlatılmadığını söyler.
Bu son kategori kendi müze kanadını hak ediyor. Birçok kuruluş DMARC'ın tek bir anahtar olduğunu hayal eder. Kaydı yayınla. Güvende hisset. Bir slayta "e-posta korumalı" yaz. Gerçek dağıtım genellikle daha dağınıktır. Pazarlama platformu bir DKIM alan adıyla imzalar. CRM başka bir yol kullanır. Biletleme yazılımı kimsenin hatırlamadığı bir alt alan adından gönderir. Finans faturaları kurulum kılavuzu tehlikeli bir güven tonunda yazılmış bir satıcı tarafından yönetilen bir aktarıcıdan geçer. Biri görünürlük için p=none ekler, yaptırıma kademeli bir geçiş vaat eder ve ardından politika kimsenin harekete geçmeyi düşünmediği bir diplomatik nota gibi on sekiz ay boyunca orada oturur. Bu arada kuruluş normalde misyon beyanları ve kötü seçilmiş ofis sanatı için ayrılan o ciddi kesinlikle "güçlü e-posta güvenlik duruşu" hakkında konuşmaya devam eder.
İşte bu yüzden gerçek bir DMARC denetleyicisi "kayıt bulundu"da durmamalıdır. Bir kayıt bulmak önemsizdir. Ciddi sorular daha keskindir. Tam olarak bir DMARC kaydı var mı? Sözdizimi geçerli mi? Politika anlamlı mı? Alan adı sonsuza kadar izleme modunda mı sıkışmış? Toplu raporlar yapılandırılmış mı? Hata raporları mantıklı bir şekilde yapılandırılmış mı? Katı uyum ayarları kasıtlı mı yoksa kazara mı? Harici rapor adresleri gerçekten yetkilendirilmiş mi? RFC 7489, _report._dmarc altında özel bir DNS kaydı kullanan harici hedef doğrulaması için bir mekanizma içerir; aksi takdirde alan adları alıcıları rıza olmadan üçüncü taraflara rapor püskürtmeye yönlendirebilirdi. Bu küçük tasarım tercihi size internet hakkında her şeyi anlatır: Raporlama adresinin bile bir izin yapısına ihtiyacı vardır çünkü bir yerlerde biri daha basit versiyonu kesinlikle kötüye kullanırdı.
DMARC'ın en açıklayıcı kısmı conformance (uygunluk) kelimesi olabilir. Kulağa sert, neredeyse dini gelir ama önemli bir şey söyler. DMARC yalnızca kimlik yapıtlarını yayınlamakla ilgili değildir. Bir iletinin bir alan adı sahibinin belirtilen kimlik doğrulama beklentilerine uyup uymadığına karar vermekle ilgilidir. Bu "bir yerlerde SPF'imiz var" veya "başlıkların bir köşesinde bir DKIM imzası var"dan daha güçlü bir iddiadır. Uygunluk, iletinin alıcı tarafından görülebilen alan adıyla gerçekten aynı hizada olup olmadığını sorar. Dağınık teknik kontrolleri politika yargısına dönüştürür. DMARC'ın kimlik avı savunmasında ve marka korumasında tam olarak bu yüzden önemli olmasının ve zayıf dağıtımların çok fazla gerçek direnç sağlamadan sahte bir dürüstlük hissi yaratmasının nedeni de budur.
Peki ciddi bir DMARC Kayıt Denetleyicisi ne öğretmelidir? Bir alan adının görünür kimlik olduğunu, DNS'in yayınlama katmanı olduğunu, SPF ve DKIM'in kimlik doğrulama bileşenleri olduğunu ve DMARC'ın bu bileşenlerin görünür gönderici kimliğine cevap vermesini sağlayan politika çerçevesi olduğunu öğretmelidir. p=none'ın yaptırım olmadığını, yinelenen DMARC kayıtlarının "ekstra titizlik" olmadığını, rapor adreslerinin önemli olduğunu, uyum ayarlarının davranışı değiştirdiğini ve e-posta kimlik doğrulamasının DNS'teki küçük dizelerin faturaların, şifre sıfırlamalarının, yasal bildirimlerin ve yönetici postalarının teslim edilip edilmeyeceğini, karantinaya alınıp alınmayacağını veya atılıp atılmayacağını sessizce belirleyebildiği yetişkin teknik disiplinlerden biri olduğunu öğretmelidir.
Sonuçta DMARC'ın dikkatle kontrol edilmeye değer olmasının nedeni budur. Kısa bir DNS kaydının kurumsal ciddiyeti bir sayfalık politika retoriğinden daha dürüstçe ifade edebildiği birkaç yerden biridir. Alan adı ya eyleme geçirilebilir raporlama ve savunulabilir uyum ile tutarlı bir kimlik doğrulama politikası yayınlar ya da yayınlamaz. DNS bu açıdan harika bir şekilde duygusuzdur. Niyete göre not vermez. Ekibin "gerçekten gelecek çeyrekte e-posta güvenliğini sıkılaştırmalıyız" deme sıklığını umursamaz. Yalnızca var olan kayda hizmet eder.