[ Platform kılavuzları ]

Google Workspace grupları ve yönlendirme: gerçek mesaj yolunu test edin

Orijinal kimlik doğrulama sonucunun hayatta kalacağını varsaymadan Google Workspace grubunu ve yönlendirme yollarını izleyin.

EmailAuth araştırma ekibi tarafından · 4 dakikalık okuma

[ Anahtar noktalar ]

  • Orijinal kimlik doğrulama sonucunun hayatta kalacağını varsaymadan Google Workspace grubunu ve yönlendirme yollarını izleyin.
  • Yalnızca teslimat durumunu değil, önceki ve sonraki kimlikleri de karşılaştırın.
Bu sayfada

Bir Workspace posta kutusuna veya grubuna teslim edilen bir mesaj, son okuyucusuna ulaşmadan önce ikinci bir yolculuğa çıkabilir. Bir sonraki alıcı şunu görür: yönlendirme sistemin bağlantısı ve mesaj değişmiş olabilir. İdealleştirilmiş bir doğrudan dağıtım örneğini değil, mevcut yolu test edin.

DNS incelemeden önce yolu çizin

Orijinal göndereni, ilk Workspace alıcısını veya grubunu, her genişletme veya iletme eylemini ve son harici alıcıyı kaydedin. Posta kutusu yönlendirme kuralını, grup dağıtımını ve yönlendirme kuralını ayırt edin. Grubun konuyu, alt bilgiyi, Kimden alanını veya yanıt davranışını değiştirip değiştirmediğine dikkat edin. Bunlar, her Google Grubuna ilişkin evrensel iddialar değil, gerçek ayarlarınızdan ve mesajlarınızdan toplanacak gözlemlerdir.

Mümkün olduğunda ve ham son mesajı iletmeden önce bir kopyasını saklayın. Bunları mesaj tanımlayıcılara ve zaman damgalarına bağlayın, böylece yeni bir tanımlayıcı oluşturan bir aracıya olanak tanıyın. Teslimat reddedilirse arıza bildiriminin tamamını kaydedin. Genel bir geri dönme etiketi, başarısız olan kimlik doğrulama mekanizmasını tanımlayamaz.

Belgelenen Google Grupları kontrollerini inceleyin

Google'ın Gruplar ayarları, Gönderim politikaları altındaki varsayılan gönderen belgelerine referans verir; seçenekler olarak yazarın veya grubun adresi ve ayrı bir Grup olarak gönderi paylaşabilecek kişi izni bulunur. Her posterin grup kimliğini kullanabileceğini varsaymak yerine her iki ayarı da kaydedin. Bu, sizin özel teslimatınızın ürettiği Kimden alanını değil, mevcut kontrolü doğrular.

Bir sahip veya yönetici Grup ayarlarını ve ardından E-posta seçeneklerini inceleyebilir. Google, Konu öneki kontrolünü ve standart veya özel E-posta altbilgisi seçeneklerini belgeler. Onaylı bir testten önce mevcut değerlerini koruyun; Kontrollü bir grupta her seferinde bir ayarı değiştirin. Ayrı Gönderi yanıtları seçeneği, varsayılan yanıt alıcılarını kontrol eder, DMARC hizalama. Ürüne özgü bu özellikler, test planının neden konu, beden ve kimlik karşılaştırmalarını içerdiğini açıklıyor.

Google'ın altbilgi talimatları, Gmail gruptan alınan bir iletinin incelenmesi gerektiğini söylüyor: altbilgi, Gruplar ileti dizisi görünümünde, Gmail Gönderilenler klasöründe veya Cc'lendiğiniz bir kopyada gösterilmez. Kimlik doğrulama analizi için ayrıca amaçlanan dağıtım yolundan teslim edilen son ham mesajı saklayın. Altbilgiyi içermeyen bir ekran, herhangi bir değişiklik yapılmadığının kanıtı olarak algılanmamalıdır. Bu resmi talimatlar özellik modelini oluşturur; yalnızca önceki ve sonraki mesajlar belirli bir imzalı alanın değişip değişmediğini ve hangi imzanın hayatta kaldığını belirleyebilir.

