Kurumsal E-postanız Neden Spam’e Düşüyor? SPF, DKIM ve DMARC’ı Sade Bir Dille Anlatıyoruz

Müşteri teklifini gönderdiniz, cevap gelmedi. İki gün sonra telefonla aradınız: “Mail mi attınız? Bize hiç düşmedi.” Bakıyorsunuz, mail Gönderilenler’de duruyor, hata mesajı da yok. Aslında mail karşı tarafta ya spam klasörüne düşmüş ya da hiç teslim edilmemiş. Üstelik bunu siz asla öğrenmeyebilirsiniz.

Bu durumla özellikle kurumsal alan adıyla (info@firmaniz.com gibi) çalışan küçük işletmelerde sık karşılaşıyoruz. Kendi mail sunucumuzu yönettiğimiz ve müşterilerin alan adlarında DNS kayıtlarını düzelttiğimiz için kalıp neredeyse hep aynı: site yapılmış, mail kutuları açılmış, ama kimse alan adının “ben bu maili gerçekten gönderebilirim” diyen kayıtlarını tamamlamamış. Bu yazı o kayıtların (SPF, DKIM, DMARC) ne işe yaradığını, nasıl kontrol edileceğini ve hangi sırayla düzeltileceğini anlatıyor.

1. Mail neden spam’e düşer? Üç soru

Alıcının sunucusu her gelen maile şu üç şeyi sorar: bu mesaj gerçekten bu alan adından mı geldi, yolda değiştirildi mi, ve bu alan adının sahibi sahtekârlık durumunda ne yapılmasını istiyor? Bu üç sorunun cevabı DNS’te üç ayrı kayıtta durur. Kayıt yoksa ya da yanlışsa alıcı sunucu şüpheyi lehinize yorumlamaz; mesajı spam’e atar ya da reddeder.

Kısa özet: SPF “bu sunucular benim adıma mail atabilir” listesidir. DKIM mesajın üzerine konan, değiştirilmediğini kanıtlayan dijital imzadır. DMARC ise ikisi de tutmazsa alıcının ne yapacağını söyleyen kuraldır ve rapor da ister. Üçü birlikte çalışır; birinin eksik olması çoğu zaman diğer ikisinin emeğini boşa çıkarır.

2. Önce teşhis: kendi durumunuzu 5 dakikada görün

Hiçbir şeyi değiştirmeden önce mevcut durumu görmek gerekir. En güvenilir yöntem, gerçek bir mailin üstbilgisine bakmaktır.

1. Kurumsal adresinizden kendi Gmail adresinize bir mail gönderin.
2. Gmail’de maili açın, sağ üstteki üç noktadan “Orijinali göster” seçeneğine tıklayın.
3. En üstte SPF, DKIM ve DMARC için ayrı ayrı PASS ya da FAIL yazar.

Üçü de PASS ise teknik taraf büyük olasılıkla sağlam; sorun içerikte ya da alan adı itibarındadır. Biri FAIL ya da NEUTRAL ise aşağıdaki bölümlere geçin. DNS kayıtlarını doğrudan görmek isterseniz terminalde şu komutlar yeterli:

dig +short TXT firma.com            # SPF burada, "v=spf1" ile başlar
dig +short TXT _dmarc.firma.com     # DMARC kaydı
dig +short TXT secici._domainkey.firma.com   # DKIM (seçici adını üstbilgiden öğrenirsiniz)

Windows’ta aynı işi nslookup -type=TXT firma.com görür. Komut satırı size uzaksa Google Admin Toolbox’taki “Check MX” ya da benzeri ücretsiz kontrol araçları da aynı bilgiyi gösterir.

3. SPF: en sık bozulan kayıt

SPF, alan adınızın DNS’inde duran tek satırlık bir TXT kaydıdır ve mail gönderme yetkisi olan sunucuları listeler. Basit görünür ama hatayı en çok burada görüyoruz. Tipik bir kayıt şöyle:

