SPF ve DMARC: yalnızca alıcı alan adında sahteciliği durdurma

İki yön var, birini yapılandırdınız

Bir alan adını buraya yönlendirmek tek bir DNS kaydı gerektirir. O kayıt — MX — tam olarak tek bir soruyu yanıtlar: bu alan adına gönderilen posta nereye gider? Bir catch-all'ın ihtiyaç duyduğu şeyin tamamı budur, ve çözümlendiği an alan adı çalışır hale gelir. Ama o anda aynı zamanda yalnızca yarı yapılandırılmıştır, çünkü bir alan adı iki yönde kullanılır ve MX kaydının ikincisi hakkında söyleyecek hiçbir şeyi yoktur.

İlginç olan ikinci yöndür. Posta protokolünde, bir yabancının kendi makinesinden gönderdiği bir mesajın From: satırına sizin alan adınızı yazmasını engelleyen hiçbir şey yoktur. Bunun için DNS'inize, kayıt şirketinize ya da posta kutunuza erişmesine gerek yoktur — bir mesajdaki adres bir iddiadır, bir kimlik bilgisi değildir, ve her zaman öyle olmuştur. Bu iddianın inanılıp inanılmayacağına karar veren şey, alan adınızın bunu kimin yapmaya yetkili olduğu konusunda söyledikleridir:

Hiçbir şey söylemeyen alan adı

Bir alıcı sunucu ne SPF ne de DMARC politikası bulur ve kendi sezgisel yöntemlerine geri dönmek zorunda kalır: itibar, içerik, alan adının daha önce nasıl davrandığı. Geçmişi ve politikası olmayan yepyeni bir alan adı, sahtecilik için neredeyse ideal hedeftir, çünkü sahteciliği çürütecek hiçbir şey yoktur ve sonrasında suçlanacak hiçbir şey de yoktur.

Hayır diyen alan adı

Aynı sunucu, hiçbir makinenin bu alan adı olarak göndermeye yetkili olmadığını ve başarısız olanların reddedilmesi gerektiğini belirten yayınlanmış bir politika bulur. Artık bir yargı meselesi olmaktan çıkar. Mesaj kapıda reddedilir, çoğu zaman bir spam klasörüne bile ulaşmadan.

Bu, büyük markalarla ilgili varsayımsal bir durum değildir. Giden postası olmayan alan adları, tam olarak politikaları olmadığı için seçilir — kimsenin korumadığı, iki hafta kullanılıp bırakılan bir isim, istenmeyen posta gönderen biri için karşı koyan bir isimden daha değerlidir.

Herkesin altı ayını alan kısmı neden atlayabilirsiniz

DMARC hakkında daha önce bir şey okuduysanız, bunun uzun ve dikkatli bir proje olduğunu okumuşsunuzdur. Bu tavsiye doğrudur, ama sizinle ilgili değildir. Posta gönderen bir alan adı için yazılmıştır, ve tek bir nedenden uzundur: dünyaya başarısız olan her şeyi reddetmesini söylemeden önce, sizin adınıza meşru olarak gönderen her sistemi bulup her birini geçer hale getirmeniz gerekir. Sıradan bir kuruluşta bu liste herkesin beklediğinden daha uzundur, ve bilinen değil keşfedilen bir şeydir:

1. Hiçbir şey yapmayan bir politika yayınlayın. p=none, alıcılardan rapor vermelerini ama hiçbir şeyi değiştirmemelerini ister, böylece unutulan bir gönderen politikanın kendisi tarafından kesilmez.
2. Haftalarca raporları okuyun. Faturalama sistemi, yardım masası, bülten aracı, birinin 2019'da kaydolduğu işe alım platformu — her biri başarısız olan bir kaynak olarak ortaya çıkar, ve her birinin ya yetkilendirilmesi ya da devre dışı bırakılması gerekir.
3. Aşamalı olarak sıkılaştırın. quarantine'a geçin, bekleyin, izleyin, ve ancak sonra reject'e geçin, çünkü sıkılaştırmanın her adımı birinin bel bağladığı postayı sessizce durdurabilir.

