ARC (Authenticated Received Chain): İletilen E-postalarda SPF/DKIM Sorunu

E-posta güvenlik altyapısının en sık göz ardı edilen noktalarından biri, e-postanın birden fazla sunucu üzerinden geçtiği senaryolardır. SPF ve DKIM doğrudan gönderimde güvenilir biçimde çalışır; ancak bir mailing listesi ya da kurumsal forwarder devreye girdiğinde zincir üç mekanizmanın birlikte çalışmasını bozar, alıcı sunucunun gördüğü e-posta artık orijinal gönderici tarafından imzalanmış değildir. Kimlik doğrulama denetimleri başarısız olur, meşru bir e-posta spam klasörüne düşer ya da reddedilir.

Eğer DMARC politikanızı p=quarantine veya p=reject düzeyine taşıdıysanız, mailing listesi abonelerinize gönderilen iletiler alıcıya hiç ulaşmayabilir. Sorunun kökü, SPF ve DKIM'in iletim zincirini değil yalnızca anlık durumu görmesinde yatar. Her iki mekanizma da "bu e-posta şu an kimden geliyor?" sorusunu sorar, "bu e-posta başlangıçta meşru bir kaynaktan mı çıktı?" sorusunu değil.

ARC (Authenticated Received Chain - Kimlik Doğrulanmış Alınan Zincir), tam da bu noktada devreye girer. Her aracı sunucunun, e-postayı aldığı andaki kimlik doğrulama durumunu kriptografik olarak imzalamasına olanak tanır. Böylece son alıcı sunucu, yalnızca mevcut başarısız durumu değil, zincirin tüm geçmişini inceleyerek daha bilinçli bir karar alabilir.

SPF ve DKIM Forwarder'da Neden Kırılır?

SPF denetimi, gönderici IP adresini hedef domain'in TXT kaydındaki izin listesiyle karşılaştırır. Bir forwarder e-postayı orijinal göndericinin adına ilettiğinde, alıcı sunucuya ulaşan SMTP bağlantısı forwarder'ın IP adresinden gelir. Bu IP, orijinal domain'in SPF kaydında yer almaz; dolayısıyla denetim başarısız olur ya da softfail döndürür.

DKIM farklı bir mantıkla çalışır. İmza, e-postanın belirli başlıklarını ve gövde içeriğini kapsar; RFC standardı, göndericinin belirlediği h= parametresindeki başlıklara dayanır. Mailing listelerinin büyük çoğunluğu List-Unsubscribe başlığı ekler, konu satırına liste adını yerleştirir ya da gövdeye abonelik çıkış bağlantısı koyar. Bu değişikliklerden herhangi biri DKIM imzasını geçersiz kılar.

İki başarısızlık birlikte gerçekleştiğinde DMARC politikası devreye girer. Orijinal gönderici p=reject ya da p=quarantine kullanıyorsa, alıcı sunucu e-postayı reddedebilir veya spam klasörüne yönlendirebilir. DNS kaynaklı iletim sorunları çoğu zaman bu iletim zinciri kırılmalarından kaynaklanır; ancak hata iletisi her zaman doğrudan SPF veya DKIM başarısızlığına işaret etmeyebilir.

ARC Nedir, Hangi Problemi Çözer?

ARC, 2019 yılında RFC 8617 ile standardize edilmiş bir e-posta kimlik doğrulama mekanizmasıdır. Temel fikir basittir: her aracı sunucu, e-postayı teslim aldığı sıradaki kimlik doğrulama sonuçlarını imzalar ve bu imzayı başlıklara ekler. Son alıcı sunucu bu zinciri inceleyerek e-postanın meşru bir aracı tarafından mı işlendiğini, yoksa kötü niyetli bir değişikliğe mi uğradığını değerlendirebilir.

ARC bir güven protokolüdür. Bir aracı sunucunun imzası alıcıya şunu söyler: "Bu e-postayı aldığımda kimlik doğrulama sonuçları şöyleydi, içeriği bu şekilde işledim ve tüm süreci imzalıyorum." Alıcı sunucu bu imzaya güvenip güvenmemeye kendisi karar verir.

Kritik bir ayrım: ARC, SPF ya da DKIM başarısızlığını ortadan kaldırmaz. Başarısız sonuçları silmez; neden başarısız olduğuna dair bağlam sunar. Alıcı sunucu bu bağlamı kullanarak daha isabetli bir karar alabilir, ancak nihai karar yine alıcı sunucunun politikasına bağlıdır. Bu nedenle ARC'ı "SPF sorunlarını çözen bir araç" olarak değil, "iletim geçmişini taşıyan bir altyapı" olarak değerlendirmek daha doğrudur.

