Mailler spam’e düşüyor: kimsenin bakmadığı From hizalaması

İşlettiğimiz bir platform kampanya maillerini birden çok sunucu üzerinden gönderiyordu. Her sunucuda doğrulama kuruluydu, bilinen test araçları SPF ve DKIM için geçti diyordu, maillerin önemli bir kısmı yine spam klasörüne düşüyor ya da hiçbir geri dönüş olmadan kayboluyordu. Sebebini açıklayan başlık her mesajın içindeydi ve kimse onu okumamıştı. Okuyucunun From alanında gördüğü alan adı ile mesajı gerçekten doğrulayan alan adı farklıydı, yani DMARC hizalaması tutmuyordu.

Üç kayıt aslında ne yapıyor

SPF, bir alan adı adına mail gönderebilecek adreslerin listesini DNS'te yayımlar. Kontrol ettiği alan adı zarf göndereni, yani geri dönen maillerin gideceği adrestir; okuyucunun gördüğü adres değildir.

DKIM, mesajı gönderim sunucusundaki özel anahtarla imzalar ve eşleşen açık anahtarı DNS'e koyar. İmzanın içinde d= etiketi vardır ve imzalayan alan adını söyler. Alıcı taraf özeti yeniden hesaplar, imza tutuyor mu ona bakar.

DMARC ise görünen From başlığındaki alan adında yayımlanan bir politikadır ve diğer ikisinden daha dar bir soru sorar: SPF ya da DKIM, From alan adıyla eşleşen bir alan adı için geçti mi? Bu eşleşmeye hizalama deniyor ve atlanan kısım tam olarak burası.

Varsayılan olan gevşek hizalamada kök alan adı eşleşmesi yeterlidir, yani mail.marka.example ile marka.example hizalı sayılır. Katı hizalamada alan adının birebir aynı olması gerekir. Her iki durumda da alakasız bir alan adı için alınan geçti sonucunun DMARC açısından hiçbir değeri yoktur.

Hataya yol açan kurulum şöyleydi. Platform birden çok sunucudan gönderim yapıyor. Her sunucunun kendi hostname'i, kendi alan adı, kendi SPF kaydı ve kendi DKIM anahtarı var, hepsi de doğru kurulmuş. Platform ise hangi sunucu gönderirse göndersin her mesajın From başlığına tek bir marka adresini yazacak şekilde ayarlanmış. Sonuç:

• SPF, gönderim sunucusunun alan adı için geçiyor.
• DKIM, d= değeri gönderim sunucusunun alan adı olacak şekilde geçiyor.
• From başlığında marka alan adı yazıyor.
• DMARC ilk ikisinden birinin üçüncüyle eşleşmesini bekliyor, ikisini de bulamıyor ve geçmiyor.

SPF ile DKIM'e ayrı ayrı bakan her araç yeşil yazar. Sadece doğrulama var mı diye bakan alıcılar maili geçirir. Hizalamayı zorunlu tutan alıcılar ise karantinaya alır veya sessizce düşürür. Belirtinin rastgele görünmesinin sebebi budur: bazı kutularda sorunsuz, bazılarında spam, bazılarında hiçbir şey.

Bu tablonun can sıkıcı yanı ölçmenin zor olmasıdır. Gönderdiğiniz mailin hangi klasöre düştüğünü dışarıdan göremezsiniz, elinizde sadece açılma oranı vardır ve o oran sıfırlanmaz, sessizce düşer. Ekip önce içeriği suçlar, konu başlığını değiştirir, listeyi temizler, hacmi kısar. Hepsi mantıklı hamlelerdir ve hiçbiri işe yaramaz, çünkü sorun mesajın içinde değil zarfın üstündedir.

Nasıl görülür

Büyük bir sağlayıcıda kendi kontrolünüzdeki bir test adresine tek bir mail atın, mesajın orijinal kaynağını açın ve tek bir başlığı okuyun.

Authentication-Results: mx.saglayici.example;
       spf=pass (sender IP is 203.0.113.10)
        smtp.mailfrom=mail7.gonderim.example;
       dkim=pass (signature was verified)
        header.d=mail7.gonderim.example;
       dmarc=fail (p=NONE sp=NONE dis=NONE)
        header.from=marka.example

Üç satır, üç alan adı. smtp.mailfrom SPF'in baktığı, header.d DKIM'in imzaladığı, header.from ise okuyucunun gördüğü alan adıdır. İlk ikisi üçüncüyle eşleşmiyorsa raporun geri kalanı ne derse desin dmarc=fail gelir.

DNS tarafı iki komutluk iş:

dig +short TXT marka.example | grep spf1
# "v=spf1 include:_spf.gonderim.example ~all"

dig +short TXT _dmarc.marka.example
# "v=DMARC1; p=none; rua=mailto:dmarc@marka.example; adkim=r; aspf=r"

p=none politikanın sadece raporlama modunda olduğunu söyler, herkes oradan başlar. adkim ve aspf hizalama kiplerini belirler, r gevşek, s katı demektir.

Bazı istemcilerde kaynak görüntüleme seçeneği kolay bulunmaz, bazı sağlayıcılar da başlığı arayüzde kısaltır. O durumda test kutusunu IMAP ile çekip ham mesajı diske yazmak en pratik yol. Test adreslerini bir kere kurun ve gönderim yapısına dokunan her değişiklikten sonra aynı üç kutuya gönderin.

Çözüm

Hizalamanın iki dürüst yolu var ve ikisi farklı kurulumlara uyuyor.