Bu adımların her biri, meşru gönderenleri kendi politikanızdan korumak için vardır. Yalnızca alıcı bir gelen kutusuna yönlendirilmiş bir alan adının meşru göndereni yoktur. Liste uzun değildir, keşfetmesi zor değildir, kısmen bilinmiyor da değildir — boştur. Ve her şeyi reddeden bir politika, var olmayan bir göndereni bozamaz.

Doğrudan son duruma geçmek için ikincil bir gerekçe daha vardır. p=none üzerinde duran bir alan adı, hiçbir şey istemeyen bir politika yayınlıyordur, ve bir alıcı sunucu bunu neredeyse hiç politikası olmayan bir alan adıyla aynı kabul eder. Kayıt var olduğu için halledilmiş gibi görünür — bu, açıkça bitmemiş olmaktan daha kötüdür, çünkü kimse onu bitirmek için geri dönmez.

Üç kayıt

Üçü de TXT kaydıdır, ve üçü de zaten sahip olduğunuz MX'in yanına girer. Adlar, çoğu DNS panelinin istediği şekilde yazılır — bölgeye göre göreceli olarak, @ alan adının kendisi anlamına gelecek şekilde. Sizinki tam nitelikli bir ad istiyorsa, bunun yerine yourdomain.com, _dmarc.yourdomain.com ve *._domainkey.yourdomain.com yazın.

Sağlayıcınız değerin tırnak içine alınmasını istiyorsa, alın. Bazı paneller tırnakları sizin için kendileri ekler ve sonunda onları iki kez saklamış olurlar, bu da hiçbir denetleyicinin okuyamayacağı bir kayıt üretir — bir değer dig'den etrafında iki tırnak takımıyla dönüyorsa, olan şey budur.

Yapıştırmaya hazır üç değer. Yeniden yazmak yerine kopyalayın: DMARC kaydında eksik bir noktalı virgül, tüm etiket listesini ayrıştırılamaz hale getirir, ve ayrıştırılamayan bir politika hiç politika yokmuş gibi kabul edilir.

SPF — alan adının kendisindev=spf1 -allKopyala

DMARC — _dmarc adındav=DMARC1; p=reject; sp=reject; adkim=s; aspf=sKopyala

DKIM — *._domainkey adındav=DKIM1; p=Kopyala

Bu kayıtlardaki her kelime aslında ne yapar

Beş karar, ve hangisinin hangisi olduğunu bilmek işe yarar — çoğunlukla, alan adı bir gün göndermeye başlarsa hangisini gevşetmeniz gerektiğini sonradan tanıyabilmeniz için.

-all

SPF kaydının sonu, ve burada önemli olan tek parçası. Yukarıda listelenmeyen her şey sahtedir anlamına gelir, ve yukarıda hiçbir şey listelenmemiştir. Yaygın alternatif olan ~all, muhtemelen sahte, ama yine de teslim et ve işaretle anlamına gelir — bu, siz hâlâ kendi gönderenlerinizi bulurken doğru cevaptır, ama hiç olmadığından emin olduğunuzda yanlış olandır.

p=reject

Bir alıcı sunucunun, bu alan adı olduğunu iddia edip başarısız olan postayla ne yapması gerektiği. none yalnızca rapor et anlamına gelir, quarantine şüpheli olarak işlem gör anlamına gelir, reject SMTP görüşmesinde reddet anlamına gelir. Reddetmek, mesajı bir insanın gözünden tamamen uzak tutandır.

sp=reject

Aynısı, her alt alan adına uygulanır — var olmayanlar da dahil. Bu olmadan bir sahtekâr, kendi kaydı olmayan ve onu durdurmak için hiçbir şey miras almayan billing.yourdomain.com'u kullanır. Bu etiket varsayılan olarak p'nin dediğine döner, bu yüzden kayıt onsuz da aynı şekilde davranır; yine de yazılır, çünkü kaydı geri okuduğunuzda göremediğiniz bir politika, eksik olduğunu varsayacağınız bir politikadır.

