DMARC politikası: none, quarantine mı, reject mi?

Her DMARC politikası ne yapar?

Bir DMARC kaydı, domain düzeyinde bir politika yayınlar. p=none ile alıcı sistemden, uygulama yapmadan hataları izlemesi istenir. p=quarantine ile doğrulamadan geçemeyen e-posta şüpheli sayılır. p=reject ile alıcı sistemden doğrulamadan geçemeyen e-postayı reddetmesi istenir.

Politika, her alıcının aynı şekilde davranacağının garantisi değildir. SPF ve DKIM hizalama kontrolleriyle birlikte çalışan, herkese açık bir talimattır.

p=none neden koruma anlamına gelmez?

p=none, domain adına hangi sistemlerin meşru olarak e-posta gönderdiğini öğrendiğiniz dönemde işe yarar. Uygulayan bir politikanın geçerli iletileri erkenden aksatmasını önlemeye yardımcı olabilir.

Karantina ya da reddetme talep etmediği için p=none, nihai koruma düzeyi değil, bir izleme aşaması olarak görülmelidir. CloudSpex, tam uygulama ile karıştırılmaması için p=none değerini uyarı olarak raporlar.

Güvenli bir ilerleme sırası

Önce tüm meşru gönderenlerin envanterini çıkarın: e-posta sağlayıcınız, destek masanız, pazarlama platformunuz, işlemsel e-posta servisiniz ve sizin adınıza gönderim yapan her uygulama. Her kaynağın amaçlanan SPF ve DKIM yapılandırmasına sahip olduğunu doğrulayın.

DMARC raporlarını ya da e-posta sağlayıcınızdan gelen kanıtları inceleyin, sonra küçük adımlarla ilerleyin. Yaygın sıra şudur: önce p=none, sonra p=quarantine, meşru trafik anlaşıldıktan sonra da p=reject. Gönderim servislerini kontrol etmeden başka bir domainin politikasını kopyalamayın.

1. Bir DMARC kaydının bulunup bulunmadığını ve hangi politikayı yayınladığını kontrol edin.
2. Meşru gönderenler için SPF ve DKIM'in yapılandırıldığını doğrulayın.
3. Uygulamayı değiştirmeden önce meşru e-postaları inceleyin.
4. Daha sıkı bir politikayı ancak gönderim envanteri anlaşıldıktan sonra yayınlayın.
5. DNS değişiklikleri yayıldıktan sonra herkese açık kaydı yeniden kontrol edin.

Sık yapılan hatalar

Sözdizimi açısından mevcut olan bir kaydı tam koruma saymak sık yapılan bir hatadır. p=none politikası, bilinçli olarak quarantine ve reject değerlerinden daha zayıftır.

Bir başka hata, gözden kaçmış bir servis hâlâ kimliği doğrulanmamış e-posta gönderirken reject değerini etkinleştirmektir. Bu, istenen e-postaları kesintiye uğratabilir. Bu yüzden sahiplik ve değişiklik kontrolü, DNS kaydının kendisi kadar önemlidir.

Üç kayıt nasıl görünür?

DMARC kaydı, _dmarc ve ardından domain adından oluşan konumda yayınlanan tek bir TXT kaydıdır. İlk iki etiket, bu sırayla v ve p olmalıdır. Geri kalan her şey isteğe bağlıdır, ancak rua adresi olmayan bir kayıt size bir politika verir ama etkisini görmenin bir yolunu vermez.

Aşağıdaki üç kayıt, aynı domainin üç ayrı aşamasını gösterir. İlki ile sonuncusu arasında yalnızca p etiketi değişir. Ortadaki kayıtta yer alan pct etiketi ise kademeli ilerlemenin aracıdır.

; Stage 1 - monitor only
_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

; Stage 2 - quarantine a quarter of failing mail
_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com"

; Stage 3 - reject all failing mail
_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Alıcı sunucu bir iletinin başarısız olduğuna nasıl karar verir?

