Bir terminal üç alan adının DMARC kayıtlarını listeler; biri yeşil p=reject, ikisi kırmızı p=none ile işaretlenmiş

read receipts

Bir Şirketin DMARC Politikasını On Saniyede Okumak (ve Bunun Size Söylemediği Şeyler)

Alan sahibinin sahte postaya ne yapılmasını istediğini belirten satır herkese açıktır ve bir sorgu uzağındadır. Bu belirtilen bir tercih — spam filtresi değildir ve gelen kutunuz hakkında bir söz değildir.

·5 dk

Bir DNS sorgusu, bir şirketin kendi adına gönderilen sahte postaya dünyanın posta sunucularının ne yapmasını istediğini söyler. Kayıt herkese açıktır ve komut tek bir satırdır: dig +short TXT _dmarc.example.com. Geri dönen şey ayarlardan oluşan kısa bir dizedir ve içinde bir talimat vardır — p=none, p=quarantine veya p=reject — bu, o alan adını kullanan bir mesaj kimlik doğrulamada başarısız olduğunda alan sahibinin tercihini belirtir.

Mevcut spesifikasyon RFC 9989, Mayıs 2026'da bir IETF Standards Track belgesi olarak yayımlanmış ve eski RFC 7489'un yerini almıştır. Üç değeri neredeyse kısaca tanımlar:

  • p=none — "Alan Sahibi bir tercih ifadesi sunmaz."
  • p=quarantine — "Alan Sahibi, böyle postaları şüpheli olarak değerlendirir. Posta geçerli olabilir, ancak başarısızlık önemli bir endişe yaratır."
  • p=reject — "Alan Sahibi, tüm bu başarısızlıkları, alan adı adının kullanılmasının geçerli olmadığının açık bir göstergesi olarak değerlendirir."

Bu kelimeleri tekrar okuyun, çünkü DMARC hakkında çoğu açıklamadan daha zayıftırlar. Bir politika, gönderen tarafından yayımlanan ve alıcılar tarafından dikkate alınması için bir tercihtir. Alıcının yerine getirmekle yükümlü olduğu bir talimat değildir. RFC 9989 bunu tek bir cümlede söyler: "Herhangi bir mesajın nihai işlenmesi her zaman yerel politikanın bir meselesidir ve Posta Alıcısının takdirlerine bırakılmıştır." Aynı bölüm sonucun her iki yarısını da ekler — alıcılar "DMARC doğrulamasını geçen bir mesajı reddedebilir veya karantinaya alabilir" ve "yayımlanmış bir 'reject' politikası nedeniyle yalnızca mesajları reddetmemelidirler," tam da DMARC'ın tanımlanamadığı şekillerde gönderilen meşru posta ve posta listeleri için imha edilmez, böylece.

p=none aslında ne itiraf eder? Genellikle suçlandığından daha az. Spesifikasyonun kendi terimleri içinde Monitoring Mode'dur: alan sahibi toplam raporlar toplayıp "DMARC doğrulamada başarısız olan mesajlar için işleme tercihini ifade etmez" ve DMARC dağıtan bir alıcı "yine de" alan adının kullanımını doğrulayabilir. Bunun yaptığı şey, alıcının sonundaki herhangi bir şeyi kapatmak değildir. Sağlayıcınızın spam filtrelemesi, itibar puanlaması, URL kontrolleri ve ek analizi, göndericinin yayımladığı şeyden bağımsız olarak çalışan ayrı makineleridir. p=none alanına ulaşan sahte bir mesaj, kayıt tarafından gelen kutunuza taşınmaz; basitçe alıcıya belirtilen bir tercih olmaksızın iletilir ve alıcı karar verir.

Yanlış anlama diğer tarafı öbür yöne gider. DMARC, bir kimlik avı e-postasının tehlikeli bölümünü okumuyor. Kendi spesifikasyonu, kasıtlı olarak kapsam dışında bırakılan şeyleri listeler ve "content analysis" bu kelimelerde o listede yer alır. Ayrıca DMARC'ın "görsel olarak benzer alan adlarının kullanımını veya RFC5322.From insan tarafından okunabilir görüntü adının kötüye kullanımını ele almadığını" belirtir — çoğu marka kimliğe bürünme postasını taşıyan iki numara. Ve bir geçişin değeri hakkında: "bir DMARC geçişi tek başına, alıcının gelen kutusuna teslim edilmenin güvenli veya istenebilir olacağını garanti etmez." Düzgün şekilde kimlik doğrulaması yapılan bir mesaj bir ıskarta alandan temiz bir şekilde DMARC'ı geçer. DMARC, From: başlığında alan adını kullanmaya kimin yetkili olduğunu yanıtlar. Başka hiçbir şey değil.

