DMARC: 30 günde p=none'dan p=reject'e

Zorlamanın neden bir plana ihtiyacı var

p=reject yayımlamak tek bir DNS değişikliğidir; kendi postanızı bozmak da öyle. Değişiklikten sonra alan adınız adına gönderim yapan her servisin DMARC doğrulamasını geçmesi gerekir: posta sağlayıcınız, bülten aracı, faturalama sistemi, destek masası, web mağazası ve ofiste PDF gönderen tarayıcı. Bunlardan kendi alan adıyla imza atan ya da kendi dönüş adresini kullanan her biri hizalamada başarısız olur ve reddedilir.

DMARC raporlama döngüsü tam da bu göndericileri zorlamadan önce bulmak için vardır. p=none ve çalışan bir rua adresiyle birlikte alıcı sunucular her gün toplu raporlar gönderir; bu raporlar From başlığında sizin alan adınızla posta gönderen her IP adresini ve o postanın doğrulamayı geçip geçmediğini listeler. Zorlamaya yalnızca raporlar meşru hiçbir kaynağın geride başarısız kalmadığını gösterdiğinde geçersiniz.

Başlamadan önce: gönderici envanteri

From adresinde alan adınız yazan posta gönderen her sistemi ve her birinin sahibini yazın. Unuttuklarınızı raporlar zaten ortaya çıkaracaktır, ama hazır bir liste ilk haftayı belirgin biçimde kısaltır ve bir şey bozulduğunda kime başvuracağınızı size önceden söyler. Yılda yalnızca bir kez çalışan yıl sonu ekstre gönderimi gibi seyrek sistemleri de listeye ekleyin; iki haftalık bir pencerede bu tür bir gönderimi gözden kaçırmak çok kolaydır.

Herhangi bir şey yayımlamadan önce alan adının SPF ve DKIM durumunu kontrol edin. Kaydın gerçekten var olduğunu, 10 sorgu sınırının altında kaldığını ve ~all ya da -all ile bittiğini doğrulamak için E-posta Güvenliği aracını kullanın. SPF, DMARC, MX kayıtlarını ve web sitesini tek bir çalıştırmada özetleyen genel bir bakış için Alan Adı Sağlığı kontrolünü çalıştırın.

1. hafta: p=none yayımlayın ve rapor toplayın

Toplu rapor adresi içeren bir izleme kaydı yayımlayın. Bu iş için ayrılmış bir posta kutusu ya da bir DMARC rapor servisi, kişisel bir gelen kutusundan çok daha iyi çalışır: büyük alan adları günde onlarca sıkıştırılmış XML dosyası alır. Adres başka bir alan adındaysa o alan adının bir yetkilendirme kaydı yayımlaması gerekir; rapor servisleri bu kaydı kendiliğinden oluşturur.

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Değişiklikten sonra E-posta Güvenliği aracını çalıştırın. Araç, ortada tam olarak tek bir kaydın bulunduğunu, politikanın söz dizimsel olarak ayrıştırılabildiğini ve harici rapor adreslerinin yetkilendirilmiş olduğunu doğrular. Büyük sağlayıcılardan gelen raporlar genellikle bir iki gün içinde başlar ve bir önceki UTC gününü kapsar.

2. hafta: raporları okuyun ve hizalamayı düzeltin

Rapor satırlarını kaynak IP adresine göre gruplayın ve her adresin sahibini belirleyin. Ters DNS kaydı, IP Bilgisi aracından gelen ağ adı ve gönderim hacmi durumu genellikle açık eder: ESP'nizin bir IP aralığı, posta sağlayıcınız ya da kendi sunucularınız. Raporun her alanını tek tek toplu rapor rehberi açıklar.

Her serviste DKIM hizalamasını hedefleyin. Posta yönlendirildiğinde SPF hizalaması her seferinde bozulur; buna karşılık d=example.com taşıyan bir DKIM imzası, ileti yol boyunca değiştirilmediği sürece yönlendirmeden sağ çıkar. Bir servis kendi alan adınızla imza atamıyorsa, onu kendi SPF, DKIM ve DMARC kurulumu olan news.example.com gibi ayrı bir alt alan adına taşımayı değerlendirin.

selector1._domainkey.example.com. IN CNAME selector1-example-com._domainkey.esp.example.net.

3. hafta: p=quarantine aşamasına geçin

Son bir haftalık raporlar bilinen göndericilerinizin hizalı biçimde doğrulamayı geçtiğini gösterdiğinde politikayı quarantine olarak değiştirin. Başarısız posta artık spam klasörlerine teslim edilir; bu, kullanıcılar tarafından görülebilen ama geri alınabilir bir durumdur. Gönderim sistemlerinin sahiplerine ve destek ekibine neyin değiştiğini önceden söyleyin ki kayıp posta şikâyeti hızla DMARC ile ilişkilendirilebilsin.

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

