Podemos ter problemas de reputação com e-mails do Yahoo?
O cabeçalho de email bruto do Yahoo encontra minha política que publiquei:dmarc=success(p=REJECT,sp=REJECT)
E-mails para clientes no Google e no Outlook não estão acabando em spam, mas o Yahoo sim.
Finalmente, uma semana atrás, resolvemos o dkim 'FAIL' com o domínio que estávamos experimentando há um bom tempo.
Esta é uma cópia do último relatório xml dmarc do Yahoo:
<?xml version="1.0"?>
<feedback>
<report_metadata>
<org_name>Yahoo! Inc.</org_name>
<email>[email protected]</email>
<report_id>1596849225.380362</report_id>
<date_range>
<begin>1596758400</begin>
<end>1596844799</end>
</date_range>
</report_metadata>
<policy_published>
<domain>filmfix.com</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>reject</p>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>76.80.54.218</source_ip>
<count>2</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>filmfix.com</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>filmfix.com</domain>
<result>pass</result>
</dkim>
<spf>
<domain>filmfix.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
</feedback>
Parece que estamos todos bem para ir.
Então eu testei enviando um e-mail, e meus e-mails acabaram na minha pasta de spam do Yahoo.
Devo mencionar que meu text/plainbloco bruto sob
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
ainda tem alguns problemas de formatação. Tem muitas =3D20e outras cordas dentro dele. Dificultando a leitura, como aqui:
=3DEF=3DBB=3DBF =3D0D =3DE2=3D9D=3DA4 =3DC3=3D84pfel fallen von B=3DC3=3DA4=
ume wenn sie =3D
=3DC3=3DBCberreif =3D20
sind, oder wenn der Wurm im Apfel steckt. =3D0D =3D0A=3D
(É um trabalho em andamento por enquanto.)
ATUALIZAÇÃO 1:
Desde então, mudei meu registro DNS dmarc de v=DMARC1; p=reject; ...para v=DMARC1; p=none; ...e verei se essa poderia ser a razão pela qual eles às vezes nem são entregues; nem no spam!
e agora estou de volta para:v=DMARC1; p=quarantine; ...
ATUALIZAÇÃO 2:
Hoje recebemos uma solicitação de consulta de orçamento de um e-mail da bellsouth.net. Ele não recebeu nossa resposta por e-mail de estimativa automática.
Descobrimos esse fato enviando a ele um e-mail separado, sem nenhum link, mas ainda usando FilmFix.com, mas esse e-mail acabou em sua pasta de spam .
Response received from 76.80.54.218:
Authoritative response (AA): No
Recursion available (RA): Yes
Truncated (TC): No
Answer section:
A-record for bellsouth.net:
IP address: 216.77.188.73
TTL = 10800 (3 hours)
Additional section:
EDNS0 options:
UDP payload size: 1280
DNSSEC OK (DO flag): No
procurando o IP 73.188.77.216.in-addr.arpa, recebo isso:
Response received from 76.80.54.218:
Authoritative response (AA): No
Recursion available (RA): Yes
Truncated (TC): No
Header:
RCODE 3 - Non-Existent Domain
Authority section:
SOA-record for 77.216.in-addr.arpa:
Primary DNS server: ns0.attdns.net
Responsible person: [email protected]
Serial number: 2019121901
Refresh interval: 3600
Retry interval: 1800
Expire interval: 2592000
Default / minimum TTL: 300
TTL = 300 (5 minutes)
Additional section:
EDNS0 options:
UDP payload size: 1280
DNSSEC OK (DO flag): No
Também costumávamos ter a AT&T como ISP, fornecendo também uma entrada rDNS na época (para um endereço IP diferente).
ATUALIZAÇÃO 3:
Aqui estão minhas configurações de DNS (uma perda parcial). Eu uso o Simple DNS Plus como controlador.
Acabei de notar que há uma entrada para 76-80-54-219.filmfix.net com um número de prioridade menor de [10] (marcado em azul), enquanto 76-80-54-218.filmfix.net tem [11 ]. Eu só tenho configuração spf, dkim e dmarc para IP 76.80.54.218, então fui em frente e removi essa entrada 76-80-54-219.filmfix.net. Não tenho certeza se isso poderia estar causando um problema. O Gmail e o Outlook funcionaram bem com essa configuração.
Algum tempo atrás, bem antes do spf, dkim e dmarc, foi sugerido ter dois IPs para não acabar em spam. Não tenho certeza se isso ainda é assim.
ATUALIZAÇÃO 4:
Tenho monitorado meus relatórios dmarc. Eu uso easydmarc.com para lê-los. aqui está meu relatório de 31 de agosto de 2020 a 14 de setembro de 2020 , também aqui como imagem:
Em 2 de setembro, o Yahoo! Inc. registrou uma falha de dkim e, em 7 de setembro, uma passagem de dkim (mas sem anotação do resultado de dkim). Parece que ainda estamos tendo problemas com o Yahoo.
No relatório, parece que tivemos duas tentativas de falsificação de identidade. Um por secureserver.net 173.201.193.33 e outro por hostpoint.ch 217.26.49.174, se estou lendo isso corretamente.
Além disso, adicionei um rastreador de imagem aos meus e-mails de resposta automática "solicitando uma estimativa". Assim posso identificar se um usuário está recebendo o e-mail que solicitou.
Solicitação de endereços de e-mail desses domínios
- @gmail.com
- @icloud.com
- @swissmail.org
- @wibox.fr
registrou a imagem conforme solicitado.
Estes não retornaram uma solicitação para a imagem, do que posso concluir (com alguma suposição) que o email nunca foi visualizado (e provavelmente acabou em spam):
- @yahoo.com
- @verizon.net
- @spamgourmet.com
- @ameritech.net
ATUALIZAÇÃO 5:
Agora estou mudando gradualmente para a política de rejeição do dmarc para e-mails com falha.
Esta é uma nova política
v=DMARC1; p=reject; pct=25; rua=mailto:[left out]; ruf=mailto:[left out]; sp=reject; fo=0:1:d:s;
1 respostas