Kendi Alan Adınızdan E-posta

Botunuz müşterilerinize e-posta yazabilir — kendi alan adınızdaki bir adresten, örneğin noreply@example.com. Ancak iletiyi gönderen bizim sunucumuzdur. Bu nedenle ilk gönderimden önce alan adınızın DNS'ine bir kez üç kayıt eklemeniz gerekir. Aşağıda: bunun neden gerektiği, tam olarak ne ekleneceği ve sonrasında ne olduğu.

DNS kayıtları olmadan e-postalar neden ulaşmaz

Olaya alıcı tarafın gözünden bakın — Gmail, Outlook ya da müşterinizin posta sunucusu. Onlara, alan adınızdan geldiğini iddia eden ama alan adınıza ait olmayan bir sunucudan gelen bir ileti ulaşır. Bu, tam olarak bir sahteciliğin görüntüsüdür: kimlik avı böyle çalışır.

Alıcının ikisini ayırt etmesinin tek yolu, alan adının kendisine sormaktır: "bu gönderici gerçekten sizin adınıza mı hareket ediyor?" Yanıtı alan adınızın DNS'inde yayımlarsınız; çünkü DNS yalnızca sizin elinizde olan tek yerdir ve bu yüzden alıcının inandığı tek yerdir.

Bu yanıt olmadığı sürece, dürüst bir posta sunucusu iletiyi şüpheli saymak zorundadır. En iyi ihtimalle Spam'e düşer, en kötüsünde reddedilir ve alıcı varlığından hiç haberdar olmaz.

Dolayısıyla aşağıdaki üç kayıt bir formalite ya da arayüzdeki bir onay kutusu değildir. Onlar sizin izninizdir.

Üç kayıt ve her birinin işlevi

DKIM — özgünlüğü kanıtlayan imza

DKIM, giden her iletiye eklenen kriptografik bir imzadır. Platform alan adınız için bir anahtar çifti üretir: özel olan bizde kalır ve iletileri imzalar, açık olanı siz DNS'te yayımlarsınız. Alıcı açık anahtarı DNS'inizden alır ve imzayı doğrular. Tutuyorsa, ileti özel anahtara sahip olan tarafından gönderilmiştir ve içeriği yolda değiştirilmemiştir.

DKIM olmadan: imzayı doğrulayacak bir şey yoktur. İleti imzasız ve güvenilmez görünür; başka hiçbir ayar bunu telafi etmez. DKIM, üçünün en önemlisidir.

SPF — sizin adınıza hangi sunucular gönderebilir

SPF başka bir soruyu yanıtlar: bu alan adı için hangi sunuculardan gelen postalar kabul edilebilir. Bu bir kaynak listesidir — barındırma sağlayıcınızın posta sunucuları, hâlihazırda kullandığınız gönderim hizmetleri ve botun yazabilmesi için bizim gönderim sunucularımız.

SPF olmadan: ileti, alan adınızın tanımadığı bir sunucudan gelir. Bir filtre için bu klasik bir sahtecilik işaretidir ve diğer tüm şüphelerin üstüne eklenir.

DMARC — doğrulamalar başarısız olursa alıcı ne yapmalı

DKIM ve SPF "ileti gerçek mi" sorusunu yanıtlar. DMARC bir sonrakini yanıtlar: değilse ne yapılmalı. Bu sizin alıcıya talimatınızdır — hiçbir şey yapma ve yalnızca rapor gönder, spam'e at, ya da reddet. Ayrıca DMARC, alıcıların adınıza giden postayla ilgili toplu raporları — başkalarının sahtecilik denemeleri dahil — gönderdiği adrestir.

En yumuşak politikayla, "yalnızca rapor" ile başlayın. Daha sonra, tüm meşru göndericilerinizin (muhasebe, CRM, bültenler, bu bot) doğrulamaları geçtiğinden emin olduğunuzda sıkılaştırın. Erken açılan katı bir politika kendi postanızı yemeye başlar.

DMARC olmadan: her alıcı kendi bildiğini yapar ve siz adınıza gönderilen postaya ne olduğunu hiç öğrenemezsiniz.

Hangi kayıtlar eklenir

Önce alan adını panelde ekleyin: Email bölümü → "Sending domains" → "Add domain" düğmesi. İletişim kutusunda üç alan vardır: alan adının kendisi (örneğin shop.example.com), adresin yerel kısmı (@ işaretinden önceki bölüm, genelde noreply) ve alıcının adres yerine göreceği gönderen adı. Kaydettikten sonra DNS kayıtlarınız ekranda belirir.

