DMARC'ı p=none'dan reject'e Taşımak: Meşru Postayı Düşürmeden Kademeli Geçiş Runbook'u
p=none bir bitiş çizgisi değil, dinleme modudur. Enforcement'a geçerken kendi faturalarını, şifre-sıfırlama ve pazarlama postalarını karantinaya yollamamak için agregat raporlarla yürütülen, pct kademelemesiyle kontrollü ve geri alınabilir bir DMARC geçiş planı.
EvilMail Team18 Temmuz 202612 dk okuma
Alan adınızda aylardır v=DMARC1; p=none yayında. Panelde yeşil bir tik var, "DMARC kurulu" diyorsunuz, raporlara kimse bakmıyor. Sorun şu: p=none hiçbir şeyi engellemez. Tek işi telemetri toplamaktır. Domain'iniz spoof'a sonuna kadar açık, çünkü hiçbir alıcı sunucu sizin adınıza atılan sahte postayı reddetmiyor. Ama panikleyip bir gecede p=reject'e geçen daha da beteridir: forwarding, mailing list ve üçüncü-parti SaaS gönderimlerini kör noktada bırakıp kendi fatura, şifre-sıfırlama ve newsletter postalarını karantinaya, hatta 550'ye yollar.
DMARC geçişi bir "politika değişikliği" değildir. RUA raporlarıyla yürütülen, ölçüme dayalı bir kaynak-envanteri operasyonudur. Aşağıdaki runbook, agregat raporla yürütülen, pct= kademelemesiyle kontrollü ve her adımı geri alınabilir bir geçiş sunar. Hedef net: sıfır meşru kayıp.
DMARC gerçekte neyi kontrol eder: alignment, pass değil
Kafa karışıklığı burada başlar. "SPF pass verdi, DKIM pass verdi, o zaman DMARC de geçer" — hayır. DMARC, SPF veya DKIM'in ayrı ayrı pass vermesiyle ilgilenmez. Kullanıcının gördüğü
SPF alignment: MAIL FROM (RFC5321 envelope sender) domain'i, header From domain'iyle hizalı mı?
DKIM alignment: imzanın d= domain'i, header From domain'iyle hizalı mı?
Kural sade: DMARC pass = (SPF pass VE aspf hizalı) VEYA (DKIM pass VE adkim hizalı). Biri yeter. Bu "veya" ilişkisi, enforcement'ta hayatınızı kurtaran şeydir — birazdan forwarding bölümünde göreceğiz.
relaxed (varsayılan, adkim=r/aspf=r) organizational domain eşleşmesine izin verir: mail.evilmail.pro ile evilmail.pro hizalı sayılır. strict (adkim=s/aspf=s) tam eşleşme ister. Çoğu gerçek altyapı subdomain'den gönderdiği için relaxed ile başlayın; strict'e ancak envanteri tam çıkardıktan sonra geçin.
İki klasik vaka bu bölümün neden kritik olduğunu gösterir:
"SPF pass ama DMARC fail": Bir SaaS sağlayıcı kendi MAIL FROM domain'iyle gönderir, SPF onların domain'inde pass verir ama sizin header From'unuzla hizalı değildir. SPF yeşil, DMARC kırmızı.
"Forwarding SPF'i kırar ama DKIM hizalı kalır": İleten sunucu envelope sender'ı değiştirir, SPF alignment çöker — ama gövdeye dokunmadıysa DKIM imzası ayakta kalır ve DMARC yine geçer.
RUA okumadan enforcement yapmamanızın teknik temeli tam olarak budur: hangi kaynağın hangi eksenden geçtiğini bilmeden yüzde artıramazsınız.
Agregat (RUA) raporlarını okumak: kaynak envanterini çıkar
Envanter çıkarmadan önce raporları toplayacak adresi kurun. Başlangıç kaydınız şöyle görünür:
Alıcı sunucular her gün, domain'inizden gördükleri postanın gzip'li XML özetini rua adresine yollar. Ham XML'i doğrudan bir mailbox'ta okumaya kalkışmayın — bir domain birkaç günde yüzlerce rapor üretir. Ayrı bir mailbox açın ve bir agregatöre bağlayın: Postmark DMARC (ücretsiz), Dmarcian, Valimail veya URIports iş görür. Bunlar XML'i sizin için IP/kaynak bazında tabloya çevirir.
1.Sizin ve hizalı geçen kaynaklar — kendi MTA'nız, Google Workspace, doğru kurulmuş ESP'niz. Dokunmayın.
2.Sizin ama hizalanamayan kaynaklar — fatura sistemi, CRM, bir SaaS webhook gönderici. policy_evaluated'de dkim/spf fail görünür ama header_from sizin domain'iniz. Enforcement'ta kanayacak meşru postalar tam olarak bunlardır. Görev: her birini düzeltmek.
3.Size ait olmayan kaynaklar — tanımadığınız IP'lerden sizin From'unuzla gelen postalar. Spoof/spam. p=reject bunları öldürecek; asıl amacınız bu.
Eşik: en az 2-4 hafta veri toplayın. Fatura, bordro ve aylık newsletter gibi düşük frekanslı akışları kaçırmamak için bir tam aylık döngüyü kapsayacak kadar bekleyin. Haftada bir çalışan bir sistemi ilk haftada göremezsiniz — ve tam da onu karantinaya yollarsınız.
pct= kaldıracı: yanlış anlaşılan ama en güvenli fren
pct= etiketi neredeyse herkesin yanlış anladığı bir mekanizmadır. pct=N, politikayı gönderilen mesajların yalnızca %N'ine uygular. Kalan %(100−N) bir alt kademe politikaya düşer: reject için quarantine, quarantine için none.
Yani p=reject; pct=10 aslında mesajların %10'una reject, %90'ına quarantine uygular. Bu "en riskli %10'u seç" demek değildir — alıcı sunucu rastgele örnekler. Böylece bir sorunu tüm trafiği düşürmeden, küçük bir dilimde canlı gözlemlersiniz.
Bir uyarı: 2023'ten beri bazı büyük alıcılar (Google dahil) pct'yi tutarsız uygular ya da görmezden gelebilir. Bu yüzden pcttek güvenlik ağınız değildir — RUA teşhisiyle birlikte çalışır. pct frendir, RUA gösterge paneli. İkisi olmadan direksiyona geçmeyin.
Hafta 0 — p=none + rua kaydını yayınla. TTL'i 300 sn tut ki her adımı dakikalar içinde geri alabilesin. Sadece dinle.
Hafta 2-3 — Kaynakları düzelt. Eksik DKIM imzalarını ekle (her gönderici için ayrı selector). Üçüncü-parti SaaS gönderenlere kendi domain'inin altında delege bir subdomain'le DKIM ver (mg.evilmail.pro gibi). SPF include'larını temizle — 10 DNS lookup limitini aşarsan tüm SPF permerror'a düşer ve fail sayılır.
Hafta 4 — p=quarantine; pct=25. RUA'yı 3-7 gün izle. Kova 2'de (senin ama hizalanamayan) yeni meşru kaynak var mı? Temizse pct=50, sonra pct=100.
Hafta 6-8 — p=reject; pct=25 → 50 → 100. Aynı gate, aynı disiplin.
sp= (subdomain policy) etiketini atlama. Ana domain p=reject olsa bile, sp= ayarlı değilse subdomain'ler ana politikayı miras alır. Hiçbir subdomain'den posta göndermiyorsan sp=reject'i erkenden koy — bedava güvenlik. fo=1, SPF veya DKIM'den herhangi biri hizalanamazsa failure raporu üretir (fo=0 yalnızca ikisi de fail ederse; fo=d/fo=s DKIM/SPF'e özel).
Forwarding, mailing list ve SRS/ARC: enforcement'ın gerçek katili
Enforcement'a geçince en çok kan burada akar. İki mekanizma DMARC'ı kırar:
Forwarding: İleten sunucu MAIL FROM'u kendi domain'iyle değiştirir → SPF alignment çöker.
Mailing list: Liste yazılımı Subject'e [liste] ekler veya gövdeye footer koyar → DKIM imzası bozulur.
İkisi aynı anda kırılırsa DMARC fail eder ve p=reject altında meşru postan 550 yer. Kurtaran üç mekanizma:
Hizalı DKIM'in hayatta kalması: Forwarder gövdeye dokunmadıysa DKIM ayakta kalır ve tek başına DMARC'ı geçirir. Bu yüzden tüm gönderenlerde DKIM zorunlu — forwarding'de yalnız SPF'e güvenmek intihardır.
ARC (Authenticated Received Chain): Güvenilir aracı (Google Groups gibi), gövdeyi değiştirse bile orijinal auth sonucunu ARC-Seal, ARC-Message-Signature ve ARC-Authentication-Results başlıklarıyla zincire taşır. Son alıcı bu zincire güvenirse DMARC fail'ini affeder.
SRS (Sender Rewriting Scheme): Gönderen tarafta MAIL FROM'u yeniden yazarak forwarding sonrası SPF'i onarır.
Pratik tavsiye: kendi forwarding'inde SRS + ARC imzalama kullan. Mailing list için üyenin From'unu rewrite eden listeler (Mailman'in from_is_list ayarı gibi) sorunu zaten çözer. Temp-mail ve relay bağlamında — evilmail'in tam oturduğu yer — relay katmanının ARC imzalaması, aracıdan geçen postanın son alıcıda DMARC'ı geçmesi için gereklidir.
DNS kayıtları ve doğrulama komutları
Kaydı yayınladıktan sonra göz kararı güvenme, doğrula:
bash
# DMARC kaydını oku — TEK bir TXT dönmeli
dig +short TXT _dmarc.evilmail.pro
# SPF kaydını gör (10 lookup limitine dikkat)
dig +short TXT evilmail.pro | grep spf
# Uçtan uca test: gönder, sonra Gmail'de "Show original"
swaks --to [email protected] --from [email protected] \
--server smtp.evilmail.pro
Gmail'de "Show original" başlığında üçünü de görmelisin: DMARC: PASS, SPF: PASS (alignment), DKIM: PASS. SPF ya da DKIM tek başına PASS ama DMARC FAIL görüyorsan sorun alignment'tadır — header_from ile doğrulanan domain hizalı değildir.
Alan-dışı rua kullanıyorsan (raporları başka bir domain'e yolluyorsan, çoğu agregatör böyle çalışır) o domain'in senin adına rapor almayı onaylayan bir TXT kaydı yayınlaması gerekir, yoksa raporlar hiç gelmez:
dns
evilmail.pro._report._dmarc.raporlayici.com. IN TXT "v=DMARC1"
Yaygın syntax hataları: _dmarc yerine yanlış konum, aynı isimde birden fazla TXT kaydı (DMARC'ı geçersiz kılar) ve yukarıdaki external-domain onayının unutulması.
Yayına geçmeden önce hızlı checklist
RUA'da en az 4 hafta veri toplandı ve aylık döngüler (fatura, bordro, newsletter) kapsandı mı?
RUA'daki tüm meşru kaynaklar hizalı geçiyor mu — kova 2 boşaldı mı?
DKIM her gönderende açık mı (kendi MTA + tüm SaaS/ESP)?
SPF 10 DNS lookup altında mı, permerror yok mu?
sp= ayarlı mı, subdomain akışları biliniyor mu?
TTL=300s — her adımı dakikalar içinde geri alabiliyor musun?
Forwarding'de ARC imzalama + SRS var mı?
MTA-STS + TLS-RPT (_mta-sts ve _smtp._tls TXT) ile taşıma katmanını da kilitledin mi? BIMI ise ancak quarantine/reject enforcement + VMC ile mümkün — sıralama bu.