SPF onarımını orijinal alan hizalamasından ayırın

Yönlendirme, son alıcıya bağlanan IP'yi değiştirir. Orijinal etki alanının SPF politika bu aracıya yetki vermeyebilir. Google'ın alıntı yapılan yönlendirme kılavuzu özellikle Gmail iletilen postalara yöneliktir. Bu, Google Grupları'nın giden varsayılanlarının bir özelliği değildir. Bu yönlendirme yolunu işleten yöneticiler için, Zarf göndereni bir yönlendirme alanı kimliğine ve bu alanın SPF politikasında yönlendirme hizmetine yetki verilmesine. Bu, yönlendirme kimliğinin SPF sonucunu, orijinal görünür Kimden alanıyla hizalamadan onarabilir.

Mümkün olan her yönlendirme hizmetini orijinal gönderenin servisine eklemeyin. SPF kaydı. Bu etki alanını kontrol edemeyebilirsiniz ve değişiklik, orijinal gönderme yetkilendirmesini aşağı yönde yönlendirmeyle karıştırır. İletici, gönderenin yeniden yazılmasını sağlıyorsa, belirli bir uygulamayı varsaymak yerine desteklenen davranışını onaylayın ve ortaya çıkan kimliği test edin.

Hayatta kalan bir DKIM yolunu koruyun

Değişiklikler geçersiz kılabileceğinden Google, imzalı başlıklarda ve gövde içeriğinde değişiklik yapmaktan kaçınmanızı önerir. DKIM. Orijinal imzanın d= alanını inceleyin, seçici ve son atlamadan sonra alıcı sonucu. İletim hizmetinden gelen ikinci bir imza, orijinal yazarın Kimden alan adıyla otomatik olarak hizalanmaz.

ARC, veya Kimliği Doğrulanmış Alınmış Zincirmevcut olduğunda, aracılar aracılığıyla ön kimlik doğrulama değerlendirmesini gerçekleştirir. İletilen her mesajı bir DMARC geçişine dönüştürmez veya alıcıyı zincire güvenmeye zorlamaz. ARC sonuçlarını ve son alıcının kararını ayrı ayrı kaydedin. Google, iletilen iletiler üzerinde açıkça kendi kimlik doğrulama kontrollerini gerçekleştirir.

Üç kontrollü vakayı karşılaştırın

Bu orijinal test matrisi, gözlemlenen Google sonuçlarını değil, beklenen mantığı açıklar. Yetkili bir gönderen etki alanı ve kontrollü grup ve gelen kutuları kullanın.

  • Durum: Doğrudan kontrol; Neler değişir: Grup veya iletme adımı yok; Ne karşılaştırılmalı: Temel SPF , DKIM ve DMARC kimlikleri.
  • Durum: Değiştirilmemiş ileri; Neler değişir: IP'yi ve muhtemelen zarfı bağlamak; Ne karşılaştırılmalı: Orijinalin hizalanıp hizalanmadığı DKIM imzası hayatta kalır.
  • Vaka: Grupla genişletilmiş mesaj; Neler değişir: Gerçek yapılandırılmış grup dönüşümleri; Karşılaştırmalı olanlar: İmzalı içerik bütünlüğü, görünür Kimden, tüm imzalar ve ARC .

Örneğin, Kimden'in author@example.com olduğunu, bir ileticinin zarfı forwarding.example.net yeniden yazdığını ve SPF oradan geçtiğini varsayalım. Orijinal d=example.com imzası geçerli kalırsa DMARC hizalaması sağlayabilir. Bu imza başarısız olursa ve kalan tek geçerli imza d=example.net, listelenen yolların hiçbiri example.com ile aynı hizada değildir. Bu çizimde hiçbir ek hizalanmış imza varsayılmamaktadır; alıcı yine de kendi yerel tasarruf politikasını uygulayabilir.