adkim=s, aspf=s

Katı hizalama. Kimliği doğrulanan alan adının, yalnızca akrabası değil, tam olarak From: satırındaki alan adı olmasını gerektirir — böylece anything.yourdomain.com'dan gelen bir mesaj, üst alan adına ait bir geçişi ödünç alamaz. Varsayılan gevşek hizalamadır, ve yetkilendirecek hiçbir şeyi olmayan bir alan adının söylemesi gereken şey katı olandır.

v=DKIM1; p=

İçinde anahtar olmayan bir DKIM genel anahtarı. Belirtim, boş bir anahtarın iptal edilmiş anlamına geldiğini açıkça belirtir, bu yüzden bu alan adı altında herhangi bir seçici adını belirten herhangi bir imza, yok sayılmak yerine doğrulamada başarısız olur. Wildcard, bir sahtekârın uydurabileceği her seçici adını kapsar, çünkü adı seçme hakkı ona aittir.

Ve tam olarak olduğu gibi kalması gereken kayıt

Yukarıdakilerin hiçbiri gelen postaya dokunmaz, ve hiçbiri dokunmamalıdır. Alan adındaki her adresi burada bir posta kutusu yapan şey MX kaydıdır, ve bunların hiçbiri onu değiştirmez:

MX kaydı — değişmedi10 smtp.grabmail.ioKopyala

Üç yeni kayıt ile bu kayıt farklı soruları yanıtlar, bu yüzden birbirleriyle etkileşmezler: SPF ve DMARC, sizmiş gibi görünen postayı kabul edip etmeyeceğine karar veren sunucular tarafından okunur, MX ise size gönderilen postayı nereye teslim edeceğine karar veren sunucular tarafından okunur. Dördüne de sahip bir alan adı, her şeyi alan ama kimseye kefil olmayan bir alan adıdır.

İşinizi üç komutla kontrol etmek

DNS, varsayımda bulunacak bir yer değildir. Bu kayıtların her biri yabancılar tarafından okunmak üzere yayınlanır, bu da onları tam olarak onların okuyacağı gibi okuyabileceğiniz anlamına gelir — hesap yok, araç yok, alan adınızı yapıştıracak bir site yok:

$ dig +short TXT      yourdomain.com
dig +short TXT _dmarc.yourdomain.com
dig +short MX       yourdomain.com

Kendi alan adınızı yerine koyun. Aradığınız şey budur, o ad üzerinde zaten sahip olabileceğiniz diğer TXT kayıtları bir yana:

"v=spf1 -all"
"v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s"
10 smtp.grabmail.io.

Bunun yanlış dönmesinin dört yolu, aşağı yukarı sıklık sırasına göre:

İlk komut hiçbir şey yanıtlamıyor

Kayıt henüz yayılmamıştır, ya da yanlış ada eklenmiştir. Alan adının kendisindeki TXT kayıtları www'a değil, @'a girer — düzenlediğiniz son ada varsayılan olarak dönen bir panel genellikle suçludur.

İki SPF kaydı dönüyor

Bir alan adına tam olarak bir tane izin verilir. İki tane, bir taneden daha katı değildir — kalıcı bir hatadır, ve iki tane bulan bir alıcı sunucu SPF kontrolünü başarısız değil bozuk olarak değerlendirir. Zaten bir SPF kaydınız varsa, ikinci bir tane eklemek yerine onu düzenleyin.

DMARC satırı dönüyor ama hiçbir şey onu uygulamıyor

Değeri dikkatle okuyun: v=DMARC1 ile başlamak zorundadır, ve etiketler noktalı virgüllerle ayrılır. Sürüm etiketi eksik olan ya da bir noktalı virgülün virgüle dönüştüğü bir kayıt, daha zayıf bir politika değildir — ayrıştırılamayan bir politikadır, ki bu da hiç politika yokmuş gibi sayılır.

