DMARC Hizalaması: SPF ve DKIM Alignment'ta Relaxed ile Strict Farkı
SPF pass, DKIM pass, ama DMARC hâlâ fail. Bu paradoksu çözerek DMARC'ın gerçekte neyi doğruladığını, organizational domain hizalamasının nasıl hesaplandığını ve relaxed ile strict kararının nerede sessizce teslimat kırdığını mühendislik detayıyla anlatıyoruz.
EvilMail Team18 Temmuz 202612 dk okuma
Postmaster kutusuna düşen ticket'ların en kafa karıştırıcısı şudur: "SPF de pass diyor, DKIM de pass diyor, ama Gmail mesajı reddediyor." Üstelik kullanıcı ekran görüntüsünde haklı. Ham başlığa bakınca satır aynen şöyle görünür:
İki mekanizma da pass. Yine de dmarc=fail. Paradoks tek cümlede çözülür: geçen SPF ve DKIM kimliği, kullanıcının gördüğü From: domain'iyle hizalı değil. SPF bounces.sendgrid.net için geçti, DKIM sendgrid.net için geçti, ama mesaj evilmail.pro
DMARC Alignment Rehberi: Relaxed ve Strict Farkı (SPF + DKIM) — EvilMail Blog
adına gönderiliyordu. DMARC'ın tek işi bu uyuşmazlığı yakalamaktır. Aşağıda önce hizalamanın mekaniğini, sonra
relaxed
ile
strict
kararının gerçekten nerede fark yarattığını sökeceğiz.
DMARC neyi doğrular: üç ayrı "kimlik"
Bir e-postada tek bir "gönderen" yoktur, üç tane vardır ve bunlar farklı katmanlarda yaşar:
RFC5321.MailFrom — SMTP zarfındaki MAIL FROM, yani Return-Path. Bounce'lar buraya döner. SPF bu domain'i doğrular.
RFC5322.From — mesaj başlığındaki From:, kullanıcının mail istemcisinde gördüğü tek şey. Hiçbir alt protokol bunu doğrulamaz.
Kritik nokta: ne SPF ne DKIM From: başlığına bakar. SPF zarfa bakar, DKIM imza domain'ine bakar. Saldırgan From: [email protected] yazıp mesajı kendi attacker.example domain'inden SPF ve DKIM ile kusursuz imzalayabilir — her ikisi de pass verir, çünkü kendi domain'i için gerçekten geçerlidirler.
DMARC'ın kattığı tek yeni şey budur: geçen kimliği From: başlığının domain'iyle karşılaştırmak. Buna identifier alignment (kimlik hizalaması) denir. DMARC sonucunun mantığı bir "VEYA" kapısıdır:
(SPF authenticated VE SPF aligned) VEYA (DKIM authenticated VE DKIM aligned) → DMARC pass.
Yani tek bir hizalı mekanizma yeterlidir. DKIM hizalıysa SPF'in hiç hizalanmaması sorun değildir. İkisi de hizalı değilse — yukarıdaki ticket'ta olduğu gibi — DMARC fail eder, From: domain'inin politikasına (p=reject) göre mesaj düşer.
Hizalama nasıl hesaplanır: organizational domain ve PSL
İki mod vardır ve her mekanizma için ayrı ayrı ayarlanır: adkim DKIM hizalamasını, aspf SPF hizalamasını kontrol eder. DMARC kaydında hiç yazmazsanız varsayılan `relaxed`'dir. Bunu bilmek önemli, çünkü çoğu operatör kaydına adkim/aspf koymaz ve farkında olmadan relaxed çalışır — ki genelde doğru olan da budur.
strict basittir: iki domain karakter karakter aynı olacak. mail.evilmail.pro ile evilmail.pro strict altında eşleşmez, çünkü string olarak farklıdırlar.
relaxed ise iki domain'in organizational domain'inin aynı olmasını ister. Organizational domain, Public Suffix List (PSL) kullanılarak bulunur; teknik adı eTLD+1'dir. mail.evilmail.pro → org domain evilmail.pro. em123.evilmail.pro → org domain yine evilmail.pro. İkisi de aynı eTLD+1'e indiği için relaxed altında hizalıdırlar.
PSL neden elle yapılamaz? Çünkü "son iki etiketi al" kuralı yanlıştır. foo.com.tr domain'inde com.tr bir public suffix'tir, dolayısıyla org domain foo.com.tr'dir, com.tr değil. co.uk, gov.tr, github.io gibi binlerce çok seviyeli suffix vardır. Bu yüzden hizalamayı naif string işlemiyle değil, güncel bir PSL kütüphanesiyle hesaplayın; alıcı taraf (Gmail, Outlook) zaten öyle yapar.
SPF alignment: relaxed vs strict ve ESP tuzağı
SPF hizalaması Return-Path domain'i ile From: domain'ini karşılaştırır. Bunu DKIM ile karıştırmak en sık yapılan kavramsal hatadır; SPF hizalaması imza domain'ine hiç bakmaz.
Kendi sunucun senaryosu kolaydır. From: [email protected], MAIL FROM: [email protected] → hem Return-Path hem From aynı kök domain. Her iki modda da hizalı.
ESP senaryosu işte burada iş değişir. SendGrid, Mailgun, Amazon SES gibi sağlayıcılar bounce yönetimi için kendi subdomain'lerini kullanır. CNAME delegasyonuyla Return-Path: [email protected] görürsünüz — ama From: hâlâ @evilmail.pro. Bu durumda:
aspf=r (relaxed) → em1234.evilmail.pro ve evilmail.pro aynı org domain → PASS.
Şu tuzağa dikkat: aspf=s açar ve CNAME'li ya da paylaşımlı bir ESP bounce domain'i kullanırsanız SPF hizalaması sessizce ölür. Teknik olarak DKIM tek başına DMARC'ı geçirebilir, ama SPF'ten gelen ikinci hizalı mekanizmanın güvenlik payını kaybedersiniz. Üstelik mesaj bir mail listesi ya da forwarder üzerinden geçtiğinde SPF zaten kırılır (Return-Path yeniden yazılır); o senaryoda tek dayanağınız DKIM hizalaması kalır. Strict SPF, marjı olması gerekenden dar bırakır.
DKIM alignment: relaxed vs strict ve subdomain imzalama
DKIM hizalaması DKIM-Signature başlığındaki d= ile From: domain'ini karşılaştırır. Selector (s=) hizalamaya girmez — s=s1024._domainkey olması hiçbir şey değiştirmez, yalnızca d= sayılır.
Bir mesajda birden fazla DKIM imzası olabilir ve DMARC hepsini dener; biri hem geçerli hem hizalıysa yeter. ESP'ler tipik olarak iki imza koyar: kendi domain'leri (d=sendgrid.net — asla hizalanmaz) ve CNAME delegasyonuyla sizin domain'iniz. Buradaki incelik: CNAME kurulumu size d=evilmail.pro mı yoksa d=em.evilmail.pro mı veriyor?
Delegasyon tam kök d=evilmail.pro veriyorsa strict de geçer.
Delegasyon d=em.evilmail.pro (subdomain) veriyorsa strict kırılır, relaxed geçer.
Bunu varsaymayın, doğrulayın. default._domainkey.evilmail.pro yerine ESP genelde s1._domainkey.evilmail.pro gibi bir selector CNAME'i kurdurur; imzanın d= değerini gerçek bir test mesajının başlığından okuyun.
Ayrıca aynı denetimde hizalamadan bağımsız iki şeye daha bakın: l= (body length) tag'i — varsa gövde tampering'e açık, kullanmayın — ve anahtar uzunluğu. 2026'da 1024-bit DKIM anahtarı zayıftır; 2048-bit tercih edin.
Karar: ne zaman relaxed, ne zaman strict
Doğru başlangıç noktası nettir: adkim=r; aspf=r. Kurumsal e-posta + ESP + subdomain kullanan operasyonların büyük çoğunluğu bunu ister ve zaten varsayılan budur.
strict'in tek gerçek kazancı, org domain altındaki subdomain'lerden gelen spoofing yüzeyini kapatmaktır. Saldırgan From: [email protected] yazamıyorsa ama From: [email protected] deneyebiliyorsa ve siz hiçbir subdomain'den meşru mail göndermiyorsanız, strict o kapıyı kapatır. Ama bunu ancak şu koşullar birlikte sağlanıyorsa savunabilirsiniz:
evilmail.pro'yu yalnızca kök domain'den gönderiyorsunuz.
Tek MTA / tek ESP var ve delegasyonu kök d=evilmail.pro veriyor.
Anlamlı forwarding trafiğiniz yok.
Subdomain gönderimi envanterlenmiş ve kilitli.
Bu koşullardan biri bile sağlanmıyorsa strict, güvenlik değil, sessiz teslimat kaybı satın alır. Pratik reçete tek büyük strict yerine domain başına politikadır: kök domain'de sıkı olun (p=reject; sp=reject), farklı ürün subdomain'lerine kendi DMARC kaydını ve kendi hizalama modunu verin. Örnek kök kayıt:
Gmail'de "Show original" ile Authentication-Results satırını okuyun ve üç alanı ayrı ayrı doğrulayın: dmarc=pass header.from=, spf=pass smtp.mailfrom=, dkim=pass header.d=. header.from ile smtp.mailfrom/header.d org domain'lerini karşılaştırın — hizalamayı gözünüzle görürsünüz.
Aggregate (rua) raporlarını okurken en kritik ayrım şu: rapordaki <policy_evaluated> altındaki dkim/spf değerleri zaten hizalama sonucudur, ham auth değil. Ham auth sonuçları <auth_results> altındadır:
xml
<record>
<row><policy_evaluated>
<dkim>pass</dkim> <!-- ALIGNMENT sonucu -->
<spf>fail</spf> <!-- ALIGNMENT sonucu -->
</policy_evaluated></row>
<auth_results>
<spf><domain>em123.evilmail.pro</domain><result>pass</result></spf>
</auth_results>
</record>
Bu örnekte SPF ham auth pass, ama hizalama fail — çünkü em123.evilmail.pro strict altında evilmail.pro ile eşleşmiyor. Rapor okumada en sık hata bu iki katmanı karıştırmaktır. relaxed'da pass gördüğünüz bir kaynağı zihinsel olarak strict'e çevirip hâlâ geçer mi diye bakın; ölçtüğünüz şey tam olarak hizalama marjınızdır. learndmarc.com veya dmarcian gibi araçlar görselleştirir, ama başlığı elle okumayı bilmek şarttır.
Üretime almadan önce checklist
From: domain'i ile fiili gönderim (Return-Path + DKIM d=) org domain'de çakışıyor mu — dig ve gerçek başlıkla doğrula, varsayma.
Her gönderim kaynağı için (kendi MTA, ESP, faturalama, CRM) en az bir hizalı mekanizma var mı?
relaxed ile ve p=none ile başla; rua topla, 2-4 hafta gözlemle.
Aggregate raporda tüm meşru trafik %100 hizalı görünüyor mu?
Subdomain gönderimi envanterlenmiş ve kilitli mi? Değilse strict açma.
Kök ve subdomain için ayrı politika (sp=) düşün; tek büyük strict yerine domain başına karar.
Politika yolunu izle: p=none → p=quarantine; pct=25 → pct=100 → p=reject.
strict'e ancak kaynak envanteri tam ve raporlar temizken geç.
Operasyonel kural tek cümledir: relaxed ile başla, aggregate raporda %100 hizalama gördüğün ve subdomain gönderimini kilitlediğin gün strict'e çevir — bir gün önce değil.