2024 toplu gönderici kurallarının düzenli olarak yanlış raporlandığı, bu makalenin ilk versiyonu de dahil olmak üzere buradadır. Google'ın gönderici yönergeleri, Gmail hesaplarına günde 5.000 veya daha fazla mesaj gönderenleri "Gönderme alan adınız için DMARC e-posta kimlik doğrulamasını ayarlayın" şartını getirir ve ardından, aynı nefeste: "DMARC uygulaması politikanız none'a ayarlanabilir." Yahoo'nun kendi Sender Hub'ı, Google'ı kopyaladığı varsayılmak yerine ayrı ayrı okunması gerekir, gereksinimi "En azından p=none içeren geçerli bir DMARC politikası yayımlayın - DMARC geçmelidir" şeklinde belirtir ve hiçbir sayısal hacim eşiği yayımlamaz. Her iki gereksinimler kümesi de Şubat 2024'ten itibaren yürürlüğe girmiştir. Hiçbiri kimseyi p=none'dan uzaklaştırmaz. Her ikisinin gerçekten uyguladığı şey, hizalanmış kimlik doğrulamadır: Google, "göndericinin From: başlığındaki alan adının SPF alanı veya DKIM alanı ile hizalanması gerektiğini" gerektirir ve Yahoo, rahat hizalamayı kabul edilebilir olarak söyler. Hizalama, önem değildir, kapıdır.

Bu, alanların monitoring'de oturması için gerçek nedeni bırakır ve bu operasyonel değil, korkakça değildir. quarantine veya reject'e taşınmak, önce kendi adınıza posta gönderen her hizmeti — bordro, bilet işlemleri, pazarlama, belgelenmemiş bir destek masası — bulmak ve her birini hizalanacak şekilde kimlik doğrultmak anlamına gelir. Standart kendisi bu yavaşlığı yapan tehlikeleri kabul eder: üçüncü taraf göndericiler DMARC tarafından sunulan veya hariç tutulmaz, iletme ve posta listeleri hiçbir gönderici kusuru olmaksızın hizalamayı bozabilir ve spesifikasyon alıcıları tam da bu başarısızlık modları için RFC 7960'a işaret eder. p=none yayımlayan ve raporlarını okuyan bir kuruluş, belirtilen sırada işi yapıyor. p=none yayımlayan ve raporları gözardı eden bir kuruluş değil. Dışarıdan, kayıt tek başına sizin ikisinin hangisine baktığınızı söyleyemez.

Terminal'e ihtiyacınız yok. Ücretsiz arama araçları — dmarcian'ın alan adı denetleyicisi, MXToolbox'ın DMARC denetimi — kaydı getir ve politikayı sizin için yazdır. Bunu bankanız, bordro sağlayıcınız, uçtuğunuz havayolu için yapın. Sadece cevabı ne olduğu için okuyun: alan sahibinin niyetinin bir beyanı, kendi başına bir karar verirken sağlayıcınızın yaptığı birçok girdiden biri, belirli bir sahte olma türü hakkında. On saniyede okuması gerçekten yararlı bir şeydir. O markayla ilgili olduğunu iddia eden sonraki mesajın güvenli olup olmadığı hakkında bir karar değildir.

Düzeltme, 20 Ekim 2026. Bu makalenin önceki bir versiyonu p=none'u, sahte uyarıları gelen kutusuna teslim etmek ve p=reject'i bir sahte mesajı bloke eden tek ayar olarak tanımladı, 2024 Google ve Yahoo toplu gönderici kurallarının gönderenleri p=none'dan uzaklaştırdığını söyledi ve enforcement figürü olarak kabaca üçte biri alınan bir rakam alıntıladı. Politika açıklamaları RFC 9989 karşısında düzeltilmiştir; hem Google hem de Yahoo aslında p=none'u kabul eder, yukarıda kendi belgelerinden alıntılanmıştır; ve uygulanma figürü kaldırılmıştır çünkü temel rapor kendi örneğini veya paydasını yayımlamaz. Makale, DMARC'ın incelemediği şeyleri de belirtir.

The weakest DMARC policy, and the one both Google and Yahoo accept from bulk senders under rules in force since February 2024

Kaynaklar

  1. RFC 9989 — Domain-based Message Authentication, Reporting, and Conformance (DMARC) — IETF, Standards Track, May 2026; obsoletes RFC 7489. Policy values §4.7, Monitoring Mode §3.2.12, out-of-scope list §2.4, policy enforcement §5.4
  2. Google — Email sender guidelines — Requirements in force from 1 February 2024, including "Your DMARC enforcement policy can be set to none" and the 5,000-messages-a-day threshold (checked 20 October 2026)
  3. Yahoo Sender Hub — Best practices — Yahoo's own bulk-sender requirements: "Publish a valid DMARC policy with at least p=none"; no numeric volume threshold published (checked 20 October 2026)
  4. DMARC.org — Overview — Plain-language introduction to SPF, DKIM and identifier alignment
  5. dmarcian Domain Checker — Free lookup that fetches and reads a domain's DMARC record

← Tüm yazılar