Sorumlu en küçük bileşeni düzeltin

Bir altbilgi hayatta kalan imzayı bozarsa, bu dönüşümü veya sağlayıcı tarafından desteklenen grup davranışını gözden geçirin. Görünen Kimden kimliği kasıtlı olarak yeniden yazıldıysa, yeni kimlik için kimlik doğrulamayı ve sunumun hâlâ grubun amacına hizmet edip etmediğini değerlendirin. Tek bir dağıtım yolunun teslim edilmesini sağlamak için etki alanı korumasını genel olarak devre dışı bırakmayın.

Yol şemasını, ayarların revizyonunu, düzeltilmiş öncesi ve sonrası başlıklarını ve nihai sonucu saklayın. Grup ayarı değişiklikleri, yönlendirme güncellemeleri, yeni ağ geçitleri, imza rotasyonu veya alıcı sağlayıcının politika değişikliği sonrasında karşılaştırmayı yeniden çalıştırın. Kimlik doğrulama sonuçları teslimatın bir girdisidir; Şikayet ve suiistimal kontrolleri, teknik zincir geçerli olsa bile hâlâ önemlidir.

Minimum karşılaştırma kaydını tutun

Kontrol edilen her yol için ayarların revizyonunu, orijinal ve son mesaj tanımlayıcılarını, UTC zamanlarını, görünür Kimden, zarf kimliğini, tüm DKIM imzalayanları ve güvenilir alıcı sonuçlarını kaydedin. Kanıtın izin verdiği ölçüde, değiştirilen alanı veya vücut bölgesini kesin olarak ekleyin. Kullanılamayan bir ön iletme kopyası için ayrı bir bilinmeyen alan tutun. Eksik bir orijinal, mesajı hangi aracının değiştirdiğini belirleyemez.

[ Götürmek ]

Yalnızca teslimat durumunu değil, önceki ve sonraki kimlikleri de karşılaştırın.

[ Role göre ]

Bu sizin için ne anlama geliyor?

Sonraki pratik adımlar için rolünüzü seçin.

BT / Posta Yöneticisi

Atlama dizisinin tamamını izleyin

Orijinal pas nihai sonuç değildir.

Sonraki adımlar

  1. Doğrudan ve genişletilmiş mesajları karşılaştırın.
  2. Her bir DKIM kimliğini ve tüm ARC kanıtlarını kaydedin.
  3. Genişletmeden önceki ve sonraki görünen gerçekleri karşılaştırın.

CISO / SecOps

Geniş kimlik doğrulama istisnalarından kaçının

Tek bir yönlendirme hatası, her etki alanı göndericisini zayıflatmamalıdır.

Sonraki adımlar

  1. Kapsamlı bir iyileştirme planı gerektirir.
  2. Güvenilir aracı kararları DMARC geçişinden ayrı olarak inceleyin.
  3. İstisna kararlarını zaman sınırlı ve sahiplenilmiş halde tutun.

Kurucu / Teknik Olmayan

Dağıtım yollarını görünür tutun

Bir grup, iş açısından kritik bir iş akışının parçası olabilir.

Sonraki adımlar

  1. Grup sahibini ve harici alıcıları adlandırın.
  2. Bildirimlerde ve yönlendirmede yapılan değişikliklerden sonra test edin.
  3. Önemli dağıtım iş akışları için doğrudan teslimat kontrolünü elinizde tutun.

[ SSS ]

Sık sorulan sorular

SPF neden yalnızca iletme sonrasında başarısız olabiliyor?

Son alıcı, orijinal gönderenin IP'si yerine ileticinin bağlantı IP'sini görür.

Zarfın yeniden yazılması DMARC geçişini garanti ediyor mu?

Hayır. İleticinin etki alanını, bu etki alanını orijinal Gönderen adresiyle hizalamadan doğrulayabilir.

DKIM yönlendirmeden sağ çıkabilir mi?

