SPF kaydınız yayında, DKIM imzanız doğrulanıyor, mail başlığında spf=pass ve dkim=pass yazıyor — ama aynı satırın sonunda dmarc=fail görüyorsunuz. Bu, DMARC kuran herkesin er ya da geç karşılaştığı ve ilk bakışta çelişkili görünen durumdur. Cevap tek bir kavramda saklı: DMARC alignment, yani hizalama. DMARC, SPF ve DKIM'in geçmesiyle yetinmez; hangi alan adı için geçtiklerini de sorgular ve bu alan adının kullanıcının ekranda gördüğü gönderici adresiyle uyuşmasını şart koşar.
Bu yazıda hizalamanın neden var olduğunu, SPF ve DKIM hizalamasının ayrı ayrı nasıl değerlendirildiğini, relaxed ile strict modun ne değiştirdiğini, hizalamanın en sık hangi üç senaryoda bozulduğunu ve kendi kurulumunuzda bunu nasıl doğrulayıp düzelteceğinizi anlatacağım. Sonunda dmarc=fail satırına bakıp sebebini dakikalar içinde bulabileceksiniz.
DMARC Neden Hizalama Diye Bir Şart Koyar#
Sorunun kökeni şu: SPF ve DKIM, kullanıcının gördüğü gönderici adresini kontrol etmez. SPF, SMTP zarfındaki gönderen adresini (Return-Path / MAIL FROM) doğrular. DKIM ise imzanın hangi alan adına ait olduğunu, yani imzadaki d= değerini doğrular. Kullanıcının ekranında görünen From başlığı ise bambaşka bir alandır ve bu iki kontrolün hiçbirine dahil değildir.
Bu boşluğun sonucu şudur: bir saldırgan kendi alan adı için mükemmel bir SPF kaydı ve geçerli bir DKIM imzası kurabilir, sonra From başlığına sizin alan adınızı yazıp mail gönderebilir. Alıcı sunucu spf=pass ve dkim=pass görür, çünkü kontroller saldırganın kendi alan adı için gerçekten geçmiştir — ama kullanıcı ekranda sizin adınızı okur.
DMARC bu boşluğu kapatmak için tasarlandı. Kuralı şudur: SPF veya DKIM'den en az biri geçmeli VE geçtiği alan adı, From başlığındaki alan adıyla hizalı olmalıdır. İkisinden birinin hizalı geçmesi yeterlidir; ikisi birden gerekmez. Hizalama olmadan geçen bir kontrol, DMARC açısından hiç geçmemiş sayılır.
| Senaryo | SPF | DKIM | Hizalama | DMARC sonucu |
|---|---|---|---|---|
| Normal kendi sunucunuz | pass | pass | Her ikisi hizalı | pass |
| Gönderim servisi, özel dönüş yolu | pass | pass | Her ikisi hizalı | pass |
| Servis, varsayılan dönüş yolu | pass | pass | Yalnız DKIM hizalı | pass |
| Yönlendirilmiş mail | fail | pass | Yalnız DKIM hizalı | pass |
| Sahtecilik girişimi | pass | pass | Hiçbiri hizalı değil | fail |
| İmzasız üçüncü taraf araç | pass | yok | Hizalı değil | fail |
Tablonun son iki satırı işin özünü gösteriyor: DMARC'ın koruduğu şey alan adınızın görünen kimliğidir ve bu koruma yalnızca hizalama şartıyla mümkün olur.
SPF Hizalaması Nasıl Değerlendirilir#
SPF hizalaması iki alan adını karşılaştırır: SMTP zarfındaki gönderen adresinin alan adı (teknik adıyla RFC5321.MailFrom) ve From başlığındaki alan adı (RFC5322.From). Bu ikisi uyuşuyorsa SPF hizalıdır.
Somut bir örnekle bakalım. Bir gönderim servisi kullanıyorsunuz ve mailleriniz şöyle çıkıyor:
Return-Path: [email protected]
From: Muhasebe <[email protected]>
SPF kontrolü mail.servis.net alan adı üzerinden yapılır ve büyük olasılıkla pass verir — servis kendi SPF kaydını doğru kurmuştur. Ama From başlığındaki alan adı firmaniz.com'dur. mail.servis.net ile firmaniz.com hiçbir modda hizalı değildir, dolayısıyla SPF hizalaması başarısızdır ve DMARC bu kontrolü yok sayar. Mail başlığında bu şöyle görünür:
Authentication-Results: mx1.ornek.com;
spf=pass smtp.mailfrom=mail.servis.net;
dkim=pass header.d=firmaniz.com header.s=s1;
dmarc=pass (p=NONE dis=NONE) header.from=firmaniz.com
Bu örnekte DMARC yine de geçiyor — çünkü DKIM hizalı (header.d ile header.from uyuşuyor). Eğer DKIM de servisin kendi alan adıyla imzalanmış olsaydı, dmarc=fail görürdünüz.
SPF hizalamasını düzeltmenin yolu, gönderim servisinde özel bir dönüş yolu (custom return-path) tanımlamaktır. Servisler bunu genellikle kendi alan adınızın altında bir alt alan adı isteyerek yapar:
; Servisin sizden istediği tipik dönüş yolu kaydı
bounce.firmaniz.com. 3600 IN CNAME donusyolu.servis.net.
Bu kayıt eklendiğinde Return-Path adresi [email protected] haline gelir ve bounce.firmaniz.com ile firmaniz.com relaxed modda hizalanır. SPF'in Return-Path üzerinden çalıştığını ve ~all ile -all arasındaki farkı SPF SoftFail ve HardFail farkı yazısında ayrıntısıyla ele aldım.
DKIM Hizalaması Nasıl Değerlendirilir#
DKIM hizalaması, doğrulanmış bir imzanın d= değeriyle From başlığındaki alan adını karşılaştırır. Bir mesajda birden fazla DKIM imzası olabilir; DMARC açısından en az bir tanesinin hem doğrulanması hem hizalı olması yeterlidir.
İmza başlığı şöyle görünür ve d= ile s= değerleri belirleyicidir:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=firmaniz.com; s=s1; t=1756110764;
h=From:To:Subject:Date:Message-ID;
bh=...; b=...
Buradaki d=firmaniz.com değeri From başlığındaki alan adıyla aynı olduğu için DKIM hizalıdır. Servis kendi anahtarıyla imzalayıp d=servis.net yazsaydı hizalama bozulurdu.
DKIM hizalaması, SPF hizalamasından daha dayanıklıdır ve bunun sebebi imzanın mesajın içinde taşınmasıdır. Mesaj kaç sunucudan geçerse geçsin, kaç kez yönlendirilirse yönlendirilsin, imzalanan başlıklar ve gövde değişmediği sürece imza geçerli kalır ve hizalama korunur. SPF ise gönderen IP'ye baktığı için her yönlendirmede kırılır. Bu yüzden sağlam bir DMARC kurulumunun bel kemiği DKIM'dir, SPF değil.
Buna karşılık DKIM'in kendi kırılma noktası mesajın değiştirilmesidir. İmzalanan bir başlığa (h= listesindeki) ekleme yapan ya da gövdeye alt bilgi ekleyen bir ara sunucu imzayı geçersiz kılar. Bu durumun teşhisi için DKIM doğrulaması başarısız yazısındaki adımları izleyin; DKIM anahtarınız DNS'e sığmıyorsa DKIM TXT kaydı 255 karakter sınırı yazısı kaydın nasıl bölüneceğini anlatıyor.
Relaxed ve Strict Mod Arasındaki Fark#
Hizalamanın ne kadar katı değerlendirileceğini DMARC kaydınızdaki iki etiket belirler: aspf (SPF hizalama modu) ve adkim (DKIM hizalama modu). Her ikisi de r (relaxed) veya s (strict) değerini alır ve belirtilmezse varsayılan r'dir.
Relaxed modda kurumsal alan adı (organizational domain) düzeyinde karşılaştırma yapılır. Yani mail.firmaniz.com, bounce.firmaniz.com ve firmaniz.com birbiriyle hizalı sayılır, çünkü hepsinin kurumsal alan adı firmaniz.com'dur. Bu, alt alan adı kullanan gerçek dünya kurulumlarının büyük çoğunluğunu kapsar.
Strict modda ise alan adlarının tam olarak, harfi harfine aynı olması gerekir. mail.firmaniz.com ile firmaniz.com strict modda hizalı değildir.
| From alan adı | Karşılaştırılan alan adı | Relaxed | Strict |
|---|---|---|---|
| firmaniz.com | firmaniz.com | Hizalı | Hizalı |
| firmaniz.com | mail.firmaniz.com | Hizalı | Hizalı değil |
| mail.firmaniz.com | firmaniz.com | Hizalı | Hizalı değil |
| firmaniz.com | servis.net | Hizalı değil | Hizalı değil |
| firmaniz.com | firmaniz.com.tr | Hizalı değil | Hizalı değil |
Pratik tavsiye: relaxed modda kalın. Strict mod ek bir güvenlik sağlamaz gibi görünse de aslında marjinal bir fayda için ciddi bir kırılganlık ekler — alt alan adı kullanan bir gönderim yolunuz olduğu anda hizalama bozulur. Strict mod yalnızca alt alan adı kullanımını tamamen kontrol ettiğiniz, çok sıkı yönetilen kurumsal ortamlarda anlamlıdır.
Tipik bir DMARC kaydı şöyle görünür:
_dmarc.firmaniz.com. 3600 IN TXT "v=DMARC1; p=none; adkim=r; aspf=r; fo=1; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100"
Buradaki fo=1, SPF veya DKIM'den herhangi biri hizalı geçmediğinde adli rapor üretilmesini ister; hizalama sorunlarını avlarken en faydalı etiket budur.
Hizalamanın En Sık Bozulduğu Üç Senaryo#
Birinci senaryo: üçüncü taraf gönderim servisi. Bir bülten platformu, fatura yazılımı veya CRM kullanıyorsunuz. Servis kendi altyapısından gönderdiği için hem Return-Path hem DKIM imzası varsayılan olarak kendi alan adını taşır. From başlığında sizin adınız yazar ama hiçbir kontrol sizin alan adınıza hizalanmaz, sonuç dmarc=fail. Çözüm, servisin "alan adı doğrulama" adımını eksiksiz tamamlamaktır: hem DKIM CNAME kayıtlarını hem de özel dönüş yolu kaydını eklemelisiniz. Çoğu kişi yalnızca DKIM kayıtlarını ekler ve dönüş yolunu atlar; bu durumda DKIM hizalanır, SPF hizalanmaz — DMARC yine geçer ama tek bacak üzerinde durursunuz.
İkinci senaryo: posta listeleri ve tartışma grupları. Bir listeye mail gönderdiğinizde liste yazılımı konu satırına bir etiket ekler, gövdenin sonuna abonelik bilgisi yapıştırır ve mesajı tüm abonelere yeniden dağıtır. Bu iki değişiklik DKIM imzanızı bozar, yeniden dağıtım ise SPF'i kırar. Sonuç: hem SPF hem DKIM hizalaması başarısız olur ve p=reject politikanız varsa mesajınız listedeki herkes için reddedilir. Bu sorunun standart çözümü ARC (Authenticated Received Chain) protokolüdür ve uygulaması liste yazılımına aittir, size değil.
Üçüncü senaryo: iç sistemlerden çıkan otomatik mailler. Ofisteki bir yazıcının tarama-mail özelliği, bir izleme sistemi veya eski bir cron betiği, From başlığına kurumsal alan adınızı yazıp doğrudan gönderim yapar. Ne DKIM imzası vardır ne de o sunucu SPF kaydınızda listelidir. Bu maillerin varlığını genellikle DMARC raporlarını okurken keşfedersiniz — ve p=reject'e geçmeden önce keşfetmek çok önemlidir. Raporları yorumlamak için DMARC raporu nasıl okunur yazısına bakın.
Hizalamayı Doğrulama ve Düzeltme Adımları#
Hizalamayı doğrulamanın en kesin yolu, kendinize gerçek bir test maili gönderip başlığı okumaktır. Başlığa nasıl ulaşacağınızı ve hangi satırlara bakacağınızı mail başlıklarını okuma ve analiz etme yazısında anlattım. Kontrol sırası şudur:
Frombaşlığındaki alan adını not edin. Karşılaştırmanın referansı budur.- Return-Path adresinin alan adına bakın.
Fromile aynı kurumsal alan adı altındaysa SPF hizalıdır. DKIM-Signaturebaşlığındakid=değerine bakın.Fromile aynı kurumsal alan adı altındaysa DKIM hizalıdır.- Authentication-Results satırındaki
dmarc=sonucunu okuyun.passise en az bir bacak hizalı geçmiş demektir. dmarc=failgörüyorsanız 2. ve 3. adımdan hangisinin uymadığını bulun; düzeltme o bacağa yapılır.
Komut satırından kayıtlarınızı hızlıca doğrulamak için:
# DMARC kaydı yayında mı ve hizalama modları ne
dig +short _dmarc.firmaniz.com TXT
# SPF kaydı tek mi
dig +short firmaniz.com TXT | grep -c "v=spf1"
# DKIM seçicisi çözümleniyor mu (servis CNAME verdiyse zinciri izler)
dig +short s1._domainkey.firmaniz.com TXT
dig +short s1._domainkey.firmaniz.com CNAME
# Özel dönüş yolu kaydı kurulmuş mu
dig +short bounce.firmaniz.com CNAME
Düzeltme sırası da önemlidir: önce DKIM hizalamasını sağlayın, sonra SPF'e geçin. DKIM daha dayanıklı olduğu için tek başına da DMARC'ı geçirir ve yönlendirilen maillerinizi korur. SPF hizalaması ise ikinci bir güvence katmanıdır.
Sık Yapılan Hatalar#
En pahalı hata, hizalamayı doğrulamadan p=reject politikasına geçmektir. Hizalamayan meşru bir gönderim yolunuz varsa o yoldan çıkan tüm mailler bir anda reddedilir ve bunu genellikle müşteri şikâyetiyle öğrenirsiniz. Doğru yol p=none ile başlayıp raporlarda hizalamayan meşru kaynak kalmadığını görene kadar beklemektir.
İkinci hata, spf=pass gördüğü için işin tamam olduğunu sanmaktır. Authentication-Results satırında spf=pass yazması, o kontrolün hangi alan adı için geçtiğini söylemez; onu smtp.mailfrom değerinden okumanız gerekir. Aynı satırda dmarc=fail varsa mesele neredeyse her zaman hizalamadır.
Üçüncü hata, strict modu "daha güvenli" diye seçmektir. Strict mod DMARC'ın sağladığı korumayı artırmaz; yalnızca alt alan adı kullanan meşru gönderim yollarınızı kırar. Özel bir gereksiniminiz yoksa adkim=r; aspf=r bırakın.
Dördüncüsü, alt alan adları için politika belirlememektir. DMARC kaydınızdaki sp= etiketi alt alan adlarına uygulanacak politikayı belirtir; yoksa ana politikanız alt alan adlarına da uygulanır. Hiç kullanmadığınız alt alan adlarını korumak için sp=reject vermek iyi bir alışkanlıktır. Alan adı taklidine karşı bütünsel önlemler için e-posta spoofing önleme yazısına bakabilirsiniz.
Sıkça Sorulan Sorular#
SPF ve DKIM geçiyor ama DMARC neden fail veriyor#
Neredeyse kesinlikle hizalama sorunudur. SPF, zarftaki gönderen adresinin alan adı için geçmiş olabilir; DKIM ise imzayı atan servisin alan adı için. Her iki kontrol de kendi alan adında başarılı, ancak hiçbiri From başlığındaki alan adıyla uyuşmuyorsa DMARC bunları yok sayar ve fail verir. Başlıktaki smtp.mailfrom ve header.d değerlerini header.from ile karşılaştırın.
Hizalama için SPF ve DKIM'in ikisi de mi geçmeli#
Hayır, birinin hizalı geçmesi yeterlidir. DMARC "SPF hizalı geçti VEYA DKIM hizalı geçti" mantığıyla çalışır. Pratikte ikisini birden sağlamak daha sağlamdır çünkü yönlendirme SPF'i kırar, mesaj değişikliği ise DKIM'i. İki bacağın da hizalı olduğu bir kurulumda biri kırıldığında diğeri DMARC'ı geçirmeye devam eder.
Relaxed mi strict mi seçmeliyim#
Özel bir gereksiniminiz yoksa relaxed (varsayılan) modda kalın. Relaxed mod kurumsal alan adı düzeyinde karşılaştırma yapar, yani mail.firmaniz.com ile firmaniz.com hizalı sayılır — gerçek dünyadaki alt alan adı kullanımlarının neredeyse tamamını kapsar. Strict mod ek koruma sağlamaz ama alt alan adı kullanan meşru gönderim yollarınızı kırma riski taşır.
Gönderim servisi kullanırken hizalamayı nasıl sağlarım#
Servisin alan adı doğrulama adımlarının tamamını uygulayın. Genellikle iki set kayıt istenir: DKIM için bir veya iki CNAME kaydı ve özel dönüş yolu için bir CNAME daha. Çoğu kişi yalnızca DKIM kayıtlarını ekleyip dönüş yolunu atlar; bu durumda DKIM hizalanır ama SPF hizalanmaz. İkisini birden kurmak, bir bacak kırıldığında diğerinin devreye girmesini sağlar.
Yönlendirilen mailler DMARC'ı geçer mi#
DKIM imzanız varsa evet, geçer. Yönlendirme sırasında gönderen IP değiştiği için SPF kırılır, ancak DKIM imzası mesajın içinde taşındığı için — mesaj değiştirilmediği sürece — geçerli kalır ve hizalama korunur. DKIM imzanız yoksa veya yönlendiren sistem mesajı değiştiriyorsa DMARC başarısız olur; bu, DKIM'i her gönderim yolunda devreye almanın en pratik gerekçesidir.
DMARC kaydını p=reject yapmak ne kadar sürer#
Teknik olarak DNS kaydını değiştirmek dakikalar sürer, ancak güvenli geçiş genellikle bir ile üç ay alır. Bu sürenin tamamı rapor okumakla geçer: p=none ile başlar, gelen toplu raporlarda alan adınız adına gönderim yapan tüm kaynakları çıkarır, meşru olanları hizalarsınız. Hizalamayan meşru kaynak kalmadığında önce p=quarantine, sonra p=reject aşamasına geçersiniz.
Alt alan adlarım için ayrı DMARC kaydı gerekli mi#
Zorunlu değil; alt alan adları için ayrı bir kayıt yoksa ana alan adının politikası uygulanır. Ancak sp= etiketiyle alt alan adlarına farklı bir politika verebilirsiniz. İyi bir alışkanlık, ana politikanız henüz p=none iken bile hiç kullanmadığınız alt alan adlarını sp=reject ile korumaktır; böylece kimse fatura.firmaniz.com gibi bir isimle sahte mail gönderemez.
Kapanış#
Hizalama, DMARC'ı SPF ve DKIM'den ayıran ve gerçekten koruma sağlayan mekanizmadır. Aklınızda kalması gereken dört şey: DMARC, kontrolün geçmesiyle değil, hangi alan adı için geçtiğiyle ilgilenir; SPF hizalaması Return-Path üzerinden, DKIM hizalaması imzadaki d= değeri üzerinden değerlendirilir; DKIM daha dayanıklıdır ve yönlendirmede ayakta kalan tek bacaktır, o yüzden önce onu hizalayın; ve relaxed modda kalıp p=none ile başlayarak raporları okumadan asla p=reject'e geçmeyin.
Kendi mail sunucunuzu kurup DKIM imzalamayı ve DNS kayıtlarını yönetmek isterseniz Postfix, Dovecot ve DKIM'i yapılandırılmış gelen SMTP sunucu paketleri iyi bir başlangıç noktasıdır; daha genel bir altyapı için tam root erişimli VDS sunucularına bakabilirsiniz. DNS kayıtlarınızı tek yerden yönetmek isterseniz alan adı hizmetimiz, kurulumu ve raporların takibini bize bırakmak isterseniz sunucu yönetimi hizmetimiz devrede.