DMARC: Raporlardan sonra reject’e geçiş

Alan adınız için DMARC’ı kurmadan önce SPF ve DKIM’i etkinleştirin; ardından DNS’te p=none politikası ve rua rapor adresi içeren bir TXT kaydı yayımlayın. Google Workspace kurulum yönergesi, SPF ve DKIM’in önce çalışır hâle getirilmesini, başlangıçta p=none kullanılmasını ve politikanın raporlar incelendikçe sıkılaştırılmasını önerir.

Raporlarda bütün meşru gönderim yollarını tanımadan p=reject’e geçmek, kuruluşunuzun kendi iletilerinin reddedilmesine yol açabilir. Bir bülten ya da fatura hizmeti SPF veya DKIM denetiminden geçse bile görünen From alan adıyla uyum sağlayamıyorsa DMARC denetiminde başarısız olabilir. p=none, alıcıya DMARC nedeniyle engelleme talimatı vermez; alıcının diğer güvenlik filtreleri ise çalışmaya devam eder.

Göndericileri ve alan adı uyumunu kontrol edin

Önce alan adınız adına posta gönderen yolları çıkarın: çalışanların posta hizmeti, web sitesinin otomatik iletileri, destek sistemi, pazarlama aracı ve işlem bildirimleri. Her yol için görünen From alan adını, zarf gönderici alan adını ve DKIM imzasındaki alan adını kaydedin. DMARC’ın geçmesi için SPF ya da DKIM doğrulamasından en az birinin başarılı olması ve başarılı yöntemin alan adının From alan adıyla uyumlu olması gerekir.

SPF kaydında gerçekten kullanılan gönderim hizmetlerinin bulunduğunu ve aynı alan adı için çakışan SPF kayıtları oluşturulmadığını kontrol edin.
DKIM imzalamasının etkin olduğunu, imzadaki alan adının görünen From alan adıyla uyum sağladığını doğrulayın.
Üçüncü taraf hizmetlerin kendi alan adlarıyla gönderim yapıp yapmadığını inceleyin. Gerekirse hizmetin sunduğu özel DKIM alan adını veya özel dönüş adresini yapılandırın.
Posta gönderen alt alan adlarını da listeleyin. Ayrı bir DMARC kaydı bulunmayan alt alan adları, ana alan adının politikasından etkilenebilir.

Her önemli gönderim yolundan örnek bir ileti gönderip üstbilgideki doğrulama sonuçlarına bakın. SPF sonucu başarılıyken zarf gönderici alan adı From alan adıyla uyuşmayabilir; DKIM imzası da geçerli olup başka bir kuruluşun alan adını taşıyabilir. Böyle bir durumda yalnızca “pass” sonucunu görmek, reject politikasına geçmek için yeterli değildir.

_dmarc TXT kaydını yayımlayın

DNS sağlayıcınızda TXT türünde bir kayıt oluşturun. Alan adınızın koşullu olarak example.com olduğunu varsayarsak kayıt adı _dmarc.example.com, değeri ise v=DMARC1; p=none; rua=mailto:[email protected] olabilir. example.com ile rapor adresini kendi bilgilerinizle değiştirin. DNS paneli alan adını kayıt adına otomatik ekliyorsa adın yanlışlıkla iki kez yazılmadığını kontrol edin.

Burada v=DMARC1 kayıt türünü, p=none başlangıç politikasını, rua ise toplu raporların gönderileceği adresi belirtir. Raporlar için erişebildiğiniz ayrı bir posta kutusu seçmek, iletileri günlük yazışmalardan ayırır. Rapor adresi izlenen alan adından farklı bir alan adındaysa raporları alacak alan adının DNS’inde ayrıca yetkilendirme kaydı gerekir. Kaydı kaydettikten sonra herkese açık DNS yanıtında beklediğiniz _dmarc TXT değerinin göründüğünü doğrulayın.

Google Workspace ve Microsoft 365’te kayıt nereye eklenir?

