DMARC ve alt alan adları: sp, np ve organizational domain üzerinden politika kalıtımını doğru kurmak
example.com'da p=reject yayında olsa bile billing.example.com veya hiç var olmayan secure-login.example.com hâlâ sahtelenebilir. DMARC alıcıları alt alandan köke "tırmanmaz"; birebir sorgular, bulamazsa tek atlayışta organizational domain'e gider. sp ve np etiketlerinin gerçek semantiğini, öncelik sırasını ve hizalamayı üretim davranışına dayandıran mühendis rehberi.
EvilMail Team20 Temmuz 202611 dk okuma
Sorun: p=reject var ama alt alanlar hâlâ sahtelenebiliyor
example.com bölgesinde _dmarc kaydı p=reject ile yayında. DKIM imzalı, SPF hizalı, raporlar temiz. Sonra muhasebe ekibine bir fatura kimlik avı düşüyor: gönderen billing.example.com, üstelik böyle bir alt alan hiç oluşturulmamış. Mesaj karantinaya bile takılmadan geçiyor. Bir hafta sonra ikinci dalga secure-login.example.com adından geliyor — yine geçiyor.
Kök alan sapasağlam korunurken bu nasıl mümkün? Çünkü alt alan politikası ayrı yönetilir ve ekip çoğunlukla ya bunu boş bırakır ya da yanlış yerde tanımlar. Kökteki p=reject, alt alanları otomatik olarak "aynı sertlikte" korumaz — koruma davranışı, alıcının hangi kaydı sorguladığına ve o kayıtta hangi etiketin bulunduğuna bağlıdır.
DMARC Alt Alan Politikası: sp ve np Etiketiyle Kalıtımı Yönetme — EvilMail Blog
Bu yazı üç somut soruyu cevaplar: (1) alıcı alt alan için gerçekte hangi DNS kaydını sorgular, (2)
sp
etiketi tam olarak ne zaman devreye girer, (3) hiç var olmayan alt alanları nasıl kapatırsın. Cevaplar RFC davranışına ve büyük alıcıların 2026'daki üretim pratiğine dayanıyor — kopyala-yapıştır kayıt seti değil, "neden böyle" mantığı.
Buradaki tek en yaygın yanılgı şu: "Alıcı a.b.example.com için bulamazsa b.example.com'a, oradan example.com'a doğru adım adım tırmanır." Klasik DMARC bunu yapmaz.
RFC 7489 §6.6.3'teki gerçek sıra şudur:
Alıcı önce başlıktaki RFC5322.From domain'i için birebir _dmarc.<from-domain> TXT kaydını sorgular. Kayıt varsa onu kullanır ve iş biter — org domain'e hiç bakılmaz.
Kayıt yoksa, alıcı Public Suffix List (PSL) üzerinden organizational domain'i belirler ve doğrudan _dmarc.<org-domain> TXT kaydını sorgular.
Aradaki katmanlar (_dmarc.b.example.com gibi) hiç sorgulanmaz. From a.b.example.com olsa bile alıcı yalnızca iki noktaya bakar: tam From domain'i ve org domain.
Yani newsletter.example.com'un kendi _dmarc kaydı yoksa, alıcı doğrudan example.com'un kaydına atlar ve orada bulduğu politikayı uygular. Ara seviye diye bir şey yoktur.
DMARCbis notu (2026): IETF taslağı draft-ietf-dmarc-dmarcbis, klasik org-domain sorgusunun yerine gerçek bir "tree walk" öneriyor — From'dan yukarı, en fazla beş etikete kadar adım adım tırmanan bir arama. Bazı alıcılar geçiş sürecinde, ama 2026 itibarıyla üretimdeki çoğu alıcı hâlâ RFC 7489 davranışında. Sonuç: kurulumunu klasik iki-noktalı aramayı varsayarak yap; tree walk yaygınlaştığında mevcut kayıtların zaten doğru sonucu verecek şekilde konumlanmış olmalı. np etiketi de resmî statüsünü DMARCbis ile kazanıyor.
sp etiketi tam olarak ne yapıyor
sp etiketi yalnızca organizational domain'in DMARC kaydında anlamlıdır ve yalnızca kendi `_dmarc` kaydı olmayan alt alanlara uygulanır. Öncelik sırası kafa karışıklığının kaynağı, o yüzden net koyalım:
Alt alanın kendi `_dmarc` kaydı varsa, `sp` tamamen yok sayılır._dmarc.mail.example.com altında zayıf bir p=none kaydı duruyorsa, kökteki sp=reject bu alt alan için hiçbir işe yaramaz. Alt alan kendi kaydını sonuna kadar kullanır.
`sp` tanımlı değilse, alt alanlar `p` değerini miras alır. Yani sp'nin varsayılanı p'dir. p=reject yazıp sp yazmazsan, kendi kaydı olmayan alt alanlar da reject alır.
`sp` tanımlıysa, `p`'den bağımsız çalışır. Kökü p=none ile raporlama modunda tutup alt alanları sp=reject ile sertleştirebilirsin — ya da tam tersi.
Buradaki en sinsi tuzak: köke p=reject yazıp "alt alanlar da otomatik korunuyor" varsaymak. Varsayım teknik olarak doğru olsa da, geçmişte birinin bir test için açtığı _dmarc.mail p=none kaydı bu korumayı sessizce deler. Kimse silmez, kimse fark etmez, mail.example.com aylarca korumasız kalır. Alt alan sızıntılarının bir numaralı sebebi tam olarak budur.
Organizational domain ve PSL: sınırı kim çiziyor
Org domain'i "kayıtlanabilir en üst seviye" olarak Public Suffix List belirler. example.com için org domain example.com'dur. Ama example.co.uk için org domain example.co.uk'tır, çünkü co.uk bir public suffix'tir — example.co.uk'nin org domain'i co.ukdeğildir.
Bu, sp kapsamını ve hizalamayı doğrudan etkiler. shop.example.co.uk'dan gelen bir mesaj için alıcı önce _dmarc.shop.example.co.uk'yı, bulamazsa _dmarc.example.co.uk'yı sorgular — asla _dmarc.co.uk'ya gitmez. PSL yanlış yorumlanırsa hizalama kontrolleri de yanlış hesaplanır.
Bir uyarı: PSL alıcılar tarafından cache'lenir ve farklı sağlayıcılar farklı sürümler taşıyabilir. Yeni kaydolmuş bir suffix (ör. yeni bir eTLD) bazı alıcılarda güncel, bazılarında eski olabilir. Standart ticari TLD'lerde bu bir sorun değil, ama egzotik bir suffix altındaysan davranış farkı yaşayabileceğini hesaba kat.
np ile var olmayan alt alanları kapatmak
sp ve p, alt alan gerçekten var olsun ya da olmasın, sorgu sonucuna göre çalışır. Ama saldırganların favori tekniği hiç oluşturmadığın alt alanları kullanmaktır: no-reply-2026.example.com, secure-login.example.com, account-verify.example.com. Bunlar için ayrı bir kaldıraç var: np (RFC 9091).
np, MX / A / AAAA kaydı olmayan — yani teknik olarak "var olmayan" — alt alanlara uygulanır. np yoksa, var olmayan alt alanlar sp'ye düşer; sp de yoksa p'ye düşer. Tam kapalı bir kurulum üçünü birlikte kullanır:
Bu üçlü hem var olan alt alanları (sp=reject) hem de var olmayanları (np=reject) kapatır. Destek gerçeği şu: Google, Microsoft ve Yahoo np'yi işler; daha küçük alıcıların desteği kısmi. Bu yüzden np bir ek katmandır, sp'nin yerine geçmez. np=reject yazdın diye sp'yi boş bırakma — np'yi anlamayan bir alıcı doğrudan sp'ye düşecektir.
Politika kalıtım matrisi: tek bakışta öncelik
Org domain kaydının p=reject; sp=quarantine; np=reject olduğunu varsayalım. Üç farklı From domain'i, üç farklı efektif politika alır:
İlk satır dersin tamamı: mail.example.com'un zayıf kendi kaydı, kökteki tüm sertliği geçersiz kılıyor. Kalıtım öncelik zincirini ezberle: alt alanın kendi kaydı > np > sp > p.
Hizalama ve alt alanlar: relaxed neden kritik
DMARC'in geçmesi için From domain ile ya DKIM d= domain'i ya da SPF envelope domain'i hizalı olmalı. Hizalama modu adkim (DKIM) ve aspf (SPF) etiketleriyle belirlenir; varsayılan ikisinde de r (relaxed).
Relaxed modda hizalama, aynı organizational domain içinde esnektir. newsletter.example.com'dan gönderirken DKIM imzası d=example.com taşıyorsa ya da SPF envelope'u org domain ile hizalıysa, DMARC geçer — alt alan ile kök arasındaki fark tolere edilir. Strict modda (adkim=s / aspf=s) birebir domain eşleşmesi şart; d=example.com, newsletter.example.com From'u için strict'te hizalamaz.
Pratik sonuç: alt alan gönderimi olan çoğu kurulum relaxed'te kalmalı. Mailchimp, SendGrid gibi ESP'lere alt alan delegasyonu yaptığında sağlayıcı çoğu zaman kendi imzalama/return-path domain'ini kullanır ve strict mod bu akışları kırar. Strict'i yalnızca tek domain'den gelen, uçtan uca kontrol ettiğin akışlar için sakla.
Doğru kayıt setini yayınlamak
Katmanlı gerçek bir kurulum şöyle görünür: org domain'de tam kapsamlı kayıt, farklı davranması gereken bir alt alan için özel kayıt ve ESP delegasyonu için yetki kaydı.
dns
; Org domain — tam kapsam, kendi kaydı olmayan alt alanları da örter
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=reject; np=reject; adkim=r; aspf=r; rua=mailto:[email protected]; fo=1"
; Gerçekten gönderen, izlenmesi gereken bir alt alan — bilinçli olarak daha gevşek
_dmarc.newsletter.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"
; Raporları harici bir DMARC servisine yollama yetkisi (aksi halde raporlar reddedilir)
example.com._report._dmarc.dmarc-vendor.net. IN TXT "v=DMARC1"
O son kayıt sık atlanır: raporları (rua/ruf) senin domain'inin dışındaki bir adrese yolluyorsan, alıcı hedef domain'de bir yetki kaydı arar. _report._dmarc kaydı yoksa büyük alıcılar raporu göndermeyi reddeder ve "neden rapor gelmiyor" diye günlerce ararsın.
Bir de TXT sınırı: tek bir string en fazla 255 karakter olabilir. Uzun rua listeleri veya çok etiketli kayıtlar bu sınırı aşabilir; o durumda değeri tırnak içinde birden fazla parçaya bölmen gerekir (DNS bunları birleştirir).
Test ve doğrulama
Yayından önce ve sonra birebir sorgularla davranışı doğrula:
_dmarc.<altalan> sorgusu NXDOMAIN dönüyorsa, o alt alanın kendi kaydı yoktur — yani sp/np/p kalıtımı devrededir. Bir TXT değeri dönüyorsa, o alt alan kendi kuralıyla oynuyor demektir ve kökteki sp'nin o alt alan için hiçbir hükmü yoktur. Alt alan sızıntısı avlarken ilk bakacağın yer burasıdır: her aktif alt alan için bu sorguyu koştur, beklenmedik p=none kayıtlarını temizle.
Agregat raporlar (rua) hangi alt alanların gerçekte trafik ürettiğini gösterir. Her <record> içindeki <row><policy_evaluated> ve <identifiers><header_from> alanları, hangi From domain'inin hangi sonucu aldığını söyler. Beklemediğin bir header_from görüyorsan ya yeni bir meşru gönderici çıkmıştır ya da bir sahtecilik denemesi kaydedilmiştir — ikisi de aksiyon gerektirir.
evilmail.pro tarafında geçici e-posta altyapımızın DMARC durumunu tam olarak böyle izliyoruz: her aktif alt alan için birebir _dmarc sorgusu, artı rua akışında header_from bazlı ayrıştırma. Sürpriz kayıt yok, sessiz sızıntı yok.
Son bir not pct üzerine: 2026'da fiilen kullanımdan kalkıyor ve DMARCbis onu tamamen kaldırıyor. Eski kayıtlarda pct= görebilirsin, ama yeni kurulumda kullanma — kısmi uygulama davranışı alıcılar arasında öngörülemez.
Dağıtımdan önce kontrol listesi
Org domain kaydında p, sp ve np üçünü de açıkça yaz — sp'nin p'ye default'lanmasına güvenme, niyetini kayda geçir.
Her aktif alt alan için dig +short TXT _dmarc.<altalan> koştur; beklenmedik p=none kayıtlarını bul ve sil (klasik sessiz sızıntı).
Alt alan gönderimin veya ESP delegasyonun varsa adkim/aspf'yi relaxed bırak; strict'i yalnızca uçtan uca kontrol ettiğin tek-domain akışları için kullan.
np'yi ek katman olarak konumlandır; küçük alıcılar desteklemez, sp'yi asla boş bırakma.
Org domain'in PSL'e göre doğru belirlendiğini teyit et (özellikle co.uk gibi çok seviyeli suffix'lerde).
Yeni kayıtlarda pct kullanma; eski kayıtlardan temizle.
Yayından bir hafta sonra rua raporlarında header_from bazında alt alan trafiğini gözden geçir, DMARCbis tree-walk geçişine karşı kayıtlarının konumunu doğrula.