MX yanıtı değişti

Değişmemesi gerekirdi. MX satırı artık eksikse, çıplak bir nokta gösteriyorsa ya da smtp.grabmail.io olmayan bir host listeliyorsa, durun ve başka hiçbir şey yapmadan önce onu geri koyun — gelen kutunuzun bel bağladığı kayıt budur.

Neredeyse herkesin kaçırdığı kısım: alt alan adları

DMARC ve SPF, ad alanını aynı şekilde bölmez, ve dikkatle korunan bir alan adının sızdığı yer de bu farktır. sp=reject gerçekten de var olsun olmasın her alt alan adını kapsar. SPF ise hiç öyle çalışmaz: zarftaki tam ad üzerinden aranır, ve kendi SPF kaydı olmayan bir adın SPF kaydı yoktur — üst alan adınınkini miras almaz.

DMARC ikinci satırı tek başına kapsar, bu yüzden bu bir boşluk değil, çifte güvencedir — ama bir wildcard SPF kaydı tek bir satıra mal olur ve SPF katmanındaki boşluğu da kapatır, ki bu, SPF kontrol edip DMARC uygulamayan alıcılar için önemlidir:

Wildcard SPF — bir TXT kaydı daha* TXT v=spf1 -allKopyala

Bir DNS wildcard'ı yalnızca kendi kaydı olmayan adlar için yanıt verir. mail.yourdomain.com'da zaten herhangi bir TXT kaydı varsa, wildcard o ad için başvurulmaz ve SPF kaydını orada açıkça yayınlamanız gerekir. Yalnızca catch-all olarak kullanılan bir alan adı için bu durum, planlamaya değecek kadar değil, bilmeye değecek kadar nadirdir.

Raporlar, ve edinmeye değip değmedikleri

DMARC'ın bir raporlama tarafı vardır: bir rua etiketi ekleyin, katılan alıcılar size alan adınız olduğunu iddia eden her şeyin ve ona ne olduğunun günlük bir özetini gönderir. Bu, DMARC'ın size zaten bilmediğiniz bir şey söyleyen tek parçasıdır, ve buraya yönlendirilmiş bir alan adında toplamanın hiçbir bedeli yoktur, çünkü gideceği adres alan adının kendisinde bir adres olabilir:

Raporlamalı DMARC — alan adını değiştirinv=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc@yourdomain.comKopyala

Raporları aynı alan adındaki bir adrese göndermek, insanları yakalayan bir belirtim ayrıntısından kaçınmanızı sağlar: rua, farklı bir alan adındaki bir adresi belirtiyorsa, o diğer alan adının raporlarınızı almaya yetkili olduğunu belirten bir kayıt yayınlaması gerekir, ve bunu yapana kadar çoğu gönderen hiçbir şey göndermez. Aynı alan adında böyle bir kayıt gerekmez, yanlış gidebilecek hiçbir şey de yoktur. Etkinleştirmeden önce nelerin geldiğini bilmeye değer:

• Ek olarak, gzip'lenmiş XML gelirler. Kahve içerken okuyacağınız bir özet değildir. Küçük alan adları büyük posta kutusu sağlayıcılarından günde birkaç tane alır, her biri birkaç kilobayt; bunları açıp okuyacak bir şeye ihtiyacınız olacak.
• İyi sonuç, boş olandır. Hiçbir şey göndermeyen bir alan adı, yalnızca başarısızlıkları listeleyen raporlar üretmelidir, ve sessiz bir hafta şu anda kimsenin sizi taklit etmediği anlamına gelir — ki bu bir bilgidir, ve onu edinmenin tek yoludur.
• Sıradan posta olarak gelirler. Burada bunun anlamı sıradan bir posta kutusudur: tarayıcıda ve diğer her şey gibi API üzerinden okunabilir, ve diğer her şeyle birlikte 5 gün sonra silinir.