v=spf1 mx include:_spf.google.com include:mail.firma-hosting.com ~all

Bu kaydın okunuşu: “MX kayıtlarımdaki sunucu, Google ve hosting firmamın sunucuları benim adıma mail atabilir; geri kalan herkes şüpheli.” Kuralları yazarken şunlara dikkat edin:

• Alan adı başına yalnızca bir SPF kaydı olabilir. Hosting firması bir tane, Google Workspace kurarken başka biri eklenmiş olabilir. İki ayrı v=spf1 satırı geçersizdir ve alıcılar kaydı komple yok sayar. Çözüm, ikisini tek satırda birleştirmek.
• En fazla 10 DNS sorgusu. include, a, mx gibi her mekanizma sorgu harcar, içteki include’lar da sayılır. Bülten servisi, CRM, fatura programı ve hosting eklendikçe sınır aşılıyor ve SPF “permerror” verip düşüyor.
• Sonu ~all ya da -all olmalı. -all daha katıdır. Hangi servislerden mail çıktığına emin değilseniz önce ~all ile başlayın.
• Bir servisi eklemeyi unutmak. Siteden form maili atan SMTP servisi, e-fatura entegratörü, toplu mail aracı… Hepsinin ayrı ayrı yetkilendirilmesi gerekir.

Site formlarından giden mailler

Bunu ayrıca söylemek istiyoruz çünkü web sitesi tarafında sık yapılan bir hata: iletişim formu, sunucunun yerleşik mail fonksiyonuyla (PHP mail()) gönderiliyor ve gönderen adres olarak info@firmaniz.com yazılıyor. Oysa o mail sizin mail sunucunuzdan değil, web sunucusunun IP’sinden çıkıyor ve SPF listenizde yok. Sonuç: form bildirimleri spam’e düşüyor ya da hiç gelmiyor, “formunuz çalışmıyor” şikâyeti buradan çıkıyor. Doğrusu, formu kimlik doğrulamalı bir SMTP hesabı üzerinden göndermek. Biz geliştirdiğimiz sitelerde formları baştan SMTP ile kuruyoruz; yazılım hizmetimizde bu ayrıntıya özellikle bakıyoruz.

4. DKIM: imza ve seçici

DKIM, gönderen sunucunun her maile gizli bir anahtarla imza atması, alıcının da DNS’teki açık anahtarla bunu doğrulamasıdır. Mail yolda değiştirilirse imza bozulur. Kayıt, seçici denen bir isimle yayınlanır: secici._domainkey.firma.com. Seçici adını mail sağlayıcınız belirler (Google’da genellikle google, kimi hosting panellerinde default).

İşin pratik tarafı:

• Anahtarı kendiniz üretmezsiniz; mail sağlayıcınızın panelinde “DKIM etkinleştir” benzeri bir seçenek vardır, size DNS’e eklenecek TXT değerini verir.
• Anahtar uzunluğu için 2048 bit tercih edin. 1024 hâlâ çalışıyor ama artık zayıf kabul ediliyor.
• Uzun değerler bazı DNS panellerinde 255 karakterde kesiliyor. Değer yarım kaydedilirse DKIM sessizce FAIL verir. Kaydettikten sonra dig ile çıktıyı mutlaka karşılaştırın.
• Her gönderim kaynağının (örneğin hem Google hem bülten aracı) kendi DKIM kaydı vardır. Tek bir kayıt hepsini kapsamaz.

5. DMARC: kuralı koyan kayıt

DMARC, SPF ve DKIM sonuçlarını “gönderen adresle uyumlu mu” diye kontrol eder ve uyumsuzluk halinde alıcıya ne yapacağını söyler. En büyük faydası ise raporlardır: alan adınız adına kimlerin mail attığını size bildirir. Kimi zaman ilk raporda, haberiniz olmayan bir servisin sizin adınıza mail gönderdiğini görürsünüz.