Politika yalnızca DMARC doğrulamasından geçemeyen iletilere uygulanır, bu yüzden başarısız olmanın ne anlama geldiğini kesin olarak bilmek gerekir. Bir ileti, şu iki koşuldan en az biri doğruysa DMARC'tan geçer: SPF geçmiştir ve SPF'in kontrol ettiği domain, görünen From adresindeki domainle hizalıdır; ya da DKIM geçmiştir ve imzalayan domain aynı From domainiyle hizalıdır.

Hizalı olmak, varsayılan olan gevşek (relaxed) modda aynı kurumsal domain, katı (strict) modda ise birebir aynı domain demektir. news.example.com adresinden gelen ve example.com tarafından imzalanan bir ileti gevşek modda hizalıdır, katı modda hizalı değildir.

Bir servisin SPF ve DKIM'den geçip yine de DMARC'tan geçememesinin nedeni budur. Kendi domainiyle imzalayan ve kendi geri dönüş adresini kullanan bir bülten platformu geçerli bir imza ve geçerli bir SPF sonucu üretir, ama ikisi de sizin domaininize ait değildir. Çözüm her zaman gönderen servistedir: özel imzalama domainini, özel dönüş yolunu (return path) ya da ikisini birden etkinleştirin.

Her aşamada alıcı için ne değişir?

p=none ile, doğrulamadan geçemeyen bir ileti hiç DMARC kaydı yokmuş gibi işlenir. Alıcı sunucu iletiyi yine de kendi gerekçeleriyle filtreleyebilir, ama politikanız hiçbir şey talep etmez. p=quarantine ile alıcı sunucudan doğrulamadan geçemeyen iletiyi şüpheli sayması istenir, bu da uygulamada çoğunlukla spam klasörü demektir. p=reject ile alıcı sunucudan iletiyi teslimat sırasında reddetmesi istenir. Böylece gönderene bir geri dönen ileti ulaşır, alıcı ise hiçbir şey görmez.

Karantina geri alınabilir, reddetme alınamaz. Spam klasörüne düşen meşru bir ileti bulunabilir, reddedilen bir ileti ise hiç ulaşmaz. none değerinden doğrudan reject değerine atlamak yerine quarantine aşamasından geçmenin nedeni bu farktır.

Alıcı sunucular politikayı bir talep olarak değerlendirir. Büyük e-posta sağlayıcılarının çoğu politikaya uyar, ancak her biri kendi yerel kurallarını da uygular ve doğrulamadan geçemeyen e-postaların küçük bir bölümü politikanın istediğinden farklı işlenebilir.

İzleyebileceğiniz kademeli bir geçiş planı

Aşağıdaki takvim bir kural değil, bir örnektir. Her adımın koşulu aynıdır: toplu raporlar, hâlâ doğrulamadan geçemeyen e-postaların yalnızca yetkilendirmemeye karar verdiğiniz kaynaklardan geldiğini göstermelidir.

1. rua adresi içeren bir p=none kaydı yayınlayın ve en az iki hafta rapor toplayın. Bu süre, faturalama gönderimleri gibi ayda bir çalışan gönderenleri de kapsayacak kadar uzun olmalıdır.
2. Raporlardaki her kaynağı listeleyin. Doğrulamadan geçemeyen her meşru kaynak için SPF ya da DKIM hizalamasını ilgili serviste düzeltin.
3. pct=25 ile p=quarantine değerine geçin. Bir hafta boyunca raporları ve destek gelen kutunuzu izleyin.
4. pct değerini önce 50'ye, sonra 100'e yükseltin ve değişiklikler arasında en az birkaç gün bırakın.
5. Yüzde 100 karantina hiçbir meşru hata üretmediğinde pct=100 ile p=reject değerine geçin.
6. reject değerine ulaştıktan sonra rua adresini koruyun. Bir domaine sürekli yeni gönderenler eklenir ve bunu raporlar sayesinde öğrenirsiniz.

Alt domainler ve sp etiketi