Onları hiç toplamamayı tercih ederseniz, etiketi tamamen dışarıda bırakın. rua içermeyen bir DMARC kaydı tamamen geçerli bir kayıttır ve tam olarak aynı derecede korur; raporlama, neler olduğunu öğrenme yönteminizdir, politikanın nasıl uygulandığı değil.

Bunun yapmadığı şeyler

Bu kayıtlar dardır, ve sınırları konusunda net olmak, doğru güvendiğiniz bir kontrol ile yanlış güvendiğiniz bir kontrol arasındaki farktır. Kapsamadıkları dört şey:

Kendi gelen kutunuzu filtrelemezler

Alan adınızdaki SPF ve DMARC, sizden posta alan sunuculara verilen talimatlardır. Başkalarının posta sistemleri tarafından okunurlar, sizinkiler tarafından asla, ve catch-all'a düşen şey üzerinde hiçbir etkileri yoktur. Gelen şey, tek kimlik bilgisi onu bilmek olan bir adrese dünyanın gönderdiği her neyse odur.

From satırındaki bir ismi durdurmazlar

Your Company <attacker@gmail.com> yazan bir mesaj her kontrolü geçer, çünkü kimliği doğrulanan alan adı gerçekten saldırganın alan adıdır. DMARC alan adını korur, önündeki görünen adı değil — ve bir telefonda, gösterilen tek şey genellikle görünen addır.

Taklit bir alan adına dokunmazlar

Sizinkinden bir karakter uzaktaki bir alan adı, başkasının kayıtlarına sahip başkasının alan adıdır. Yayınladığınız hiçbir şey ona ulaşmaz. Bu bir kayıt şirketi ve izleme sorunudur, ve gerçekten farklı bir sorundur.

Posta kutusunu özel yapmazlar

Buradaki bir adreste hâlâ parola yoktur: onu bilen herkes okuyabilir, ki bu tüm hizmetin yaptığı anlaşmadır. Kendi alan adınız tahmin etmeyi ortadan kaldırır, okumayı değil — bunun dürüst hali catch-all alan adları rehberinde var.

Baştan sona yapmak

Alan adını her adımda çalışır durumda bırakan sırayla, işin tamamı:

1. Önce MX'i doğrulayın. dig +short MX yourdomain.com, smtp.grabmail.io dışında hiçbir şey yanıtlamamalıdır. Herhangi bir şey eklemeden önce bunu düzeltin, çünkü geri kalanı posta almayan bir alan adında değersizdir.
2. SPF kaydını ekleyin, @ üzerine — zaten biri orada değilse; öyleyse onu düzenleyin, çünkü iki tane daha katı bir ayar değil, bir hatadır.
3. DMARC kaydını ekleyin, _dmarc üzerine, doğrudan katı politikaya. Burada aşamalandırılacak bir kademeli geçiş yoktur ve onu atlayarak bozulacak hiçbir şey yoktur.
4. Wildcard DKIM kaydını ekleyin, *._domainkey üzerine, ve alt alan adı katmanını iki kez kapatmak isterseniz wildcard SPF kaydını da ekleyin.
5. Dördünü de geri okuyun, dig ile, TTL'nin sona ermesi için zaman geçtikten sonra genel bir çözümleyiciye karşı.
6. Kendinize bir şey gönderin. Herhangi bir yerden, alan adınızdaki kendi adreslerinizden birine posta gönderin ve gelen kutusunu açın. Ulaşırsa, gelen taraf değişikliği atlatmış demektir, ki kontrol etmeye değer tek gerileme budur.

İşte bu kadar, alan adı tamamlandı: üzerinde icat edeceğiniz her adresi kabul eder, ve kimseye kefil olmaz. Alan adını henüz bağlamadıysanız, catch-all rehberiyle başlayın — tek bir kayıt ve aynı beş dakika — ve sonra bu sayfaya geri dönün, hiçbir şeyi yarım bırakmayan sıra budur.

Sorular