Birincisi her şeyi tek alan adında toplamak. Bütün sunucular aynı anahtarla imzalar, geri dönüşler aynı alan adına gider, From başlığı olduğu gibi kalır. Hizalama tutar ve bütün sunucular tek bir itibarın arkasında toplanır. Bedeli operasyoneldir: aynı özel anahtarın her makinede durması gerekir ve SPF kaydının bütün gönderim adreslerini on DNS sorgusu sınırının içinde kapsaması gerekir, iç içe geçmiş include'lar bu sınırı hızla yer.

İkincisi her sunucunun kendi adına göndermesi. Sunucuların gelip gittiği bir yapıda ben bunu tercih ediyorum. Zarf göndereni ve DKIM imzası sunucunun kendi alan adını kullanır, From başlığı da o alan adına çevrilir, görünen isim marka olarak kalır:

From: Marka Adı <haber@mail7.gonderim.example>
Reply-To: Marka Adı <merhaba@marka.example>

Okuyucu mesaj listesinde markayı görür, çünkü istemciler adresi değil görünen ismi gösterir. Yanıtlar ana alan adına düşer, çünkü Reply-To öyle diyor. DMARC de geçer, çünkü artık üç alan adı da aynı.

Gönderim platformlarında bu genellikle sunucu bazında bir ayardır: kampanyanın belirttiği From değerini korumak yerine kendi alan adını zorlar. Bu ayarı sadece yeni sunucularda değil hepsinde açın. Eski usulle göndermeye devam eden tek bir sunucu, açıklamaya çalıştığınız hataları üretmeye devam eder ve unutacağınız sunucu tam olarak o olur; kontrol paneliyle config dosyasının birinde elle yapılan bir düzenlemeden sonra sessizce ayrışması gibi.

Ardından DMARC'ı yayımlayın ve kademeli yükseltin. p=none ve bir rua adresiyle başlayın, iki üç hafta toplu raporları okuyun, sonra yüzde vererek p=quarantine, en son p=reject. Raporlar temizlenmeden doğrudan reject'e geçmek, kendi mailinizi kendiniz reddetmektir.

Bu düzenlemenin çözmediği şeyler de var: içerik, liste kalitesi ve şikâyet oranı. Hizalama size kapıda reddedilmek yerine itibarınıza göre değerlendirilme hakkı verir, fazlasını değil.

Çalıştığını nasıl doğrularsınız

Üç farklı sağlayıcıdaki test adreslerine mail atın, ham mesajları kaydedin ve her birinden aynı başlığı okuyun:

grep -io "spf=pass\|dkim=pass\|dmarc=pass\|smtp.mailfrom=[^;]*\|header.d=[^;]*\|header.from=.*" test-*.eml
# spf=pass
# smtp.mailfrom=mail7.gonderim.example
# dkim=pass
# header.d=mail7.gonderim.example
# dmarc=pass
# header.from=mail7.gonderim.example

Üç alan adı, tek değer. Birkaç gün sonra toplu raporlar aynı şeyi hacimde söylemeli: mesajların neredeyse tamamı DMARC geçti, raporda listelenen kaynakların hepsi tanıdığınız sunucular. Raporda tanımadığınız bir adres varsa ya bir yönlendirici vardır ya da sizin adınıza gönderen biri; ikisi de bir saatinizi ayırmaya değer.

Nelere dikkat etmeli

• SPF'teki on sorgu sınırı iç içe include'lar boyunca toplanır. Sınırı aşınca sonuç kalıcı hata olur ve alıcıların çoğu bunu SPF hiç yokmuş gibi değerlendirir. Yeni bir include eklemeden önce sorgu sayısını sayın, mailler düşmeye başladıktan sonra değil.
• Yönlendirme SPF'i bozar, çünkü yönlendiren sunucu sizin kaydınızda değildir. DKIM, mesaj gövdesi değiştirilmediği sürece yönlendirmeden sağ çıkar. Bu yüzden önce DKIM hizalamasını oturtmak daha kalıcıdır.
• Toplu raporlar XML olarak gelir ve elle okunacak gibi değildir. Küçük bir betikle kaynak IP başına geçen ve kalan mesaj sayısına indirin; hangi sunucunun hizasız olduğunu ilk hafta içinde tek tabloda görürsünüz.
• Yeni bir gönderim alan adının itibarı sıfırdır ve alt alan adı üst alan adından fazla bir şey devralmaz. Hacmi yavaş yükseltin, şikâyet veya geri dönme oranı kıpırdadığında durun.
• Hangi alan adının doğrulandığını arayüzde göremezsiniz. Görünen isim her iki durumda da aynıdır, gerçeğin yazılı olduğu tek yer başkasının posta kutusundaki bir başlıktır. Bu başlığı okumayı sürüm kontrol listenize koyun; güvenlik başlıklarının geçerli sanılan bir config kuralı yüzünden yok olmasını yakalayan refleksin aynısıdır.

Mail doğrulaması tasarım gereği sessizce başarısız olur. Hizalanmamış bir mesajı düşüren alıcının size açıklama yapma yükümlülüğü yoktur ve kararın tek kaydı, sizin sahibi olmadığınız bir kutudaki başlıktır. Büyük sağlayıcıların her birinde bir test adresi tutun, gönderim yapısına her dokunduğunuzda Authentication-Results başlığını okuyun ve oradaki üç alan adına eşleşen ya da eşleşmeyen tek bir kontrol gözüyle bakın. Değişiklik başına bir dakika sürer, karşılığında maillerinizin içeriğine göre değerlendirilmesiyle hiç görülmemesi arasındaki farkı alırsınız.