RFC 7489 ayrıca politikayı başarısız postanın yalnızca bir kısmına uygulamak için pct etiketini tanımlar; örneğin pct=25 dendiğinde geri kalan posta bir kademe daha yumuşak işlem görür. Bu, çok büyük bir alan adında ilk adımı yumuşatabilir, ancak DMARCbis revizyonu pct etiketini kaldırıp yerine basit bir test bayrağı getirmektedir. Çoğu alan adı için daha iyi yol, hizalama işini bitirip politikayı tümüyle devreye almaktır.

4. hafta: p=reject aşamasına geçin

Meşru bir başarısızlık yaşanmadan bir hafta karantinada kaldıktan sonra p=reject yayımlayın. Politikaya uyan alıcılar artık başarısız iletileri SMTP oturumu sırasında reddeder; böylece gönderen, alıcının iletiyi spam klasöründe bulması yerine doğrudan bir geri dönüş iletisi alır. Alan adınızın doğrudan taklit edilmesini durduran ayar budur.

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

rua etiketini kalıcı olarak yerinde bırakın. Birinin habersizce kaydolduğu yeni bir pazarlama aracını, bir sağlayıcıda süresi dolmuş bir DKIM anahtarını ya da bir sahtecilik kampanyasını raporlar sayesinde fark edersiniz. Raporları en azından haftada bir inceleyin ya da bir rapor servisinin sizi uyarmasını sağlayın.

Bir şey bozulursa

Meşru posta geri dönmeye başladığında politikayı bir kademe düşürün, göndericiyi düzeltin ve yeniden yukarı çıkın. Kayıttaki TTL değeri kısa tutulduğunda bu değişiklik dakikalar içinde etkili olur. Kaydı silmeyin: kaydı silmek, neyin yanlış gittiğini görmek için ihtiyaç duyduğunuz raporları da ortadan kaldırır.

1. p=reject değerini p=quarantine yapın (ya da quarantine değerini none yapın).
2. Başarısız olan kaynağı en son toplu raporda veya elinizdeki geri dönüş iletisinde bulun.
3. O servis için kendi alan adınızla DKIM imzalamayı etkinleştirin ya da onu kimlik doğrulamalı bir aktarma sunucusu üzerinden yönlendirin.
4. Düzeltmeyi bir test iletisi ve E-posta Başlığı Analizi ile doğrulayın: header.d=example.com ile birlikte dkim=pass.
5. Daha katı olan politikayı geri getirin.

Özel durumlar

Yönlendirme ve posta listeleri

Yönlendirme SPF doğrulamasını bozar, çünkü yönlendirmeyi yapan sunucu sizin SPF kaydınızda yer almaz. İletiye alt bilgi ekleyen ya da konu satırını değiştiren posta listeleri de aynı şekilde DKIM imzasını bozar. Alıcılar, güvendikleri aracıların eklediği ARC (RFC 8617) başlıklarını kullanarak bu tür postayı yine de kabul edebilir, ancak bu sizin kontrolünüzün dışındadır; kontrol edebildiğiniz şey tüm postayı DKIM ile imzalamaktır.

Hiç posta göndermeyen alan adları

Park edilmiş ve savunma amacıyla alınmış alan adları bu aşamaların tamamını atlayabilir. p=reject, v=spf1 -all içeren bir SPF kaydı yayımlayın ve hiç MX kaydı bırakmayın; böylece bu alan adları sahtecilik için kullanılamaz.

example.org.        IN TXT "v=spf1 -all"
_dmarc.example.org. IN TXT "v=DMARC1; p=reject;"

Düşük hacimli alan adları

Küçük bir işletmenin alan adı günde yalnızca birkaç ileti gönderiyor olabilir; bu yüzden raporların her göndericiyi göstermesi çok daha uzun sürer. En az bir tam faturalama döngüsü boyunca ya da envanter listenizdeki her sistem bir raporda geçer durumda görünene kadar p=none politikasında kalın.

Üçüncü taraf göndericilerle çalışmak

İkinci haftada ortaya çıkan hizalama hatalarının çoğu kendi sunucularınıza değil bir satıcıya aittir. İyi haber şu: ciddi gönderim servislerinin neredeyse tamamı kendi alan adınızla kimlik doğrulamayı destekler ve bu özellik genellikle alan adı doğrulaması, gönderen kimlik doğrulaması ya da markalı gönderim adıyla anılır. Ayar, sizden DNS kayıtları gerektirdiği için çoğu zaman varsayılan olarak kapalı gelir.

Bir satıcıya başvururken kesin sorular sorun. “Lütfen DMARC'ı destekleyin” gibi belirsiz bir talep genellikle aynı ölçüde belirsiz bir yanıt alır; oysa d=example.com ile atılmış bir DKIM imzası talebinin net bir evet ya da hayır karşılığı vardır. Aldığınız yanıtları gönderici envanterinizde saklayın ki sizden sonra bu işe bakacak kişi her servisin nasıl yapılandırıldığını bilsin.