Evet, ilgili imzalı içerik ve anahtar doğrulama geçerli kaldığı sürece.

Bir grup her zaman DKIM bozar mı?

Hayır. Söz konusu grup için gerçek dönüşümleri ve alınan imza sonuçlarını inceleyin.

ARC alıcıyı postayı kabul etmeye zorluyor mu?

Hayır. ARC kanıtları, alıcının güven ve işleme politikası kapsamında değerlendirilir.

SPF tüm ileticilere yetki vermeli miyiz?

Hayır. Orijinal gönderme yetkisini aşağı yönde iletme davranışından ayırın.

Test neyi korumalıdır?

Kontrollü doğrudan ve iletilen örnekler, grup ayarları, tanımlayıcılar, zaman damgaları ve nihai alıcı sonuçları.

Küresel DMARC notunun düşürülmesi ne zaman gerekçelendirilir?

Bunu varsayılan yönlendirme düzeltmesi olarak kullanmayın. Ayrı olarak onaylanmış bir politika değişikliğini değerlendirmeden önce belirli yolu teşhis edin ve düzeltin.

[ Kaynaklar ]

Kaynaklar

  1. E-postaları Gmail yönlendirmeye yönelik en iyi uygulamalar

    Bölümler Yöneticiler ve gönderenler için e-posta iletme

  2. RFC 9989 : Etki Alanı Tabanlı İleti Kimlik Doğrulaması, Raporlama ve Uyumluluk ( DMARC )

    Bölümler Tanımlayıcı hizalaması · Politika ve alıcı yönetimi

  3. RFC 6376 : Etki Alanı Anahtarlarıyla Tanımlanan Posta

    Bölümler İmzalama ve doğrulama

  4. RFC 7208 : Gönderen Politikası Çerçevesi

    Bölümler MAIL FROM kimlik · DNS arama sınırları

  5. Bir grup oluşturun ve grup ayarlarını seçin

    Bölümler Gönderme politikaları · E-posta seçenekleri

  6. Grup e-posta iletilerine alt bilgi ekleme

    Bölümler Bir grup için alt bilgiyi ayarlama · Alt bilgiyi görüntüleme

  7. Grup mesajlarının konu satırlarına önek ekleyin

    Bölümler Bir önek ekle

  8. RFC 8617 : Kimliği Doğrulanmış Alınan Zincir ( ARC ) Protokolü

    Bölümler §7.2.1 DMARC Yerel Politikayı Geçersiz Kılmalar · §9.3 Mesaj İçeriği Şüphesi · §9.4 Mesaj Kapatıcı Şüphesi

[ Sözlük ]

Sözlük

Yönlendirme
Bir mesajı kabul etmek ve onu başka bir hedefe iletmek.
ARC
Aracılar arasında kimlik doğrulama değerlendirmelerini ileten Kimliği Doğrulanmış Alınmış Zincir.
Zarfın yeniden yazılması
Daha sonraki bir iletimde kullanılan SMTP gönderen kimliğinin değiştirilmesi.

Kurumsal menşe

Neden en iyi finans kurumları ve hükümetler e-posta güvenlik kontrol panellerini kullanımdan kaldırdı.

Geleneksel e-posta kimlik doğrulama platformları size bir gösterge tablosu satar ve mühendislerinizden bu işi yapmalarını ister. Riskli ortamlarda, manuel gözetim, gecikmeli uygulama, konfigürasyon kayması ve izlenmeyen gölge alanlar anlamına gelir.

EmailAuth aracılı e-posta kaynak platformudur. Temsilcilerimiz uyguluyor p=reject, üçüncü taraf gönderenleri uyumlu tutun ve alan adlarınızı tam sürüme taşıyın RFC 9989 döngüdeki insan tarafından denetlenebilirliğe sahip yeni DMARC standardı uyumluluğu.

Hükümetler Büyük işletmeler 1. Seviye finans kurumları

SaaS · Özel kiracılık · Şirket içi hava boşluklu · BYOK şifrelemesi

Bilgi Bankası