Google Workspace ile kullanılan özel alan adında DMARC kaydı Google yönetici konsoluna değil, alan adının DNS barındırıcısına eklenir. Microsoft 365’te kullanılan özel alan adı için de DMARC TXT kaydının yeri DNS sağlayıcısıdır. Microsoft’un özel alan adı yönergesi, gönderim yapan alan adları ve alt alan adları için önce SPF ile DKIM’in kurulmasını, sonra p=none’dan başlayarak politikanın kademeli sıkılaştırılmasını anlatır.

Bu ayrım özellikle Microsoft 365’in varsayılan onmicrosoft.com alan adıyla özel alan adını karıştırmamak için önemlidir: Varsayılan alan adının kaydı yönetici merkezinden eklenebilirken kuruluşunuza ait özel alan adının DMARC kaydı DNS barındırıcısında yönetilir. Birden fazla özel alan adınız varsa her birinin göndericilerini ve kaydını ayrı kontrol edin.

Toplu raporlarda meşru postayı ayırt edin

rua adresine gelen toplu raporlar genellikle XML verisi taşır. Gönderen IP adresini, o kaynaktan görülen ileti sayısını, From alan adını ve SPF ile DKIM’in DMARC açısından uyum sonuçlarını birlikte okuyun. Kaynağı tanıyorsanız rapordaki IP’yi gönderim envanterinizle eşleştirin; emin değilseniz ilgili hizmetten gönderilmiş bir iletinin üstbilgisini inceleyin. Yüksek başarısızlık sayısı tek başına kaynağın yetkisiz olduğunu göstermez.

Ham SPF sonucu başarılı, DMARC içindeki SPF uyumu başarısız görünüyorsa zarf gönderici alan adı From alan adıyla uyuşmuyor olabilir. DKIM için de benzer ayrım geçerlidir: İmza doğrulanabilir, fakat imzadaki alan adı From alan adıyla uyumlu olmayabilir. Meşru hizmetin ayarını düzelttikten sonra sonraki raporlarda bu gönderim yolunun sonucunu yeniden kontrol edin. Tanımadığınız bir IP’yi yalnızca raporda göründüğü için SPF kaydına eklemeyin.

Rapor gelmiyorsa önce rua adresinin posta alabildiğini ve TXT kaydında doğru yazıldığını kontrol edin. Harici bir raporlama hizmetinin alan adını kullanıyorsanız karşı alan adındaki yetkilendirme kaydını da doğrulayın. Raporlar, her alıcının her ileti için veri göndereceği anlamına gelmez; bu yüzden önemli gönderim yollarından alınan örnek iletilerin üstbilgileri de yararlıdır.

Quarantine ve reject’e kademeli geçin

Meşru göndericiler raporlarda doğru görünmeye başladıktan sonra politikayı p=quarantine olarak değiştirin ve kapsamı küçük tutun. Google’ın kademeli geçiş planı, p=none raporlarının en az bir hafta izlenmesini ve sorun görülmüyorsa quarantine politikasına örneğin pct=10 gibi sınırlı bir kapsamla başlanmasını önerir. pct değeri, bütün postanın değil DMARC denetiminde başarısız olan iletilerin ne kadarına politikanın uygulanacağını belirler.

Quarantine sırasında raporları ve teslimat sorunlarını birlikte izleyin. Meşru bir hizmetin iletileri gereksiz yere spam klasörüne düşüyorsa önce o hizmetin SPF veya DKIM alan adı uyumunu düzeltin, ardından kapsamı artırın. Gönderim yolları sorunsuz çalıştığında p=reject’e geçebilirsiniz. Bu politika alıcıdan başarısız iletiyi reddetmesini ister; alıcının kendi posta işleme kuralları sonucu etkileyebileceği için rapor izlemeyi sürdürün.

Meşru posta etkilenirse politikayı geri alın

Politika değişikliğinin ardından meşru iletiler etkilenirse p veya pct değerini son çalışan düzeye döndürün. DNS değişikliği yayılırken etkilenen hizmetin örnek iletisindeki From, zarf gönderici ve DKIM alan adlarını rapor sonuçlarıyla karşılaştırın. Hizmetteki uyum sorunu giderilip yeni iletiler doğrulandıktan sonra kapsamı yeniden artırın. Önceki DNS değerini ve değişiklik sırasını kaydetmiş olmak, bu geri dönüşü daha hızlı ve kontrollü yapmanızı sağlar.

Ayrıca okuyun: