Bir müşteri arıyor: "Size gelen mailleri Gmail'e yönlendiriyorum ama bazıları spam'e düşüyor, hatta bazıları hiç ulaşmıyor." Kayıtlarına bakıyorsun, mail sana sorunsuz gelmiş, yönlendirme de çalışmış — ama Gmail tarafında DMARC başarısız. Sebep şu: yönlendirme sırasında zarf göndericisi değiştiği için SPF kırılır, liste yazılımı konu satırına etiket veya gövdeye altbilgi eklediyse DKIM de kırılır. ARC imzası tam olarak bu sorunu çözmek için tasarlandı: mailin sana geldiğinde doğrulamadan geçtiğini, sonraki durağa kanıtlanabilir biçimde aktarmanı sağlar.
Bu rehberde önce yönlendirmenin kimlik doğrulamayı neden bozduğunu somut biçimde göstereceğim, sonra ARC'ın üç başlığının ne işe yaradığını, bir ARC zincirini nasıl okuyacağını ve kendi sunucunda Rspamd ya da OpenARC ile nasıl imzalayacağını anlatacağım. Sonunda ARC'ın neyi çözmediğine de değineceğim, çünkü bu konuda beklentiler genelde gerçekten fazla yüksek oluyor.
Yönlendirme Neden SPF ve DKIM'i Kırar#
İki mekanizma da farklı sebeplerle kırılır ve ayrımı bilmek çözümü anlamayı kolaylaştırır.
SPF, yönlendirmede neredeyse her zaman kırılır. SPF, zarf göndericisinin (MAIL FROM) alan adına bakar ve o alan adının SPF kaydında bağlanan IP'nin yetkili olup olmadığını sorar. Sen maili yönlendirdiğinde bağlantı artık senin sunucundan çıkar; orijinal göndericinin SPF kaydında senin IP'n yazmadığı için sonuç fail olur. Bu beklenen ve normal bir davranıştır, bir hata değildir.
DKIM ise yalnızca mail değiştirildiğinde kırılır. DKIM imzası gövdeyi ve seçilmiş başlıkları kapsar. Basit bir yönlendirme mailin içeriğine dokunmazsa imza sağlam kalır. Ama posta listesi yazılımı konu satırının başına [Liste-Adi] eklediyse ya da gövdenin sonuna abonelikten çıkma bağlantısı yerleştirdiyse imza bozulur ve sonuç fail olur.
| Durum | SPF | DKIM | DMARC sonucu |
|---|---|---|---|
| Doğrudan teslimat | pass | pass | pass |
| Basit yönlendirme, içerik değişmemiş | fail | pass | pass (DKIM üzerinden) |
| Liste, konu/gövde değişmiş | fail | fail | fail |
| Yönlendirme + gövdeye altbilgi | fail | fail | fail |
Tablodaki ikinci satır önemli: DMARC, SPF ve DKIM'den birinin hizalı biçimde geçmesini yeterli sayar. Bu yüzden içeriğe dokunmayan bir yönlendirme genellikle sorun çıkarmaz. Asıl sorun üçüncü ve dördüncü satırlardır — orada kurtaracak hiçbir şey kalmaz. DKIM doğrulamasının başka sebeplerle de başarısız olabileceğini unutma; ayrıntısı DKIM doğrulaması başarısız yazısında.
ARC Nasıl Çalışır: Üç Başlık#
ARC'ın fikri basit: mail sana geldiğinde doğrulama sonuçlarını imzalayarak kaydet. Sonraki alıcı, orijinal SPF/DKIM sonuçlarını kendisi doğrulayamasa bile, senin kaydettiğin sonuca — sana güveniyorsa — bakabilir.
Her ARC uygulayan durak (hop) maile üç başlık ekler ve bunların hepsi aynı örnek numarasını (i=) taşır:
ARC-Authentication-Results(AAR) — Bu durakta yapılan SPF, DKIM ve DMARC doğrulamalarının sonucunu düz metin olarak kaydeder. Fotoğrafı çeken başlık budur.ARC-Message-Signature(AMS) — Mailin o andaki hâlini imzalar; teknik olarak DKIM imzasına çok benzer, gövdeyi ve başlıkları kapsar.ARC-Seal(AS) — Yalnızca ARC başlıklarını imzalar ve zincirin bütünlüğünü korur. Bir ara durak önceki halkaları silmeye ya da değiştirmeye kalkarsa mühür bozulur.
ARC-Seal içindeki cv= etiketi zincirin durumunu bildirir: ilk durakta cv=none, sağlam devam eden zincirde cv=pass, bozulmuş bir zincirde cv=fail. Bir kez fail olan zincir kurtarılamaz; sonraki duraklar mühür eklemeyi bırakır.
Zincir mantığı şöyle işler: birinci durak i=1 başlıklarını ekler, ikinci durak i=2 ekler ve i=1 halkasını da mührün kapsamına alır. Böylece her yeni halka, kendisinden önceki tüm zinciri onaylamış olur.
Bir ARC Zincirini Okumak#
Yönlendirilmiş bir mailin ham başlıklarına baktığında şuna benzer bir yapı görürsün:
ARC-Seal: i=1; a=rsa-sha256; t=1756000000; cv=none;
d=liste.ornek.com; s=arc; b=Xk2n...
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
d=liste.ornek.com; s=arc; t=1756000000;
h=from:to:subject:date:message-id;
bh=47DEQpj8HBSa...; b=QmFz...
ARC-Authentication-Results: i=1; liste.ornek.com;
spf=pass [email protected];
dkim=pass header.d=firmaniz.com;
dmarc=pass header.from=firmaniz.com
Okuma sırası şudur: en yüksek i= numaralı halkadan başla ve geriye doğru in. Yukarıdaki örnekte tek bir halka var (i=1) ve cv=none yazıyor — bu, zincirin burada başladığı anlamına gelir, bir hata değil. AAR satırı ise altın değerinde: mail liste.ornek.com sunucusuna geldiğinde SPF, DKIM ve DMARC'ın hepsi geçmiş. Liste yazılımı gövdeye altbilgi eklediyse ve DKIM sonradan kırıldıysa, son alıcı bu kayda bakarak "kaynağında temizmiş" sonucuna varabilir.
Kendi kutuna gelen bir maildeki zinciri hızlıca çıkarmak için:
# Ham mail dosyasından ARC başlıklarını süz
grep -i '^ARC-' /tmp/yonlendirilen-mail.eml
# Yalnızca zincir durumunu gör
grep -io 'cv=[a-z]*' /tmp/yonlendirilen-mail.eml
# cv=none
# cv=pass
Birden fazla cv=pass görüyorsan mail birkaç ARC uygulayan duraktan geçmiş ve zincir sağlam demektir. Herhangi bir yerde cv=fail varsa zincir o noktada kopmuştur ve sonrasında hiçbir değeri kalmaz.
Rspamd ile ARC İmzalama#
Sunucunda zaten Rspamd çalışıyorsa ARC imzalama için ayrı bir yazılım kurmana gerek yok; arc modülü bu işi yapar ve DKIM imzalama modülüyle aynı anahtar altyapısını kullanabilir.
# /etc/rspamd/local.d/arc.conf
path = "/var/lib/rspamd/dkim/$domain.$selector.key";
selector = "arc";
sign_local = true;
sign_authenticated = false;
sign_inbound = true;
use_domain = "recipient";
sign_inbound = true satırı kritik olandır: ARC'ın amacı gelen maili mühürleyip ileri taşımaktır, kendi giden mailini imzalamak değil. use_domain = "recipient" ile mühür, mailin teslim edildiği alan adı adına atılır — yani sen yönlendiren taraf olarak kendi alan adınla imzalarsın.
Anahtarı DKIM ile aynı yöntemle üretirsin; yalnızca seçiciyi ayrı tut ki DKIM anahtarını döndürdüğünde ARC zinciri etkilenmesin:
rspamadm dkim_keygen -s arc -b 2048 -d firmaniz.com \
-k /var/lib/rspamd/dkim/firmaniz.com.arc.key
chown _rspamd:_rspamd /var/lib/rspamd/dkim/firmaniz.com.arc.key
chmod 600 /var/lib/rspamd/dkim/firmaniz.com.arc.key
systemctl reload rspamd
Çıktıdaki arc._domainkey TXT kaydını DNS'e eklemeyi unutma; ARC mühründeki genel anahtar da tıpkı DKIM gibi DNS'ten okunur. Rspamd'ın genel kurulumu ve modül mantığı için Rspamd kurulumu ve ayarları yazısına bakabilirsin. Anahtarları belirli aralıklarla yenilemeyi de planla; yöntemi DKIM anahtar rotasyonu yazısında anlattım.
OpenARC ile Postfix Entegrasyonu#
Rspamd kullanmıyorsan OpenARC, Postfix'e milter olarak bağlanan bağımsız bir çözümdür. OpenDKIM ile aynı ekipten çıktığı için yapılandırması tanıdık gelir.
# /etc/openarc.conf
Domain firmaniz.com
Selector arc
KeyFile /etc/openarc/keys/arc.private
Socket inet:[email protected]
Mode sv
Canonicalization relaxed/relaxed
SoftwareHeader yes
UserID openarc:openarc
Mode sv değeri hem doğrulama (v) hem mühürleme (s) yapılacağını söyler. Yalnızca doğrulama istiyorsan v, yalnızca mühürleme istiyorsan s yazarsın.
Postfix tarafında milter zincirine eklenir:
# /etc/postfix/main.cf
# Sıra önemli: önce DKIM doğrulama, sonra ARC mühürleme
smtpd_milters = inet:127.0.0.1:8891, inet:127.0.0.1:8894
non_smtpd_milters = $smtpd_milters
milter_default_action = accept
milter_protocol = 6
Milter sırası ARC'ta gerçekten önemlidir. ARC mührü, kendisinden önce yapılan doğrulamaların sonucunu kaydeder; DKIM doğrulayıcısı ARC'tan sonra çalışırsa AAR başlığı boş ya da eksik kalır ve zincir hiçbir işe yaramaz. Doğrulama yapan milter'lar her zaman ARC'tan önce gelmeli.
# Servisleri başlat ve dinlediklerini doğrula
systemctl enable --now openarc
ss -lntp | grep -E '8891|8894'
postfix reload
Postfix milter yapılandırmasının genel mantığını Postfix main.cf yapılandırması yazısında bulabilirsin.
ARC'ın Sınırları ve Yanlış Beklentiler#
ARC hakkındaki en yaygın yanlış anlama, mühür atınca alıcının maili kabul etmek zorunda olduğunu sanmaktır. Böyle bir zorunluluk yoktur. ARC, alıcıya bir bilgi sunar; o bilgiye güvenip güvenmeme kararı tamamen alıcının yerel politikasına bağlıdır. Alıcı, mührü atan alan adını tanımıyorsa ya da itibarı düşükse zinciri görmezden gelebilir.
Bundan çıkan pratik sonuç şudur: ARC, mühür atan tarafın itibarına dayanır. Yeni kurulmuş, hiç trafik geçmemiş bir alan adının ARC mührü, büyük bir sağlayıcının mührü kadar ağırlık taşımaz. Bu güven zamanla ve düzgün gönderim davranışıyla kazanılır.
ARC'ın çözmediği diğer şeyler:
- Kendi giden mailinin DMARC sorunlarını çözmez. Onun için SPF, DKIM ve hizalamayı düzeltmen gerekir.
- Bozuk bir zinciri onarmaz.
cv=failgördüğün andan sonrası kayıptır. - Spam filtresinin yerine geçmez. ARC yalnızca kimlik doğrulama sonuçlarını taşır, içerik hakkında hiçbir şey söylemez.
- Kimlik avını engellemez. Kötü niyetli bir sunucu da kendi zincirini başlatabilir; mühür "bu mail temizdir" demez, "bana geldiğinde şu sonuçları aldım" der.
Yönlendirme kaynaklı sorunları çözmenin ARC dışında iki pratik yolu daha var: SRS (Sender Rewriting Scheme) ile zarf göndericisini yeniden yazmak, ya da yönlendirme yerine POP3/IMAP ile mail çekmek. cPanel üzerinde yönlendirme kuruyorsan cPanel e-posta iletme yazısındaki seçenekler bu kararı vermene yardımcı olur.
Sık Yapılan Hatalar ve Doğrulama#
ARC kurulumlarında karşılaştığım hatalar neredeyse her zaman aynı beş başlıkta toplanıyor.
- Milter sırasını yanlış kurmak. ARC, kendisinden önce çalışan doğrulayıcıların sonucunu kaydeder. DKIM doğrulayıcısını ARC'tan sonraya koyarsan
ARC-Authentication-Resultsbaşlığı boş kalır ve zincir hiçbir bilgi taşımaz. sign_inboundyerine giden maili imzalamak. ARC'ın amacı gelen maili mühürleyip ileri taşımaktır. Kendi giden mailini ARC ile imzalamak bir işe yaramaz; orada gereken şey DKIM'dir.- ARC ve DKIM için aynı seçiciyi paylaşmak. DKIM anahtarını döndürdüğün gün ARC zincirin de kırılır. Ayrı seçici kullan,
arcvemailgibi. - DNS kaydını eklemeyi unutmak. Mühür atılır ama alıcı genel anahtarı bulamaz; sonuç, hiç mühür atmamışsın gibidir. Üstelik hiçbir hata mesajı görmezsin.
- Maili ARC mührü atıldıktan sonra değiştirmek. Liste altbilgisi ya da konu etiketi ekleyecek bir bileşen varsa, bu değişiklik mühürden önce yapılmalıdır; sonra yapılırsa
ARC-Message-Signaturebozulur.
Kurulumdan sonra gerçek bir yönlendirme testi yap: kendi alan adından bir mail gönder, sunucun üzerinden harici bir kutuya yönlendir ve hedefte ham başlıkları incele.
# Hedefte alınan mailde zincir sağlam mı
grep -iE '^(ARC-|Authentication-Results:)' /tmp/hedef-mail.eml
# Beklenen: cv=none (ilk halka) ya da cv=pass, ve arc=pass satırı
# Authentication-Results: mx.hedef.com; arc=pass (i=1 spf=pass dkim=pass)
Hedefteki Authentication-Results başlığında arc=pass görüyorsan zincirin doğrulanmış demektir. arc=fail ya da hiç arc= satırı yoksa, önce DNS kaydını, sonra milter sırasını kontrol et.
Sıkça Sorulan Sorular#
ARC imzası olmadan mail yönlendirme çalışmaz mı#
Çalışır, ama güvenilirliği düşer. İçeriğe dokunmayan basit bir yönlendirmede DKIM imzası sağlam kaldığı için DMARC genellikle geçmeye devam eder ve mail sorunsuz teslim edilir. Sorun, posta listesi gibi maili değiştiren sistemlerde ya da katı p=reject politikası uygulayan alan adlarında ortaya çıkar. ARC bu senaryolarda kurtarıcı olur; onun dışında zorunlu bir bileşen değildir.
ARC mührümü kim dikkate alır#
Bu tamamen alıcının yerel politikasına bağlıdır. Büyük sağlayıcılar ARC zincirlerini değerlendirir ama mühürü atan alan adının itibarına bakarak karar verir. Yeni bir alan adının mührü, uzun süredir düzgün gönderim yapan bir alan adının mührü kadar ağırlık taşımaz. Yani ARC kurmak tek başına yeterli değildir; gönderim itibarını da korumaya devam etmen gerekir.
cv=fail gördüm, nasıl düzeltirim#
Kısaca söylemek gerekirse düzeltemezsin — bozulan bir zincir geriye dönük onarılamaz. cv=fail, zincirdeki bir halkanın imzasının doğrulanamadığını gösterir; genellikle bir ara durak mailin başlıklarını değiştirdiği ya da ARC başlıklarını yeniden sıraladığı için oluşur. Yapman gereken, kendi tarafındaki hangi bileşenin maili değiştirdiğini bulmak ve mümkünse o değişikliği ARC mührü atılmadan önce yaptırmaktır.
ARC için ayrı bir DNS kaydı gerekir mi#
Evet, ARC mührünün genel anahtarı da DKIM gibi bir TXT kaydında yayınlanır ve <selector>._domainkey.firmaniz.com biçiminde durur. DKIM ile aynı anahtarı kullanabilirsin ama ayrı bir seçici tanımlamanı öneririm; böylece DKIM anahtarını döndürdüğünde ARC zinciri etkilenmez ve iki mekanizmanın sorunlarını birbirinden ayırabilirsin.
ARC ile SRS arasındaki fark nedir#
SRS, zarf göndericisini yönlendiren sunucunun kendi alan adıyla yeniden yazar ve böylece SPF doğrulamasının geçmesini sağlar; DKIM'e hiç dokunmaz. ARC ise hiçbir şeyi yeniden yazmaz, sadece orijinal doğrulama sonuçlarını imzalayarak kaydeder ve DKIM'in kırıldığı senaryolarda da işe yarar. İkisi birbirinin alternatifi değildir, birlikte kullanılabilirler ve farklı sorunları çözerler.
Kendi sunucumda ARC kurmalı mıyım#
Başkalarının mailini yönlendiriyorsan ya da bir posta listesi çalıştırıyorsan evet, kurmanı öneririm; aksi hâlde yönlendirdiğin maillerin bir kısmı hedefte kaybolur. Yalnızca kendi kullanıcılarının mailini alıp teslim eden, yönlendirme yapmayan bir sunucuda ARC'ın pratik faydası sınırlıdır. Rspamd zaten kuruluysa modülü açmak birkaç satırlık iştir, o yüzden zararı da yoktur.
Kapanış#
ARC, mail dünyasının yönlendirme sorununa verdiği en olgun cevaptır: hiçbir şeyi yeniden yazmadan, sadece "bana geldiğinde şu sonuçları almıştım" bilgisini imzalayarak taşır. Aklında kalması gereken dört şey: SPF yönlendirmede her zaman kırılır ve bu normaldir, DKIM yalnızca içerik değiştiğinde kırılır, ARC mühürü atan tarafın itibarına dayanır ve milter sırasında doğrulayıcılar her zaman ARC'tan önce gelmelidir. cv=fail gördüğün bir zincirin geriye dönük onarılamayacağını da unutma.
Yönlendirme ve liste trafiği taşıyan bir posta altyapısı kuruyorsan tam kontrol sahibi olmak isteyeceksin; VDS ve sanal sunucu paketlerimizde root erişimiyle Rspamd ya da OpenARC kurulumunu kendin yapabilirsin. Hazır yapılandırılmış bir gönderim altyapısını tercih edersen SMTP sunucu paketlerimiz DKIM anahtarı üretilmiş hâlde teslim edilir; kurulum ve bakımı devretmek istersen sunucu yönetimi hizmetimiz bu yapılandırmaları da kapsar.