Kayıt _dmarc.firma.com adresine TXT olarak eklenir. Üç politika seviyesi vardır:

Başlangıç kaydı şöyle olabilir:

v=DMARC1; p=none; rua=mailto:dmarc@firma.com; adkim=r; aspf=r

Doğrudan p=reject ile başlamayın. Kimin adınıza mail attığını bilmeden katı politika koyarsanız, fatura programınızın ya da bülten aracınızın mailleri bir sabah topluca reddedilir. Rapor adresi (rua) için ayrı bir kutu açın, çünkü raporlar XML dosyası olarak ve sık gelir; ham haliyle okunması zor, ücretsiz DMARC rapor çözümleyicileri işi kolaylaştırır.

6. “Her şeyi kurdum ama hâlâ spam’e düşüyor” diyorsanız

Kayıtlar tamam, üç PASS da yeşil ve yine de mailler Gmail’de spam’e düşüyorsa sıra şu listeye gelir. Burada kesin reçete vermek zor, çünkü alıcı sunucular kararlarını birçok sinyale bakarak veriyor. Ama şunlar gözümüzün önünde en çok çıkanlar:

• Yeni alan adı, soğuk başlangıç. Dün alınmış bir alan adından ilk gün yüzlerce mail atarsanız hem spam filtresi hem de insanlar şüphelenir. Gönderimi küçükten başlatıp yavaş artırmak gerekir.
• IP itibarı. Paylaşımlı hosting’de aynı IP’yi başka siteler de kullanır; biri kötü kullanırsa herkes etkilenir. Kendi sunucunuzdan gönderiyorsanız IP’nin kara listede olup olmadığına ve ters DNS (PTR) kaydının mail sunucusunun adıyla uyuşup uyuşmadığına bakın. PTR eksikse birçok sunucu doğrudan reddeder.
• İçerik. Sadece bir görselden oluşan mailler, kısaltılmış linkler, büyük harfle bağıran konu satırları, eklenti olarak gönderilen şüpheli dosyalar.
• Liste kalitesi. Toplu mail atıyorsanız, geri dönen ya da şikâyet edilen adresleri listeden çıkarmak şart. Şikâyet oranı yükselince tek tek mailler değil, alan adınızın tamamı cezalanır.
• Yönlendirilen mailler. Bir adrese gelen mail otomatik başka adrese iletiliyorsa SPF çoğunlukla bozulur, çünkü iletilen mail artık ilk gönderenin IP’sinden gelmiyor. Bu yüzden DKIM’in sağlam olması önemli.

Gmail ve Yahoo’nun 2024 başında günde binlerce mail gönderenler için getirdiği kurallar (SPF, DKIM, DMARC zorunluluğu, tek tıkla abonelikten çıkma, düşük şikâyet oranı) küçük işletmeyi doğrudan ilgilendirmeyebilir. Yine de bu kuralların yönü, bütün alıcı sunucuların nereye gittiğini gösteriyor: doğrulanmamış alan adı giderek daha az hoşgörü görecek.

7. Hangi sırayla yapmalı?

1. Gönderim yapan tüm kaynakların listesini çıkarın: mail sağlayıcı, web sitesi formları, bülten aracı, CRM, e-fatura, muhasebe programı.
2. Mevcut SPF’yi kontrol edip tek kayıtta birleştirin, 10 sorgu sınırını aşmayın.
3. Her kaynak için DKIM’i etkinleştirin, kaydı DNS’e ekleyin, dig ile doğrulayın.
4. DMARC’ı p=none ile yayına alın, rapor kutusunu hazırlayın.
5. Gmail’de “Orijinali göster” ile her kaynaktan bir test maili atıp üç PASS’ı görün.
6. Raporlar temizlenince quarantine, sonra reject seviyesine çıkın.

Sürenin çoğu teknik işte değil, “bu alan adından başka kim mail atıyor” sorusunun cevabını bulmakta gidiyor. Yarım saatlik DNS işinden çok, bu envanter belirliyor.