ARC'ın Üç Başlık Bileşeni

ARC, her aracı sunucunun eklediği üç başlıktan oluşur. Her başlık zincirdeki sıra numarasını (i=1, i=2 gibi) taşır ve bu numaralar birlikte tutarlı bir zincir oluşturur.

ARC-Authentication-Results (AAR): E-postayı aracı sunucunun teslim aldığı andaki SPF, DKIM ve DMARC sonuçlarını kaydeder. Bir sonraki aracı sunucu bu başlığa bakarak, e-postayı devralırken hangi durumla karşılaştığını öğrenir.

ARC-Message-Signature (AMS): DKIM imzasına benzer bir yapıdır; aracı sunucunun e-posta başlıklarını ve gövdesini imzalamasını sağlar. Zincirin sonraki halkasına içeriğin değişmediğini kanıtlar.

ARC-Seal (AS): Tüm ARC başlıklarını kapsar ve zincirin bütünlüğünü korur. Önceki bir ARC-Message-Signature veya ARC-Authentication-Results başlığı değiştirilirse, ARC-Seal doğrulaması başarısız olur.

Bir e-posta birden fazla aracıdan geçerse her aracı kendi sıra numarasıyla bu üç başlığı ekler; zincir katman katman büyür. Alıcı sunucu zincirin tamamını doğrular ve yalnızca güvendiği aracılardan gelen zincir halkalarına itibar eder.

Mailing Listesi Senaryosu: Adım Adım

Mailing listeleri, ARC'ın en yaygın kullanım alanıdır. Bir kullanıcı [email protected] adresine üye olmuş ve bu liste her üyeye gönderilen iletileri dağıtıyor. Orijinal gönderici DKIM ile imzalanmış bir e-posta gönderir. Liste sunucusu bu e-postayı alır, başlık ekler, konu satırını değiştirir ve her üyeye iletir.

Orijinal DKIM imzası, liste sunucusunun bu değişiklikleri yapmasıyla geçersiz hale gelir. Liste sunucusu ARC destekliyorsa şunu yapar: e-postayı aldığı sıradaki kimlik doğrulama sonuçlarını ARC-Authentication-Results başlığına yazar, içeriği ARC-Message-Signature ile imzalar, zinciri ARC-Seal ile mühürler ve değiştirilmiş e-postaya kendi DKIM imzasını ekler.

Son alıcı sunucu, liste sunucusunun DKIM imzasını doğrular ve ARC zincirini inceleyerek orijinal e-postanın güvenli bir kaynaktan geldiğini görür. Bu senaryonun çalışması için alıcı sunucunun liste sunucusunu güvenilir bir ARC imzalayan olarak tanıması gerekir. Microsoft 365 e-posta altyapısı ve Gmail bu değerlendirmeyi kendi güven listelerine göre otomatik olarak yapar.

Kurumsal E-posta Yönlendirme Senaryosu

Birçok şirket, ayrılmış çalışanların kurumsal adreslerini kişisel adreslerine yönlendirir ya da birden fazla servis arasında e-posta aktarımı yapar. Bu kurulumlar mailing listelerinden daha az görünür olmakla birlikte aynı SPF/DKIM sorunlarına yol açar.

Forwarder bir e-postayı ilettiğinde MAIL FROM (zarf gönderici) adresi değişebilir; ancak From: başlığı olduğu gibi kalır. SPF zarf adresine bakarak çalışır, DMARC ise SPF ve DKIM sonuçlarının From: başlığıyla hizalanmasını denetler. Bu iki katman arasındaki uyumsuzluk DMARC başarısızlığına yol açar. Hizalama neden önemlidir? Çünkü DMARC, gönderim altyapısının meşruiyetini yalnızca gözle görülen gönderici adresiyle ilişkilendirerek değerlendirir.

ARC bu senaryoda forwarder'ın iletim anındaki durumu kaydetmesine olanak tanır. Ancak kurumsal forwarder'ların büyük bölümü henüz ARC desteği sunmuyor. Bu durumda SRS (Sender Rewriting Scheme) tamamlayıcı bir çözümdür: zarf gönderici adresini yeniden yazar ve SPF kontrolünün forwarder'ın kendi domain'ine göre yapılmasını sağlar. SRS ve ARC birbirini dışlamaz; birlikte uygulandığında iletim güvenilirliği önemli ölçüde artar.

