SPF, DKIM ve DMARC için DNS TXT bölgesi nasıl ayarlanır ve iş e-posta iletilerinin Gmail tarafından reddedilmesini nasıl önlersiniz - Posta teslimi başarısız oldu

Administratorben de iş için ciddi özel e-posta çoğu zaman birçok sorun ve zorlukla karşı karşıyadır. dalgalarından SPAM belirli filtreler tarafından engellenmesi gereken, yazışma güvenliği yerel e-posta sunucusunda ve uzak sunucularda, yapılandırma si SMTP hizmetlerini izleme, POP, IMAP, artı birçok başka ayrıntı SPF, DKIM ve DMARC yapılandırması güvenli e-posta gönderimi için en iyi uygulamaları takip etmek.

Pek çok sorun e-posta mesajları gönder veya alıcı sağlayıcılarınıza / sağlayıcılarınızdan, alanın yanlış yapılandırılması nedeniyle görünür DNS, peki ya e-posta servisi.

Bir alan adından e-posta gönderilebilmesi için, bir e-posta sunucusunda barındırılan Uygun şekilde yapılandırılmış ve DNS bölgelerine sahip alan adı için SPF, MX, DMARC SI DKIM yöneticide doğru şekilde ayarla DNS TXT'si etki alanı.

Bugünün makalesinde oldukça yaygın bir soruna odaklanacağız. özel iş e-posta sunucuları. Gmail'e e-posta gönderilemiyor, Yahoo! veya iCloud.

@ Gmail.com'a gönderilen iletiler otomatik olarak reddedilir. "Posta teslimi başarısız oldu: iletiyi gönderene iade ediyor"

Geçenlerde bir sorunla karşılaştım bir şirketin e-posta etki alanı, e-postaların düzenli olarak diğer şirketlere ve bazılarının adresleri olan kişilere gönderildiği @ gmail.com. Gmail hesaplarına gönderilen tüm iletiler anında gönderene geri döner. "Posta teslimi başarısız oldu: iletiyi gönderene iade ediyor".

E-posta sunucusuna şu tarihte döndürülen hata mesajı: EXIM buna benzer:

1nSeUV-0005zz-De ** reciver@gmail.com R=dnslookup T=remote_smtp H=gmail-smtp-in.l.google.com [142.x.x.27] X=TLS1.2:ECDHE-ECDSA-AES128-GCM-SHA256:128 CV=yes: SMTP error from remote mail server after pipelined end of data: 550-5.7.26 This message does not have authentication information or fails to\n550-5.7.26 pass authentication checks. To best protect our users from spam, the\n550-5.7.26 message has been blocked. Please visit\n550-5.7.26  https://support.google.com/mail/answer/81126#authentication for more\n550 5.7.26 information. d3-20020adff843000000b001f1d7bdaeb7si6107985wrq.510 - gsmtp

Bu senaryoda, çok ciddi bir şey değil, örneğin bir SPAM listesine gönderen alan adını veya gönderen IP'yi dahil edin küresel veya o büyük yapılandırma hatası sunucudaki e-posta servislerinin (EXIM).
Birçoğu bu mesajı gördüklerinde hemen SPAM veya SMTP yapılandırma hatası düşünse bile, sorun alandan kaynaklanmaktadır. DNS TXT'si etki alanı. Çoğu zaman, DKIM DNS bölgesinde yapılandırılmaz veya etki alanının DNS yöneticisinden doğru şekilde geçirilmez. Bu sorun genellikle kullananlarda bulunur. CloudFlare DNS Yöneticisi olarak ve geçmeyi unutmayın DNS TXT'si: posta._etkialanıanahtarı (DKIM), DMARC si SPF.

Gmail'in ret mesajının bize bildirdiği gibi, gönderen alan adının gerçekliği ve kimlik doğrulaması başarısız oldu. “Bu iletide kimlik doğrulama bilgisi yok veya \ n550-5.7.26 kimlik doğrulama denetimlerini geçemiyor. ” Bu, alanın, alıcının e-posta sunucusunun güvenilirliğini sağlamak için yapılandırılmış DNS TXT'ye sahip olmadığı anlamına gelir. Gmail, komut dosyamızda.