1. İletilerimizi kendi alan adımızla (d=example.com) DKIM kullanarak imzalayabilir misiniz ve bunun için hangi DNS kayıtlarına ihtiyacınız var?
2. Zarf göndericisi (return-path, dönüş adresi) bounces.example.com gibi bize ait bir alt alan adını kullanabilir mi, böylece SPF hizalanır mı?
3. Hangi SPF include kaydına ihtiyacınız var ve bu kayıt kaç DNS sorgusu harcıyor?
4. Paylaşımlı IP aralıklarından mı gönderiyorsunuz ve DKIM anahtarlarını döndürüyor musunuz? Anahtar değişiklikleri bize nasıl bildiriliyor?
5. Ana alan adında tam hizalama mümkün olmazsa news.example.com gibi bir alt alan adından gönderebilir miyiz?

Satıcının SPF include kaydını eklemek her zaman gerekli değildir. Satıcı sizin alan adınızla imzalıyor ve kendi dönüş alan adını kullanıyorsa DMARC yalnızca DKIM üzerinden geçer ve on SPF sorgunuzdan birini harcamaktan kurtulursunuz. Bu bütçenin neden bu kadar önemli olduğunu SPF 10 sorgu sınırı rehberi ayrıntısıyla açıklar.

Geçiş sırasında alt alan adları

Kendi _dmarc kaydı olmayan alt alan adları kurumsal alan adının politikasını devralır: varsa sp etiketini, yoksa p değerini. Bu devralma işinize yarar, çünkü saldırganlar secure.example.com gibi resmî görünen ama aslında hiçbir kaydı bulunmayan adları taklit etmeyi sever. Ayrıca bu, geçişinizin bir ekibin yıllar önce kurup unuttuğu alt alan adları da dahil olmak üzere hepsini aynı anda kapsadığı anlamına gelir.

Raporlarda alt alan adı göndericilerini arayın: header_from alanı her satırın tam From alan adını gösterir. Bir alt alan adı henüz zorlamaya hazır olmayan posta gönderiyorsa, sp etiketini tüm alt alan adları için zayıflatmak yerine o alt alan adına p=none içeren kendi kaydını verin ve sorunu bu arada düzeltin. Sorun çözüldüğünde alt alan adı kaydını silin ki yeniden ana politikayı izlesin.

_dmarc.legacy.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

DMARCbis revizyonu, DNS'te hiç var olmayan alt alan adları için bir np etiketi ekler. Bunu destekleyen alıcılar, gerçek alt alan adlarınız için daha yumuşak bir sp değeri kullansanız bile invoice-2026.example.com gibi uydurma adlardan gelen postayı reddedebilir. Bu destek yaygınlaşana kadar sp değerini p ile aynı tutmak size aynı korumayı sağlar.

İlerlemeyi ölçmek

Bir geçişi yönetmek, haftalık rapor özetinden çıkardığınız birkaç sayı ile çok daha kolay olur. Bu sayıları hafta hafta takip edin ki imzalamayı bırakan bir satıcı gibi bir gerileme daha ilk bakışta göze çarpsın. Aynı sayılar, gönderim sistemlerinin sahiplerine verilecek durum güncellemesi için de iyi bir malzeme oluşturur.

Tüm trafikte kusursuz bir yüzde 100 peşinde koşmayın. Yönlendirilen posta ve sahtecilik denemeleri her zaman başarısız olacaktır ve bu tamamen beklenen bir durumdur. Gerçekten sıfıra inmesi gereken sayı, kendi göndericilerinizden gelip başarısız olan meşru postadır.

Kontrol listesi

• Gönderim yapan servislerin her biri için ayrı bir sahibi olan bir envanter listesi.
• Geçerli, 10 sorgunun altında kalan ve ~all ya da -all ile biten bir SPF kaydı.
• Destekleyen her serviste kendi alan adınızla DKIM imzalamanın açılmış olması.
• rua içeren ve TTL değeri kısa tutulmuş tek bir DMARC kaydı; harici rapor adresleri yetkilendirilmiş.
• Her politika değişikliğinden önce en az bir haftalık raporun incelenmiş olması.
• quarantine ve reject adımlarından önce destek ekibinin bilgilendirilmiş olması.
• Haftalık rapor incelemesi ve SPF ile DKIM adımlarını içeren bir satıcı devreye alma süreci.

SSS

Kaynaklar

• RFC 7489: DMARC (politika, pct, raporlama)
• RFC 6376: DKIM imzaları
• RFC 7208: SPF
• RFC 8617: Authenticated Received Chain (ARC)
• Google: E-posta gönderenler için yönergeler