ARC Zinciri Ne Zaman Geçerli Sayılır?

Alıcı sunucunun ARC zincirine itibar etmesi için birkaç koşulun bir arada sağlanması gerekir. Zincir bütünlüğü bozulmamış olmalıdır; tüm ARC-Seal başlıkları doğrulanabilir durumda olmalıdır. Zincirin ilk halkası (i=1), e-postayı ilk işleyen sunucuya aittir ve bu sunucunun imzası geçerli olmalıdır. Son koşul çoğu zaman göz ardı edilir: alıcı sunucu, zincirdeki aracı sunucuları güvenilir olarak tanımalıdır.

Güvenilir aracı kavramı burada belirleyicidir. ARC herhangi bir sunucunun zincire girip geçmiş kimlik doğrulama başarılarını taşımasına teknik olarak izin verse de alıcı sunucular yalnızca kendi güven listelerindeki aracılara itibar eder. Kötü niyetli bir sunucu ARC başlıkları eklese bile, alıcı sunucu bu sunucuyu tanımadığı sürece o başlıklar görmezden gelinir.

ARC güveni yaratmaz; mevcut güveni iletim zinciri boyunca taşır. Bu nedenle küçük ölçekli forwarder kurulumlarında ARC sınırlı fayda sağlayabilir. Alıcı sunucu sizin forwarder'ınızı bilmiyorsa, zincir büyük ihtimalle dikkate alınmaz. Büyük sağlayıcılar (Gmail, Microsoft, Yahoo gibi) kendi ağlarına dahil olan güvenilir aracıları tanıdığından, ARC bu sağlayıcılar arasındaki iletişimde çok daha etkilidir.

Hangi Taraf ARC'ı Uygulamalı?

ARC'ın uygulanması büyük ölçüde aracı sunucu tarafına düşer. Orijinal gönderici ya da son alıcı olarak ARC başlığı eklemeniz gerekmez; bu, e-postayı işleyen aracı sunucunun sorumluluğundadır.

Kendiniz bir mailing listesi ya da e-posta yönlendirme servisi işletiyorsanız, kullandığınız e-posta sunucusunun ARC desteğini etkinleştirmeniz gerekir. Postfix için openarc paketi, rspamd ve milter tabanlı çözümler yaygın tercihler arasındadır. Yapılandırma, DKIM kurulumuna benzer şekilde bir özel anahtar ve ilgili bir DNS TXT kaydı gerektirir. Bu kaydın TTL değerini düşük tutmak (örneğin 300 saniye), anahtar rotasyonu sırasında sorun yaşamamanızı kolaylaştırır.

Son alıcı olarak ARC değerlendirmesi yapıyorsanız, güven politikanızı tanımlamanız gerekir. Google Workspace e-posta kurulumunda bu değerlendirme otomatik olarak gerçekleşir; bireysel yapılandırmaya gerek kalmaz. Kendi posta sunucunuzu yönetiyorsanız, hangi aracı sunucuları güvenilir kabul ettiğinizi ve ARC zincirinin DMARC başarısızlığını nasıl etkileyeceğini belirlemeniz gerekir.

ARC, e-posta iletim altyapısının karmaşıklığını kabul eden ve buna göre tasarlanmış bir standarttır. SPF ve DKIM doğrudan iletişimde işe yarar; ARC ise bu modeli çok adımlı iletim senaryolarına genişletir. Ekosistem henüz tam olgunluğa ulaşmamış olsa da büyük sağlayıcılar arasındaki destek giderek yaygınlaşmakta ve mailing listesi ya da forwarder kaynaklı iletim sorunları giderek daha öngörülebilir hale gelmektedir.

Mailing listesi ya da forwarder kaynaklı DMARC hatalarıyla karşılaştığınızda, aracı sunucunun ARC desteğini kontrol etmek ilk adım olmalıdır. ARC destekleniyorsa ve zincir doğru kurulmuşsa, büyük sağlayıcılar iletimi meşru olarak değerlendirme eğilimindedir. ARC desteklenmiyorsa, SRS ile birlikte DMARC politikasını p=none modunda tutmak kısa vadeli bir geçici çözüm olabilir; ancak farklı posta altyapılarında bu geçici çözümün davranışı değişebilir ve uzun vadede politika gevşekliği kendi güvenlik risklerini doğurur.