ARC: Yönlendirilen (Forward) Mailde Kimlik Neden Kırılır ve Nasıl Korunur?

DMARC yazımızda bir kural koymuştuk: alan adınızın DMARC'ını reject'e alın, sizin adınıza sahte mail atılamasın. Doğru bir kural — ama bir yan etkisi var ve bu yan etki, meşru maillerinizin bazılarının reddedilmesine yol açabilir. Suçlu, günlük hayatta hepimizin kullandığı masum bir işlem: e-posta yönlendirme (forwarding). Bir mail bir posta listesinden geçtiğinde ya da bir hesaptan başka bir hesaba otomatik iletildiğinde, SPF ve çoğu zaman DKIM kırılır — ve DMARC, gerçekte meşru olan bir maili "sahte" sanıp reddedebilir.

Mail Teknolojileri Serimizin bu dördüncü yazısında, tam bu sorunu çözmek için tasarlanmış standardı ele alıyoruz: ARC (Authenticated Received Chain — Doğrulanmış Alınan Zinciri). ARC, yönlendirme sırasında kırılan kimlik doğrulama sonucunu "mühürleyerek" bir sonraki sunucuya güvenilir biçimde taşır. Amaç yine aynı: hiç teknik olmayan bir yöneticinin bile "meşru maillerim neden bazen reddediliyor, ARC bunu nasıl çözüyor" sorusuna net cevap bulması.

1. Önce Sorun: Yönlendirme SPF ve DKIM'i Neden Kırar?

İlk yazımızda anlattığımız üç mekanizmanın forwarding karşısındaki durumu farklıdır:

• SPF neredeyse her zaman kırılır: SPF, "bu maili gönderen sunucunun IP'si, gönderen alan adı için yetkili mi?" diye bakar. Mail A→B→C diye yönlendirildiğinde, C'ye ulaşan maili artık B'nin sunucusu göndermiştir; ama SPF hâlâ orijinal alan adının izinli IP'lerine bakar. B'nin IP'si o listede olmadığı için SPF fail verir.
• DKIM çoğu zaman korunur — ama her zaman değil: DKIM içeriği imzalar, IP'ye bakmaz; bu yüzden basit yönlendirmede genelde ayakta kalır. Ancak posta listeleri konu satırına etiket ekler ("[Liste] ..."), altbilgi (footer) yapıştırır ya da içeriği değiştirirse, imza bozulur ve DKIM de fail verir.
• DMARC ikisine birden bakar: DMARC'ın geçmesi için SPF ya da DKIM'in geçmesi ve hizalı (aligned) olması gerekir. Yönlendirmede SPF zaten kırıksa ve DKIM de bir liste tarafından bozulmuşsa — DMARC fail, mail reddedilir. Oysa mail tamamen meşrudur.

Kısacası: DMARC reject, doğru kural; ama forwarding onu meşru maillere karşı da tetikleyebilir. ARC bu boşluğu kapatır.

2. ARC Ne Yapar? "Ben Doğruladım, Bana Güven" Zinciri

ARC'ın fikri şu: bir ara sunucu (posta listesi, forwarding hizmeti, güvenlik ağ geçidi) maili aldığında, o an kimlik doğrulamanın (SPF/DKIM/DMARC) sonucunu görür — henüz kırılmamıştır. ARC, bu "temiz" sonucu bir mühürle (ARC-Seal) maile ekler ve şunu der: "Ben bu maili aldığımda kimlik doğrulaması geçiyordu; bunu ben imzalayarak garanti ediyorum."

Mail bir sonraki durağa gittiğinde, orada SPF/DKIM kırılmış olsa bile, alıcı sunucu ARC mührüne bakar: "Bu maili yönlendiren güvenilir aracıyı tanıyorum ve o, mailin kaynağında meşru olduğunu doğrulamış. O halde forwarding yüzünden kırılan SPF/DKIM'e rağmen bu maili kabul edebilirim." ARC, kırılan kimlik zincirinin orijinal halkasını koruyup taşır.

ARC üç bileşenden oluşur (kavramsal)

• ARC-Authentication-Results: Aracının, maili aldığı andaki SPF/DKIM/DMARC sonucunu kaydeder.
• ARC-Message-Signature: Mailin o anki içeriğini (DKIM benzeri) imzalar.
• ARC-Seal: Önceki tüm ARC başlıklarını mühürleyerek zincirin bütünlüğünü garanti eder; her yeni durak zincire kendi mührünü ekler.

3. Kritik İncelik: ARC "Güven" Değil, "İz" Sağlar

ARC'ı yanlış anlamanın en yaygın yolu, onu sihirli bir "her zaman kabul et" düğmesi sanmaktır. Değildir. ARC yalnızca güvenilir bir aracının mührü olduğunda işe yarar — alıcı sunucu, ARC mührünü koyan tarafın güvenilirliğine karar verir. Bilinmeyen ya da güvenilmeyen bir aracının ARC mührü, tek başına maili kurtarmaz. Yani ARC, "bu maili yönlendiren aracıya güveniyor musun?" sorusunu sorulabilir hale getirir; cevabı otomatik "evet" yapmaz.

Bu yüzden ARC, büyük ve güvenilir aracılar (Microsoft 365, Google Workspace, büyük posta listesi hizmetleri, kurumsal e-posta güvenlik platformları) arasında en çok değer üretir — çünkü alıcı sunucular bu aktörlerin mühürlerine güvenmeye yatkındır.

4. Pratikte Ne Zaman Karşınıza Çıkar?