8. Sık yapılan altı hata

1. Hosting değişirken eski SPF kaydını silmemek ya da yenisini eklememek.
2. İki ayrı SPF satırı bırakmak.
3. DKIM’i yalnızca ana mail sağlayıcıda açıp bülten aracını unutmak.
4. Raporları okumadan DMARC’ı doğrudan reject yapmak.
5. Site formunu mail() ile bırakıp “çalışıyor” saymak (gönderildi demek, ulaştı demek değildir).
6. Test mailini sadece kendi adresinize atıp, farklı bir alıcıdan (Outlook, Yahoo) denememek.

Son söz

Mail teslimi, web sitesi gibi gözle görülen bir şey değil; sorun olduğunda sessiz kalıyor. Bu yüzden bir kere doğru kurmak, sonra da birkaç ayda bir kontrol etmek en ucuz sigorta. Alan adı güvenliği ve sunucu sertleştirme tarafıyla birlikte düşünmek isterseniz web sitesi güvenliği yazımıza da bakabilirsiniz. Yeni bir kurumsal site yaptırmayı planlıyorsanız e-posta kurulumunun sürece nasıl dahil edildiğini kurumsal web sitesi rehberimizde anlattık.

Maillerinizin ulaşıp ulaşmadığından emin değilseniz, alan adınızı birlikte kontrol edelim: bize yazın ya da projenizi anlatın. DNS kayıtlarından form ayarlarına kadar tümünü bakıp ne eksik ise net olarak söyleriz. Diğer çalışmalarımız için hizmetler sayfasına göz atabilirsiniz.

Sıkça Sorulan Sorular (SSS)

SPF, DKIM ve DMARC arasındaki fark nedir?

SPF, alan adı adına mail atabilecek sunucuların listesidir. DKIM, mesajın değişmediğini gösteren dijital imzadır. DMARC ise bu ikisi başarısız olursa alıcının ne yapacağını belirleyen ve rapor üreten politikadır. Üçü birbirini tamamlar.

Mail gönderebiliyorum ama alıcı spam’e düştüğünü söylüyor, ne yapmalıyım?

Önce kendi Gmail adresinize mail atıp “Orijinali göster” ile SPF, DKIM ve DMARC sonuçlarına bakın. FAIL görünen kayıt varsa onu düzeltin. Hepsi PASS ise IP ve alan adı itibarı, içerik ve liste kalitesi gibi nedenlere bakmak gerekir.

Bir alan adında birden fazla SPF kaydı olabilir mi?

Hayır. Birden fazla v=spf1 kaydı geçersiz sayılır ve alıcılar SPF’yi komple yok sayabilir. Birden fazla servis kullanıyorsanız hepsini tek kayıtta include ile birleştirin ve toplamda 10 DNS sorgusunu aşmayın.

DMARC’ı doğrudan p=reject ile başlatmak güvenli mi?

Önermiyoruz. Alan adınız adına kimlerin mail gönderdiğini bilmeden katı politika koyarsanız meşru mailler de reddedilebilir. p=none ile rapor toplayıp kaynakları düzelttikten sonra kademeli olarak quarantine ve reject’e geçin.

Web sitemin iletişim formu mailleri neden gelmiyor?

Form, sunucunun yerleşik mail fonksiyonuyla, sizin alan adınızı gönderen göstererek mail atıyorsa SPF ve DKIM tutmaz; mail spam’e düşer veya reddedilir. Çözüm formu, kimlik doğrulamalı bir SMTP hesabı üzerinden göndermektir.

DNS değişikliği ne kadar sürede etkili olur?

Kayıtların TTL süresine bağlı olarak birkaç dakikadan birkaç saate kadar sürebilir. Değişiklikten sonra dig ile kaydın yayınlandığını doğrulayıp yeni bir test maili atmak en sağlıklısı.