cPanel'inde aktif bir e-posta servisi olan bir web etki alanı eklediğimizde VestaCP, ilgili etki alanının DNS bölgesindeki dosyalar da otomatik olarak oluşturulur. E-posta hizmetinin yapılandırmasını içeren DNS bölgesi: MX, SPF, DKIM, DMARC.
Yönetici olarak etki alanını seçtiğimiz durumda DNS Bulut Parlaması, e-posta alan adının düzgün çalışması için alan adının barındırma hesabının DNS alanının CloudFlare'e kopyalanması gerekir. Yukarıdaki senaryodaki sorun buydu. Bir üçüncü taraf DNS yöneticisinde, yerel sunucunun DNS yöneticisinde bulunmasına rağmen DKIM kaydı mevcut değildir.

DKIM nedir ve bir e-posta etki alanında bu özellik yoksa e-postalar neden reddedilir?

DomainKeys Tanımlı Posta (DKIM) ekleyen standart bir e-posta etki alanı kimlik doğrulama çözümüdür. dijital imzalar gönderilen her mesaj. Hedef sunucular, mesajın gönderenin kimliğini maske olarak kullanan başka bir alan adından değil, gönderenin hukuk alanından gelip gelmediğini DKIM üzerinden kontrol edebilir. Etki alanınız varsa, tüm hesaplara göre ABCDqwerty.com DKIM olmadan, alan adınızı kullanan diğer sunuculardan e-postalar gönderilebilir. Teknik terimlerle adlandırılan bir kimlik hırsızlığı istiyorsanız, e-posta sahteciliği.
E-posta mesajları gönderirken yaygın bir teknik Kimlik avı si Spam.

DKİM aracılığıyla da sağlanabilmektedir. gönderen tarafından gönderildikten sonra mesajın içeriği değişmedi.

DKIM'in e-posta sisteminin katı ana bilgisayarında ve DNS alanında doğru ayarlanması, mesajlarınızın alıcıya SPAM'e ulaşma veya hiç ulaşmama ihtimalini de ortadan kaldırır.

Bir DKIM örneği:

mail._domainkey: "v=DKIM1; k=rsa; p=MIGfMA0GCSqGfdSIb3DQEBAQUAA4GN ... ocqWffd4cwIDAQAB"

Tabii ki, elde edilen DKIM değeri RSA şifreleme algoritması her alan adı için benzersizdir ve ana bilgisayarın e-posta sunucusundan yeniden oluşturulabilir.

DKIM'in doğru şekilde kurulması ve ayarlanması DNS TXT'si yönetici, Gmail hesaplarına dönen mesajlar sorununu çözmek çok mümkün. En azından "Posta teslimi başarısız oldu" hatası için:

"SMTP error ardışık veri sonundan sonra uzak posta sunucusundan: 550-5.7.26 Bu iletinin kimlik doğrulama bilgisi yok veya \ n550-5.7.26 kimlik doğrulama denetimlerini geçemiyor. Kullanıcılarımızı spam'den en iyi şekilde korumak için \ n550-5.7.26 mesajı engellendi. ”

Kısa bir özet olarak, DKIM gönderilen her mesaja bir dijital imza ekler, hedef sunucuların gönderenin gerçekliğini doğrulamasını sağlar. Mesaj şirketinizden geldiyse ve kimliğinizi kullanmak için üçüncü taraf adresi kullanılmadıysa.

Gmail (Google) belki tüm mesajları otomatik olarak reddeder böyle bir DKIM dijital semantiğine sahip olmayan alanlardan geliyor.

SPF nedir ve güvenli e-posta gönderimi için neden önemlidir?

Tıpkı DKİM gibi ve SPF önlemeyi amaçlar kimlik avı mesajları si e-posta sahteciliği. Bu şekilde gönderilen mesajlar artık spam olarak işaretlenmeyecek.

Gönderen Politikası Çerçevesi (SPF) mesajların gönderildiği alanın kimliğini doğrulamak için standart bir yöntemdir. SPF girişleri şu şekilde ayarlandı: TXT DNS yöneticisi ve bu giriş, sizin veya kuruluşunuzun etki alanı adını kullanarak e-posta iletileri göndermesine izin verilen etki alanı adını, IP'yi veya etki alanlarını belirtir.

SPF içermeyen bir alan, spam gönderenlerin diğer sunuculardan e-posta göndermesine izin verebilir. alan adınızı maske olarak kullanmak. bu şekilde yayılabilirler yanlış bilgi veya hassas veriler istenebilir kuruluşunuz adına

Elbette, diğer sunuculardan sizin adınıza iletiler gönderilmeye devam edebilir, ancak bu sunucu veya alan adı alan adınızın SPF TXT girişinde belirtilmemişse, spam olarak işaretlenir veya reddedilir.

