2012-03-20 11 views
23

Wysyłam cotygodniowe wiadomości e-mail do subskrybentów i okazuje się, że wiadomości często trafiają do folderu spamu dla użytkowników.Jak prawidłowo skonfigurować rekordy DNS SPF?

mam wykorzystaniem Amazon SES wysłać te wiadomości i dodaniu rekordu SPF zgodnie z ich instrukcjami: http://docs.amazonwebservices.com/ses/latest/DeveloperGuide/SPFSenderIDDKIM.html?r=3917

W sprawdzania rekordów SPF dla mojej domeny pojawia się następujący powrotem z http://www.kitterman.com/spf/validate.html:

SPF record lookup and validation for: mydomain.tld 

SPF records are primarily published in DNS as TXT records. 

The TXT records found for your domain are: 


SPF records should also be published in DNS as type SPF records. 
Type SPF records found for the domain are: 


Checking to see if there is a valid SPF record. 

Found v=spf1 record for mydomain.tld: 
v=spf1 include:amazonses.com ?all 

evaluating... 
Results - record processed without error. 

The result of the test (this should be the default result of your record) was, none . The explanation returned was, 

Dla moich CloudFlare rekordów DNS mam:

SPF mydomain.tld v=spf1 include:amazonses.com ?all with automatic TTL 
TXT mydomain.tld spf2.0/pra include:amazonses.com ?all with automatic TTL 

E-maile są wysyłane z „no-post @ MYD omain.tld "i" [email protected] ".

Niektórzy użytkownicy zgłosili wyświetlenie następującego komunikatu: "Wiadomości, które fałszywie wydają się być odpowiedzią" odrzuconą wiadomością "(wiadomość wygenerowana przez system, która może zostać automatycznie wysłana po wysłaniu wiadomości, która nie może zostać dostarczona, np. wiadomość wysłana na nieprawidłowy adres e-mail) "

Z mojego obecnego rozwiązania wysyłania nie mogę dodać DKIM do wiadomości e-mail.

W jaki sposób można rozwiązać ten problem, aby zmniejszyć problemy z odbieraniem dla naszych użytkowników?

Odpowiedz

22

Brak ważnych TXT rekordów dla domeny (Zauważ, że test nie zwraca w ogóle, patrz poniżej na przykładzie pracy), które jest spowodowane przez brak cudzysłowy wokół tych TXT zapisów zdefiniowanymi, jak wyjaśniono np w Record Types Supported:

W przeciwieństwie do większości innych typów rekordów, dla TXT rejestruje pole danych jest zasadzie free-form, a nawet mogą zawierać spacji. Uwaga: wprowadzając ciąg znaków zawierający spacje, na przykład zapisy SPF, należy ująć ciąg znaków w cudzysłowy; w przeciwnym razie pojedyncze słowa będą osobno zacytowane i rozbić rekord na wiele części.

Oto TXT zapisy Obecnie stosujemy z powodzeniem Amazon SES zgodnie Authenticating Your Email Address i (jest to rzeczywiście niefortunne, że ich dokumentacja nie zaspokojenia potrzeb cytując):

"v=spf1 include:amazonses.com ~all" 
"spf2.0/pra include:amazonses.com ~all" 

związku z tym, tu jest nasz domeny Skrótowy wynik testu, który wykonałeś:

SPF record lookup and validation for: [...] 

SPF records are primarily published in DNS as TXT records. 

The TXT records found for your domain are: 
spf2.0/pra include:amazonses.com ~all 
v=spf1 include:amazonses.com ~all 

[...] 

Checking to see if there is a valid SPF record. 

Found v=spf1 record for services.marescom.net: 
v=spf1 include:amazonses.com ~all 
+0

Czy istnieją dwa rekordy txt dla Twojej domeny, tj .: 1) twoja_domena.tld: "v = spf1 includ e: amazonses.com ~ all ", a następnie 2) yourdomain.tld:" spf2.0/pra include: amazonses.com ~ all "? – ylluminate

+0

@ylluminate: Rzeczywiście, chociaż mogą nie być potrzebne (test, który właśnie uruchamiasz, wydaje się interesować tym, który masz, zobacz moją aktualizację) - Nigdy nie analizowałem szczegółów wymagań SPF, a jedynie zastosowałem istniejące przykłady do 2 -3 z tych testów SPF zwróciło "cały zielony";) Drugi pochodzi z [Uwierzytelniający e-mail z identyfikatorem nadawcy] (http://docs.amazonwebservices.com/ses/latest/DeveloperGuide/SenderID.html) - Mam naprawiono teraz mylący link (który udał się do [Authenticating Email with SPF] (http://docs.amazonwebservices.com/ses/latest/DeveloperGuide/SPF.html) zamiast ich rodzica). –

+0

@ylluminate: Tylko po to, aby wyjaśnić (i dla późniejszego odniesienia) - czytanie powiązanej dokumentacji SES i powiązanych dokumentów RFC ponownie potwierdza, że ​​SES obsługuje obecnie trzy bezpłatne mechanizmy uwierzytelniania [...]: SPF, ID nadawcy i DKIM_. Rekord, którego już używasz, to _SPF_ (oczywiście), podczas gdy drugi, którego używamy, to _Sender ID_. W związku z tym nie wymaga się _Sender ID_, ale __ dla najlepszych szybkości dostarczania i zapobiegania fałszowaniu i phishingowi, [AWS zaleca], aby wszyscy użytkownicy Amazon SES utrzymywali zarówno rekordy SPF (v = spf1), jak i rekordy Sender ID (spf2. 0/pra) w ich serwerach DNS. –

Powiązane problemy