Üçü de alan adınızın DNS'indeki TXT kayıtlarıdır. Alan adınızı yönettiğiniz yerden eklenir: kayıt firmanızın paneli ya da DNS sağlayıcınız.

Aşağıdaki değerler örnek olarak example.com kullanır — kendi alan adınızı koyun. Alan adınıza ait tam değerler panelde alan adı kartında gösterilir; oradan kopyalayın — özellikle DKIM: değeri sizin açık anahtarınızı içerir, her alan adında farklıdır ve belgelerden alınamaz.

Ekranda her kayıt iki ayrı alana bölünmüştür — "Host" ve "Value" — her birinin kendi "Copy" düğmesi vardır. Bunları DNS sağlayıcınızdaki karşılık gelen alanlara teker teker kopyalayın: iki parça tek blok halinde yapıştırılmaz.

En sık takılınan iki nokta:

• Birçok panel alan adını kayıt adına kendisi ekler. Ad alanında zaten ".example.com" yazıyorsa tam adı değil, yalnızca mybot._domainkey yazın; yoksa mybot._domainkey.example.com.example.com çıkar.
• DKIM değeri uzundur ve anahtarın içinde satır sonu ya da boşluk bulunmamalıdır. Fareyle seçerek değil, düğmeyle kopyalayın.

Alan adında zaten bir SPF kaydı varsa

Bir alan adında yalnızca bir SPF kaydı olabilir. Barındırma, CRM ya da başka bir bülten hizmetiyle zaten posta gönderiyorsanız bu kayıt vardır. İkincisini eklemeyin — mevcut kayda, sondaki ~all öncesine bir include daha yazın:

v=spf1 include:spf.saglayiciniz.com include:esp.getmybot.dev ~all

Bir alan adında iki SPF kaydı, hiç olmamasıyla aynı hatadır: doğrulama geçmez, çünkü alıcı hangisine inanacağını bilemez.

Dikkat: başkasının kaydı üzerinden "kapsanmak" yetmez. Şu anki sağlayıcınız bizi kendi SPF'sinde içerse bile, bizim include değerimiz doğrudan sizin kaydınızda olmalıdır — nedeni aşağıda, alan adı doğrulaması bölümünde.

SPF'de neden IP adresi değil include

En sık yapılan hata, bir ileti başlığında ya da bir forumda görülen IP adresini yapıştırmaktır. Bunu yapmayın.

include:esp.getmybot.dev, kendi tuttuğumuz gönderim sunucusu listemize bir işaretçidir. Bugün bu adın arkasında tek bir aktarıcı var. Yarın sayıları artabilir, taşınabilir ya da değiştirilebilir. Bu olduğunda listeyi biz kendi tarafımızda güncelleriz ve sizin kaydınız hiçbir şeye dokunmadan çalışmayı sürdürür. Bütün mesele bu: adres tek bir yerde değişir, her müşterinin DNS'inde değil.

Elle yazılmış bir IP adresi ise o anda geçerliliğini yitirir. E-postalar hiçbir uyarı olmadan SPF'de düşmeye başlar — ne panelde hata, ne bildirim. Bunu "hiçbir şey almadık" diyen müşterilerinizden öğrenirsiniz.

Tam olarak include:esp.getmybot.dev yazın ve buna hiçbir şey eklemeyin.

Alan adı doğrulaması

Alan adı doğrulaması, platformun alan adınızın DNS'ine kendisi bakıp üç kaydın da yolunda olduğunu onaylamasıdır. Üçü de geçerse alan adı doğrulanmış duruma geçer ve gönderime izin verilir. Biri geçmediği sürece beklemede kalır.

Denetlenen şey "kayıt var mı" ile sınırlı değildir:

DMARC neden daha gevşek denetlenir: alıcılara DKIM ve SPF sonuçlarıyla ne yapacaklarını söyler, ama bize sizin adınıza gönderme hakkı vermez. O hakkı yalnızca ilk iki kayıt verir ve ikisi de içerik olarak eksiksiz denetlenir.

Başkasının include'u sayılmaz