DNS yöneticisindeki bir SPF değeri şöyle görünür:

@ : "v=spf1 a mx ip4:x.x.x.x ?all"

"ip4", e-posta sunucunuzda IPv4'tür.

Birden çok alan için SPF'yi nasıl ayarlarım?

Diğer alan adlarına alan adımız adına e-posta mesajları gönderme yetkisi vermek istiyorsak bunları "değeri" ile belirteceğiz.include”SPF TXT'de:

v=spf1 ip4:x.x.x.x include:example1.com include:example2.com ~all

Bu, e-posta mesajlarının alan adımızdan example1.com ve example2.com'a da gönderilebileceği anlamına gelir.
Örneğin elimizde bir tane varsa bu çok faydalı bir kayıttır. alışveriş adresinde "örnek1.com", Ancak çevrimiçi mağazadan müşterilere gönderilen mesajların ayrılmasını istiyoruz şirket etki alanı adresi, bu varlık"example.com". İçinde SPF TXT'si "example.com" için, IP'nin yanında belirtmek için gerektiği gibi ve "include: example1.com". Böylece kurum adına mesajlar gönderilebilir.

IPv4 ve IPv6 için SPF'yi nasıl ayarlarım?

Her ikisine de sahip bir posta sunucumuz var IPv4 ile IPv6, her iki IP'nin de SPF TXT'de belirtilmesi çok önemlidir.

v=spf1 ip4:196.255.100.26 ip6:2001:db8:8:4::2 ~all

Ardından, "ip" yönergesinden sonra "include”Gönderim için yetkilendirilmiş alan adları eklemek için.

Bu ne anlama geliyor "~all""-all"Ve"+allSPF'den mi?

