DMARC’ta p=none’dan p=reject’e Geçiş: Rapor Okuma ve Adımlar

DMARC kaydını p=none ile yayımlamak beş dakikalık iştir. Asıl iş, ay sonu faturası, CRM bildirimi ya da yazıcıdan taranan belge kaybolmadan p=reject seviyesine çıkmaktır. Bu rehber aggregate raporların nasıl okunacağını, gönderim kaynaklarının nasıl hizalanacağını ve politikanın hangi ölçüme bakılarak ilerletileceğini örnek DNS kayıtlarıyla anlatıyor.

DMARC hizalaması nasıl çalışır

DMARC (RFC 7489) yeni bir kimlik doğrulama yöntemi getirmez. SPF ve DKIM sonuçlarını kullanıcının gördüğü From başlığındaki alan adına bağlar. İletinin DMARC’tan geçmesi için iki koşuldan biri yeterlidir:

• SPF hizalaması: SPF, zarf göndericisi (RFC5321.MailFrom, başlıklarda Return-Path) için pass verir ve bu alan adı From alan adıyla hizalıdır.
• DKIM hizalaması: Geçerli bir DKIM imzasının d= değeri From alan adıyla hizalıdır.

Hizalama modunu aspf ve adkim etiketleri belirler. Varsayılan relaxed (r) modda organizasyonel alan adının eşleşmesi yeter: From adresi fatura@example.com iken bounce.example.com ile yapılan SPF doğrulaması hizalı sayılır. Strict (s) modda tam eşleşme gerekir. Geçiş boyunca relaxed modda kalın; alt alan adı kullanan servisleri hizalamak çok daha kolay olur.

Sahada en sık karıştırılan konu şu: SPF’in pass olması DMARC için yetmez. Pazarlama servislerinin çoğu iletiyi kendi bounce alan adıyla gönderir; SPF geçer ama hizalı olmadığı için DMARC hesabına yazılmaz. Raporlarda “SPF pass, DMARC fail” satırlarını görüyorsanız sebep neredeyse her zaman budur.

Aggregate raporların okunması

Raporlar rua etiketindeki adrese, alıcı sistemlerden genellikle günde bir kez, sıkıştırılmış XML olarak gelir. Başlangıç kaydı şöyle olabilir:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-rapor@example.com; adkim=r; aspf=r"

Raporları başka bir alan adındaki adrese, örneğin bir rapor analiz servisine gönderiyorsanız RFC 7489’daki harici hedef doğrulaması devreye girer: alıcı tarafta example.com._report._dmarc.rapor-servisi.example.net adında, v=DMARC1 içeren bir TXT kaydı olmalıdır. Bu kayıt yoksa raporlayıcılar raporu hiç göndermez. Rapor kutusu boş kalıyorsa ilk bakılacak yer burasıdır. Hacim yüksekse XML’i elle okumayın, bir ayrıştırıcı veya analiz servisi kullanın; ama yorumlama mantığını ekip mutlaka bilmeli.

Her record bloğu bir kaynak IP ve sonuç kombinasyonudur. Okurken şu alanlara bakılır:

XML alanı	Ne söyler
source_ip, count	Gönderen IP ve bu kombinasyondaki ileti sayısı
policy_evaluated	DMARC açısından hizalı DKIM/SPF sonucu ve uygulanan işlem
header_from	From başlığındaki alan adı
auth_results/dkim	İmzalayan d= alanı, selector ve ham sonuç
auth_results/spf	SPF’in doğrulandığı alan adı ve ham sonuç

Teşhisin anahtarı policy_evaluated ile auth_results arasındaki farktır. auth_results içinde DKIM pass görünüp d= değeri servis-saglayici.example.net ise imza geçerlidir, ama hizalı değildir. Kaynak IP’leri ters DNS ve sahiplik bilgisiyle gruplayın. Tek tek IP kovalamayın. Sorulacak soru “hangi servis?”.

Meşru gönderim kaynaklarının envanteri

Raporlar alan adınız adına kimin gönderim yaptığını gösterir; o sistemin kime ait olduğunu söylemez. Envanteri iki yönden çıkarın: raporlardaki kaynaklardan geriye, birimlerle yapılan görüşmelerden ileriye. Muhasebe, İK, pazarlama, satış ve üretime tek bir soru sorulur: “Alan adımızla müşteriye veya tedarikçiye otomatik e-posta gönderen bir sisteminiz var mı?”

Envanterde en sık atlanan kaynaklar:

• ERP veya e-fatura entegratörünün bildirim e-postaları
• CRM ve pazarlama otomasyonu platformları
• Yardım masası ve bilet sistemleri
• Çok fonksiyonlu yazıcıların “taradığım belgeyi e-postayla gönder” özelliği ve şirket içi SMTP relay’leri
• Web sitesi iletişim formları, e-ticaret ve İK aday takip sistemleri
• Ay sonu, çeyrek sonu veya yıllık çalışan bordro ve hesap ekstresi gönderimleri

Her kaynak için sahip birim, gönderen adresler, kullanılan alan adı, SPF ve DKIM hizalama durumu ve yapılacak işlem tabloya yazılır. Sahibi bulunamayan kaynak geçişi durduran bir engel sayılmaz. O, ayrıca incelenmesi gereken bir kurumsal siber güvenlik bulgusudur; kimsenin bilmediği bir sunucu alan adınızla e-posta atıyor demektir.

Üçüncü taraf servislerde SPF ve DKIM hizalaması

Her serviste sıra aynıdır: önce DKIM’i kendi alan adınızla imzalatın, sonra mümkünse özel Return-Path ile SPF hizalamasını kurun. DKIM önce gelir, çünkü yönlendirmede bozulmaz ve SPF’in 10 DNS sorgu sınırına yük bindirmez. Servislerin çoğu, sizin alan adınızda yayımlanacak CNAME veya TXT kayıtlarıyla sizin adınıza imza atmayı destekler:

s1._domainkey.example.com.     CNAME  s1.dkim.servis-saglayici.example.net.
bounce.example.com.            CNAME  bounce.servis-saglayici.example.net.

Servis yalnızca kendi alan adıyla imzalıyor ve özel Return-Path desteklemiyorsa iki yol kalır: o servisi ayrı bir alt alan adından (örneğin bildirim.example.com) göndermek ya da servisi değiştirmek. Yeni servisi SPF’e eklemeden önce sorgu bütçesine bakın; ayrıntılar SPF 10 DNS sorgu limiti ve permerror çözümü rehberinde.

Şirket içi uygulamalar ve yazıcılarda en temiz yol, cihazları doğrudan internete göndermek yerine kimliği doğrulanmış bir relay üzerinden geçirmektir; Microsoft 365 kullanıyorsanız Exchange Online’a bağlayıcı ile. DKIM imzası böylece merkezde eklenir. Yazıcı yazıcı DNS kaydı açmakla uğraşmazsınız.

none, quarantine, reject geçiş planı

Aşamalar takvime göre değil, ölçüme göre ilerler. Bir sonraki aşamaya geçmeden önce raporlarda DMARC’tan kalan ve meşru olduğu bilinen hacim sıfırlanmış olmalıdır.

Aşama	Örnek kayıt	İlerleme kriteri
1. İzleme	p=none	Tüm meşru kaynaklar envanterde ve hizalı
2. Kısmi karantina	p=quarantine; pct=25	Kullanıcı şikâyeti yok, başarısız trafik yalnız sahtecilik
3. Tam karantina	p=quarantine	Seyrek çalışan kaynaklar da en az bir döngü gözlendi
4. Kısmi reddetme	p=reject; pct=25	Karantinaya düşen meşru ileti bildirimi yok
5. Tam reddetme	p=reject	Sürekli izleme düzenine geçildi

pct etiketi, politikanın DMARC’tan kalan iletilerin yalnızca belirtilen oranına uygulanmasını ister; kalanına bir alt politika uygulanır (quarantine için none, reject için quarantine). Alıcıların pct desteği tutarlı değildir. DMARC’ın güncellenmiş sürümü üzerindeki IETF çalışmasında (DMARCbis) pct’nin yerine t (test) etiketinin getirildiğini de hesaba katın. pct’yi güvenlik ağı sanmayın; kademeli gözlem aracı olarak kullanın ve her aşamada kısa kalın.

Son kayıt şöyle olabilir:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-rapor@example.com; adkim=r; aspf=r"

Yayımladıktan sonra doğrulayın:

dig +short TXT _dmarc.example.com
Resolve-DnsName -Name _dmarc.example.com -Type TXT

Komut iki satır dönüyorsa sorun var. Aynı isimde birden fazla DMARC kaydı olduğunda alıcılar politikayı yok sayar; sahada bunu en çok, DNS panelinde yeni kayıt eklenip eskisi silinmeyi unutulduğunda görürüz.

Alt alan adları ve kullanılmayan alan adları