Kurumsal domaindeki bir DMARC kaydı, bir alt domain kendi kaydını yayınlamadığı sürece alt domainleri de kapsar. sp etiketi, alt domainler için domainin kendisinden farklı bir politika belirlemenizi sağlar.

İki kullanım yaygındır. Hâlâ p=none aşamasında olan bir domain, alt domainlerinden hiç e-posta göndermiyorsa sp=reject yayınlayabilir. Bu, sahte gönderim (spoofing) için kolay bir yolu kapatır. Ters yönde, p=reject aşamasındaki bir domain, bir pazarlama platformunun kullandığı alt domain düzeltilirken sp=none yayınlayabilir. sp etiketi yoksa alt domainler p değerini devralır.

_dmarc.example.com.  TXT  "v=DMARC1; p=none; sp=reject; rua=mailto:dmarc@example.com"

E-posta göndermeyen domainler

Park edilmiş domainler, yönlendirme domainleri ve eski marka adları, tam da kimse izlemediği için sahte gönderimin gözde hedefleridir. Bunlar için kademeli geçiş gerekmez: bozulacak meşru bir e-posta yoktur. Hiçbir şeyi yetkilendirmeyen bir SPF kaydıyla birlikte hemen p=reject yayınlayın.

example.org.         TXT  "v=spf1 -all"
_dmarc.example.org.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

İletme ve e-posta listeleri DMARC'ı bozduğunda

İki sıradan durum, meşru e-postanın doğrulamadan geçememesine yol açar. Bir alıcı e-postayı otomatik olarak başka bir posta kutusuna ilettiğinde, SPF açısından gönderen artık ileten sunucudur ve SPF başarısız olur. DKIM ise iletme (yönlendirme) sırasında çoğunlukla bozulmaz, çünkü imza iletiyle birlikte taşınır. Yalnızca SPF'e güvenmek yerine her gönderenin hizalı bir DKIM anahtarıyla imzaladığından emin olmanın başlıca nedeni budur.

E-posta listeleri daha zordur. Altbilgi ekleyen ya da konu satırını değiştiren bir liste imzalanmış içeriği değiştirir, dolayısıyla DKIM imzası artık doğrulanmaz. Bugün birçok liste bunu önlemek için From adresini yeniden yazar. Toplu raporlarda bu durumlar, tanımadığınız sunuculardan gelen hatalar olarak görünür. Bilinmeyen bir kaynağın kötüye kullanım olduğu sonucuna varmadan önce raporları dikkatle okumak için bir nedendir.

Sonucu kontrol etme

Her değişiklikten sonra DNS paneline güvenmek yerine yayınlanan kaydı geri okuyun. Önceki bir denemeden kalan ikinci bir DMARC kaydı, alıcı sunucuların ikisini de yok saymasına neden olur. Eksik bir noktalı virgül ya da yanlış sırada bir etiket kaydın tamamını geçersiz kılabilir ve domain sessizce hiç politikası olmayan duruma döner. CloudSpex DMARC Denetleyici, bir alıcı sunucunun göreceği kaydı okur, domain ve alt domainleri için politikayı raporlar ve kaydın yorumlanamayan bir bölümü olduğunda bunu belirtir.

Sıkılaştırmadan önce ilgilileri bilgilendirin

Politika değişikliği, başka ekiplerin e-postasını etkileyen bir DNS düzenlemesidir. quarantine ya da reject değerine geçmeden önce pazarlama, destek ve finans sistemlerini yönetenlere değişikliğin hangi tarihte yürürlüğe gireceğini ve bir hatanın nasıl görüneceğini söyleyin: açılma oranı alışılmadık ölçüde düşük bir kampanya ya da bir iletinin spama düştüğünü söyleyen müşteriler. Politika değişikliğinden sonraki sorunların çoğunu bir araç değil, bir çalışma arkadaşı bildirir ve önceden uyarılmış bir çalışma arkadaşı bunları ilk gün bildirir.