include:esp.getmybot.dev kendi SPF kaydınızda yer almalıdır. SPF'niz, kaydı bizi içeren üçüncü bir sağlayıcıyı içeriyorsa doğrulama bunu kabul etmez: platform başkalarının include zincirlerini çözmez. Nedeni basit — "bu alan adı bize yetki verdi mi" sorusunun yanıtı böylece kesin kalır.

Uygulamada: "sağlayıcı üzerinden kapsandığınızdan" emin olsanız bile, include'umuzu doğrudan kendi kaydınıza ekleyin. Ekranın kendisi de SPF açıklamasında aynısını söyler: alan adının zaten bir SPF kaydı varsa, kaydı tümüyle değiştirmek yerine içine include:... değerini ekleyin; çünkü alan adı yalnızca bizim üzerimizden değil, başka yollardan da posta gönderiyor olabilir. Bu not orada sürekli durur, başarısız bir denetimden sonra ortaya çıkmaz.

DNS anında güncellenmez. Kayıtları kayıt firmanızda kaydettikten sonra ad sunucularına yayılmaları gerekir: genellikle dakikalar, bazen saatler, nadiren bir güne kadar. Sağlayıcınıza ve TTL'e bağlıdır. Bu normaldir ve bizim elimizde değildir.

Yine de edilgen biçimde beklemek gerekmez. Platform bekleyen alan adlarını saatte bir kendisi yeniden denetler, ancak alan adı kartında "Verify now" düğmesi vardır: aynı denetim hemen çalıştırılır ve sonuç anında ekrandadır. Kayıtları kaydeder kaydetmez kullanın: bir yazım hatası varsa bunu bir saat sonra değil, bir saniyede öğrenirsiniz. İstediğiniz kadar tekrarlayabilirsiniz.

Alan adının durumu kartta görünür: "Pending verification", "Verified" ya da "Not verified". Doğrulanmadığı sürece kartta ayrıca "Sending from this domain is disabled until it is verified." uyarısı yer alır.

Sonuç yalnızca "başarısız" değildir. Üç kaydın her birinin ekranda kendi durumu — "Passing", "Not passing" veya "Not checked yet" — ve neyin yanlış olduğunu anlatan kendi satırı vardır.

SPF için ekran iki durumu ayırt eder ve bu, tüm akıştaki en önemli ayrımdır:

• Alan adının hiç SPF kaydı yoktur. Yukarıdaki tablodaki değerle bir tane yayımlayın.
• SPF kaydı vardır ama bizim include'umuzu içermez. Include'u var olan kayda ekleyin: ikinci bir kayıt açmayın ve kaydı tümüyle değiştirmeyin. Aynı mesaj zincir durumunu da açıkça kapsar: include bize yalnızca başka bir sağlayıcının SPF kaydı üzerinden ulaşıyorsa bu sayılmaz — zincirler çözülmez.

İkinci durum, tüm akışın en kafa karıştırıcı anıdır: kayıt zaten oradadır, az önce kendiniz okudunuz, doğrulama yine de reddeder. Hata mesajı artık kaydın yanındaki sürekli görünen notla tam olarak aynı şeyi söyler: elinizdekine bizim include'umuzu ekleyin.

Doğrulama geçmiyorsa:

1. Üç kayıttan hangisinin "Not passing" olduğunu ve açıklamasında ne yazdığını okuyun, ona göre hareket edin.
2. Kayıtların gerçekten yayımlandığından emin olun — birçok panel ayrıca "değişiklikleri uygula" ister.
3. Kayıt adında alan adının iki kez yazılmadığını denetleyin (yukarıya bakın).
4. SPF kaydının tek olduğunu ve include'umuzun tam da o kaydın içinde bulunduğunu denetleyin.
5. Biraz bekleyip yeniden denetleyin: değişiklik henüz yayılmamış olabilir.

Doğrulanana kadar gönderim çalışmaz — bu bilinçlidir

Alan adı doğrulanmadığı sürece e-postalar gönderilmez. "Gönderilir ve spam'e düşer" değil — hiç çıkmaz: deneme, doğrulanmamış alan adı hatasıyla biter ve bu günlükte görünür.

Bu bilinçli bir tercihtir, bir arıza değildir. Kendisi için kefil olmamış bir alan adından çıkan posta, spam şikâyetlerine dönüşür; şikâyetler ise platformun tüm müşterilerinin paylaştığı gönderim altyapısının itibarını bozar. Bir iletiyi göndermemek, gönderip sonra altı ay boyunca kara listelerden çıkmaya çalışmaktan ucuzdur. Bu yüzden uyarı değil, yasak vardır.