• Posta/dağıtım listeleri: "info@", "duyuru@" gibi listelerden geçen mailler konu/footer değişikliğiyle DKIM'i kırabilir; ARC bunları kurtarır.
• Otomatik yönlendirme: Çalışanların kurdukları "gelen her maili şu adrese ilet" kuralları (dikkat: ATO yazımızda bunların kötüye de kullanıldığını gördük).
• Güvenlik katmanları arası akış: Mail bir güvenlik hizmetinden geçip Microsoft 365'e ulaştığında, aradaki katmanın ARC mührü, DMARC değerlendirmesinin doğru çalışmasını sağlar.
• DMARC'ı reject'e çekerken: reject'e geçmeden önce, meşru forwarding senaryolarınızın ARC ile korunduğundan emin olmak, yanlışlıkla meşru mail kaybını önler.

5. Kurum Olarak Ne Yapmalısınız?

İyi haber: ARC'ı çoğu zaman siz elle kurmazsınız. Microsoft 365 ve Google Workspace gibi büyük platformlar ARC'ı yerleşik olarak destekler ve gelen maillerde ARC mühürlerini otomatik değerlendirir. Sizin göreviniz daha çok doğru yapılandırma ve doğru sıralama:

• DMARC yolculuğunu doğru sırayla yapın: Önce p=none ile raporları izleyin (DMARC yazımızdaki gibi), meşru forwarding kaynaklarınızı raporlarda görün, ARC'ın bunları koruduğunu doğrulayın, sonra quarantine ve reject'e ilerleyin. Kör bir reject geçişi, forwarding'i olan kurumlarda meşru mail kaybettirir.
• Güvenilir aracıları tanıyın: Hangi listelerin, hangi hizmetlerin mail akışınıza dahil olduğunu bilin; DMARC raporları bunu görünür kılar.
• Katmanları uyumlu seçin: Kullandığınız e-posta güvenlik platformunun ARC'ı doğru işlediğinden emin olun — aksi halde güvenlik katmanının kendisi meşru mailleri kırabilir.

Check Point Harmony Email & Collaboration API tabanlı mimarisiyle Microsoft 365 / Google Workspace'in ARC değerlendirmesiyle uyumlu çalışır; gelen mailleri kimlik doğrulama zincirini bozmadan analiz eder ve DMARC yolculuğunuzu (none→reject) raporlarla yönetmenize yardımcı olur.

Sıkça Sorulan Sorular

ARC'ı ayrıca kurmam gerekiyor mu?

Çoğu kurum için hayır. Microsoft 365 ve Google Workspace ARC'ı yerleşik destekler ve gelen maillerde otomatik değerlendirir. Sizin işiniz, DMARC'ı doğru sırayla (none→reject) ilerletmek ve meşru forwarding kaynaklarınızın raporlarda korunduğunu doğrulamaktır.

ARC, DMARC'ın yerine mi geçiyor?

Hayır — ARC, DMARC'ı tamamlar. DMARC "gönderen gerçek mi" sorusunu sorar; ARC, forwarding yüzünden bu sorunun yanlışlıkla "hayır" cevabı almasını önler. İkisi birlikte, hem sahte mailleri engeller hem meşru yönlendirilmiş mailleri korur.

ARC olan her mail otomatik kabul mü edilir?

Hayır. ARC mührü yalnızca güvenilir bir aracıdan geliyorsa değer taşır. Alıcı sunucu, mührü koyan tarafa güvenip güvenmeyeceğine karar verir; bilinmeyen bir aracının ARC mührü tek başına maili kurtarmaz. ARC güven sağlamaz, güvenin değerlendirilebileceği bir iz sağlar.

DMARC'ı reject'e çekince meşru maillerim reddedilmeye başladı; ne yapmalıyım?

Klasik forwarding sorunu. DMARC raporlarınıza bakıp hangi kaynağın (hangi liste/forwarding hizmeti) fail verdiğini bulun; o kaynağın ARC ile korunup korunmadığını ve güvenilir bir aracı olup olmadığını değerlendirin. Genellikle çözüm, reject'e geçmeden önce bu kaynakları raporlarla haritalamaktır — bizim saha denetimimiz tam da bunu yapar.

Şimdi Ne Yapmalı?

DMARC'ı reject'e çekmeyi planlıyor ya da çektikten sonra meşru mail kaybı yaşıyorsanız, ARC ve forwarding haritanız kritik. İki soruyla başlayın: (1) Mail akışınızda hangi meşru forwarding/liste kaynakları var? (2) DMARC'ı sıkılaştırdığınızda bunlar korunuyor mu?

1. Ücretsiz Saha Denetimi: DMARC raporlarınızı okur, meşru forwarding kaynaklarınızı haritalar ve reject'e güvenli geçiş yolunu çıkarırız.
2. Yönetilen DMARC yolculuğu: none→quarantine→reject geçişini, meşru mail kaybı olmadan, ARC uyumuyla birlikte yönetiriz.

Tanışma toplantısı planlayın

Bu yazı hakkında: Mail Teknolojileri Serimizin dördüncü yazısıdır; ilk yazıdaki SPF/DKIM/DMARC temelinin üzerine, forwarding senaryosunu ekler. Bir sonraki yazı, e-posta başlıklarını okuma rehberini ele alacak. Kinetik Bilişim, Check Point Software Technologies'in Advanced Partner 2026 seviyesindeki Türkiye iş ortağıdır; Email, Endpoint & Browser, Mobile ve SASE Solution Specialization akreditasyonlarına sahiptir. Yazar Kemal Özleyen, Check Point Workspace Security Expert sertifikalı bir siber güvenlik mühendisidir.