sp etiketi yoksa alt alan adları ana politikayı devralır. Kendi _dmarc kaydı olan alt alan adı ise o kaydı kullanır. Geçişten önce _dmarc.* kayıtlarının envanterini çıkarın. Pazarlamaya ayrılmış bir alt alan adını ana alan adından yavaş ilerletmeniz gerekiyorsa o alt alan adına ayrı kayıt yazın; ana alan adında sp=none bırakmayın. sp=none, saldırganın rastgele alt alan adlarıyla sahtecilik yapmasına kapıyı açık bırakır.

E-posta göndermeyen alan adları (eski marka adları, yazım varyasyonları, savunma amaçlı tescilli alan adları) doğrudan en sıkı ayarla kapatılabilir. Kaybedilecek meşru trafik yok:

example.org.          IN  TXT  "v=spf1 -all"
_dmarc.example.org.   IN  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-rapor@example.com"
example.org.          IN  MX   0 .

Son satır RFC 7505’teki “null MX” kaydıdır ve alan adının e-posta kabul etmediğini bildirir. Bu alan adlarından gelen raporlar, adınıza yapılan sahtecilik denemelerini temiz biçimde gösterir; orada görünen her gönderim sahtedir.

Geçiş sonrası izleme

p=reject bitiş çizgisi değildir; değişiklik yönetimine bağlanması gereken bir durumdur. Yeni bir SaaS servisi alınırken e-posta kimlik doğrulaması kontrolü satın alma sürecine eklenmezse, sorun ilk olarak müşteriye ulaşmayan faturalar şeklinde ortaya çıkar. Ve genellikle cuma akşamı. Düzenli işleyen bir yapı için:

• Haftalık rapor özeti: yeni kaynak IP’ler, hizalanmamış meşru hacim, sahtecilik denemeleri
• Satın alma ve yeni uygulama onayı sürecinde “alan adımızla e-posta gönderecek mi?” sorusu
• DKIM anahtarlarının periyodik rotasyonu ve kullanılmayan selector’ların kaldırılması
• DNS değişikliklerinin kayıt altına alınması; DMARC, SPF ve DKIM kayıtlarının sahibinin belli olması
• Kullanıcıların “müşteriye e-posta gitmedi” bildirimlerinin hızlıca rapor verisiyle karşılaştırılması

DMARC, From alan adınızın birebir taklidini engeller; benzer görünen alan adlarıyla yapılan dolandırıcılığı engellemez. O boşluğu kapatan süreç kontrolleri BEC ve sahte fatura dolandırıcılığı rehberinde, kullanıcı tarafındaki savunma katmanları kurumsal e-postada phishing riskini azaltmak yazısında. Protokolün resmi tanımı için başvuru kaynağı RFC 7489.

Alan adı envanteri geniş, gönderim kaynakları dağınık yapılarda rapor analizi ve servis hizalaması e-posta güvenliği ve kimlik avı koruması hizmeti kapsamında birlikte yürütülebilir.

Sık sorulan sorular

p=reject’e geçmeden önce ne kadar rapor toplanmalı?

Takvim değil, kapsam belirler. Ay sonu fatura gönderimi, çeyrek sonu ekstreler, dönemsel kampanyalar gibi seyrek çalışan kaynakların raporda en az bir kez görünmesi gerekir. Çoğu kurumda bu bir ila üç aylık bir tam iş döngüsüne denk gelir. Ölçüt şu: son iki haftada açıklanamayan meşru kaynak kalmamış olmalı.

SPF geçiyor ama DMARC başarısız, neden?

SPF, zarf göndericisi (Return-Path) alan adı için geçmiştir ama bu alan adı From başlığındakiyle hizalı değildir. Üçüncü taraf servislerin çoğu kendi bounce alan adını kullanır. Çözüm iki yoldan biri: servisi kendi alt alan adınızla özel Return-Path kullanacak şekilde ayarlamak ya da kendi alan adınızla DKIM imzalatmak.

Yönlendirilen (forward) e-postalar p=reject sonrası kaybolur mu?

Yönlendirmede SPF büyük olasılıkla bozulur. İleti değiştirilmediyse DKIM imzası geçerli kalır ve DMARC DKIM üzerinden geçer. Konu satırına etiket veya altbilgi ekleyen e-posta listeleri DKIM’i bozabilir; o noktada alıcının ARC desteği belirleyicidir. Bu yüzden her kaynakta hizalı DKIM şart tutulmalı.

Ana alan adında reject varken alt alan adları korunur mu?

sp etiketi yoksa alt alan adları ana alan adının p politikasını devralır. Alt alan adının kendi _dmarc kaydı varsa o kayıt geçerlidir. Farklı politika gereken alt alan adları için sp etiketini açıkça yazın ve alt alan adlarındaki _dmarc kayıtlarını envantere alın.