Bu hatayı görürseniz desteğe yazmadan önce DNS kayıtlarını denetleyip doğrulamayı çalıştırın. Vakaların büyük çoğunluğunda sorun bir kayıt adındaki yazım hatasıdır.

Abonelikten çıkışlar, şikâyetler ve teslim hataları

Önceden bilinmediğinde şaşırtan üç kural.

Her pazarlama iletisinde tek tıkla abonelikten çıkış vardır. Platform, ileti altbilgisine abonelikten çıkış bağlantısını ve posta istemcisinin gönderen adresinin yanına "Abonelikten çık" düğmesi çizmesini sağlayan teknik başlıkları kendisi ekler. Bunu kaldırmak mümkün değildir — ne bir ayarla ne de ileti tasarımıyla. Çıkış, ileti açılmadan ve onay adımı olmadan anında geçerlidir. Gmail ve diğer büyük sağlayıcılar bunu toplu göndericilerden ister: bu olanağı taşımayan ileti kesinlikle spam'e gider.

Abonelikten çıkış kesindir ve arayüzden geri alınamaz. Çıkmış bir adres bu bottan başka posta almaz. "Geri getir" düğmesi yoktur, listeyi yeniden içe aktararak dolanma yolu da yoktur: çıkış hiçbir zaman kişinin iradesi dışında iptal edilmez. Geri dönmeyi ancak kişinin kendisi yapabilir — adresini yeniden abonelik formunuza bırakarak.

Daha da katı bir durum var: biri posta istemcisinde "Bu spam" düğmesine bastıysa adres tamamen kapanır. Formunuz üzerinden yapılan yeni bir abonelik bile onu açmaz — çünkü önceki denemenin nasıl bittiğini zaten biliyoruz ve böyle adreslere yazmak bir alan adının itibarını en hızlı yok eden şeydir. Hukuki talep üzerine elle kapatılan adresler de aynı şekilde davranır.

Sert bir teslim hatası adresi kalıcı olarak kapatır. Alıcının posta sunucusu böyle bir kutunun olmadığını bildirirse adres teslim edilemez olarak işaretlenir ve sonraki gönderimlerden çıkarılır. Bu geçici bir durum değildir: var olmayan bir kutuya ısrar etmek, diğer tüm adreslerle birlikte spam filtrelerine düşmenin en hızlı yoludur.

Geçici hatalar (kutu dolu, sunucu şu an erişilemez) adresi kapatmaz — gönderim sürer.

Açılmalar neden olduğundan az görünür

E-posta istatistiklerinde bir açılma sayısı vardır ve her zaman gerçeğin altındadır. Bu bir sayım hatası değil, açılmaların nasıl ölçüldüğüyle ilgilidir.

Bir açılma, posta istemcisi iletiyi gösterirken bir sunucudan küçücük bir izleme görselini yüklediğinde kaydedilir. Modern istemciler uzak görselleri varsayılan olarak yüklemez; yükleyenler ise (Apple Mail ve benzeri gizlilik işlevleri) bunu iletiyi hiç açmamış olanlar dahil herkes için önceden yapar. İlk durumda açılma kaybolur, ikincisinde orada olmayan birine yazılır. E-posta açılmalarını daha kesin saymanın bir yolu yoktur — ne bizde ne başkasında.

Bu yüzden arayüzde sayının yanında bir uyarı vardır: bu bir alt sınırdır, kesin bir sayı değil. İletileri birbiriyle karşılaştırmak için kullanın; aynı sapma hepsinde geçerlidir. Ama "iletiyi kaç kişi okudu" sorusunun yanıtı olarak kullanmayın.

Güvenilir bir etkileşim ölçütü gerekiyorsa "Link clicks" değerine bakın. Bir bağlantıya tıklamak gerçek bir insanın gerçek eylemidir; kimse onun yerine önceden tıklamaz. "Delivered", "Unsubscribes", "Complaints" ve "Bounces" de tam olarak sayılır: bunları posta sunucuları bildirir, iletideki bir görsel değil. Bunların tümü aynı Email ekranındaki "Sending stats" bloğundadır.

Sırada ne var

• Kanallar — çok kanallılık ve kanal yetenekleri.
• Toplu Gönderimleri — çok sayıda alıcıya gönderim.
• Analitik — sayılara nereden bakılır.