Yukarıda belirtildiği gibi, sağlayıcılar (ISS'ler), SPF politikasında belirtilmeyen bir etki alanından veya IP'den gönderilmiş olsalar bile, kuruluşunuz adına e-posta almaya devam edebilir. "Tümü" etiketi, hedef sunuculara diğer yetkisiz alanlardan gelen bu iletileri nasıl ele alacaklarını ve siz veya kuruluşunuz adına iletileri nasıl göndereceklerini söyler.

~all : İleti, SPT TXT'de listelenmeyen bir etki alanından alınırsa, iletiler hedef sunucuda kabul edilir, ancak spam veya şüpheli olarak işaretlenir. Alıcı sağlayıcının istenmeyen posta önleme filtrelerinin en iyi uygulamalarına tabi olacaklardır.

-all : Bu, bir SPF girişine eklenen en katı etikettir. Alan adı listelenmemişse, mesaj yetkisiz olarak işaretlenir ve sağlayıcı tarafından reddedilir. O da teslim edilmeyecek macspam'de.

+all : Çok nadiren kullanılan ve hiç tavsiye edilmeyen bu etiket, başkalarının sizin veya kuruluşunuz adına e-posta göndermesine olanak tanır. Çoğu sağlayıcı, SPF TXT'li alanlardan gelen tüm e-posta iletilerini otomatik olarak reddeder."+all". Bunun nedeni, bir "e-posta başlığı" kontrolü dışında gönderenin gerçekliğinin doğrulanamamasıdır.

Özet: Gönderen Politikası Çerçevesi (SPF) ne anlama geliyor?

TXT/SPF DNS zone, IP'ler ve domaininizden veya firmanızdan e-mail mesajları gönderebilen domain adları üzerinden yetki verir. Ayrıca yetkisiz alanlardan gönderilen iletilere uygulanan sonuçları da uygular.

DMARC ne anlama geliyor ve e-posta sunucunuz için neden önemli?

DMARC (Etki Alanı Tabanlı İleti Kimlik Doğrulama Raporlaması ve Uyumluluk) politika standartlarıyla yakından bağlantılıdır SPF si DKIM.
DMARC bir doğrulama sistemi korumak için tasarlandı sizin veya şirketinizin e-posta alan adı, e-posta sahtekarlığı gibi uygulamalar ve kimlik avı dolandırıcılığı.

Sender Policy Framework (SPF) ve Domain Keys Identified Mail (DKIM) kontrol standartlarını kullanan DMARC, çok önemli bir özellik ekler. raporlar.

Bir alan sahibi, DNS TXT alanında DMARC yayınladığında, kendisi veya SPF ve DKIM tarafından korunan alan adının sahibi olan şirket adına e-posta iletilerini kimin gönderdiği hakkında bilgi edinecektir. Aynı zamanda, mesajların alıcıları, bu iyi uygulama politikalarının gönderen alan sahibi tarafından izlenip izlenmediğini ve nasıl izlendiğini bilecektir.

DNS TXT'deki bir DMARC kaydı şunlar olabilir:

V=DMARC1; rua=mailto:report-id@rep.example.com; ruf=mailto:account-email@for.example.com; p=none; sp=none; fo=0;

DMARC'de olayları raporlamak için daha fazla koşul ve analiz ve raporlar için e-posta adresleri koyabilirsiniz. Alınan mesajların hacmi önemli olabileceğinden, DMARC için özel e-posta adreslerinin kullanılması tavsiye edilir.

DMARC etiketleri, sizin veya kuruluşunuz tarafından uygulanan politikaya göre ayarlanabilir:

v - mevcut DMARC protokolünün versiyonu.
p - DMARC e-posta mesajları için doğrulanamadığında bu politikayı uygulayın. Şu değere sahip olabilir: “none""quarantine"Ya da"reject". Kullanıldı "none” mesaj akışı ve pin durumu hakkında rapor almak içinsora.
rua - ISP'lerin XML formatında geri bildirim gönderebilecekleri URL'lerin listesidir. E-posta adresini buraya eklersek, bağlantı şöyle olacaktır:rua=mailto:feedback@example.com".
ruf - ISP'lerin, kuruluşunuz adına işlenen siber olaylar ve suçlarla ilgili raporları gönderebileceği URL'lerin listesi. Adres şöyle olacaktır:ruf=mailto:account-email@for.example.com".
rf - Siber suç raporlama formatı. şeklinde olabilir"afrf"Ya da"iodef".
pct - ISS'ye DMARC politikasını yalnızca başarısız mesajların belirli bir yüzdesi için uygulaması talimatını verir. Örneğin, sahip olabiliriz:pct=50%"Ya da politikalar"quarantine"Ve"reject". Asla kabul edilmeyecektir."none".
adkim – “Hizalama Mode” DKIM dijital imzaları için. Bu, bir DKIM girişinin dijital imzasının etki alanı ile eşleşmesinin kontrol edildiği anlamına gelir. adkim değerlere sahip olabilir: r (Relaxed) ya da s (Strict).
aspf - Durumda olduğu gibi adkim "Hizalama" belirtildi Mode” SPF için ve aynı değerleri destekliyor. r (Relaxed) ya da s (Strict).
sp - Bu politika, kuruluş alanından türetilen alt alan adlarının, alanın DMARC değerini kullanmasına izin vermek için geçerlidir. Bu, her alan için ayrı politikaların kullanılmasını önler. Tüm alt alanlar için pratik olarak bir "joker karakterdir".
ri - Bu değer, DMARC için XML raporlarının alınacağı aralığı belirler. Çoğu zaman, günlük olarak raporlama tercih edilir.
fo - Dolandırıcılık raporları için seçenekler. “Adli options". Hem SPF hem de DKIM doğrulaması başarısız olduğunda olayları bildirmek için "0" değerlerine veya SPF veya DKIM'nin olmadığı veya doğrulamayı geçmediği senaryo için "1" değerine sahip olabilirler.

Bu nedenle sizin veya şirketinizin e-postalarının gelen kutunuza ulaşmasını sağlamak için bu üç standardı göz önünde bulundurmalısınız."e-posta göndermek için en iyi uygulamalar". DKIM, SPF si DMARC. Her üç standart da DNS TXT ile ilgilidir ve etki alanının DNS yöneticisinden yönetilebilir.

Teknolojiye tutkulu, 2006 yılından beri StealthSettings.com'da yazıyorum. macOS, Windows ve Linux işletim sistemlerinde geniş deneyimim var, aynı zamanda programlama dilleri ve blog platformları (WordPress) ile online mağazalar için (WooCommerce, Magento, PrestaShop) bilgi sahibiyim.

nasıl » önemli » SPF, DKIM ve DMARC için DNS TXT bölgesi nasıl ayarlanır ve iş e-posta iletilerinin Gmail tarafından reddedilmesini nasıl önlersiniz - Posta teslimi başarısız oldu

1, "SPF, DKIM ve DMARC için TXT DNS bölgesi nasıl yapılandırılır ve iş e-posta iletilerinin Gmail tarafından reddedilmesini nasıl önleyebilirim - Posta teslimi başarısız oldu" üzerine düşündüm

Leave a Comment