Email Spam Tester Executar um teste · Para agentes · API · Blog

Como funciona o teste

Envie uma mensagem para um endereço descartável e serão executadas 42 verificações. Esta página apresenta-as todas: o que cada uma analisa, quanto desconta à sua pontuação quando falha e a secção da norma de onde provém.

Nada do que está aqui é a nossa opinião apresentada como regra. Quando uma verificação aplica algo indicado por uma norma, a frase dessa norma é citada por baixo. Quando aplica algo exigido pelo Google ou pelo Yahoo, é fornecida uma ligação para a respetiva página. Quando se baseia no nosso próprio critério, isso é indicado.

Atualizado:

VerificaçãoGrupoA nossa pontuaçãoPontuação clássica
Cadeia ARCAutenticação−20
Assinatura DKIMAutenticação−18−1
Alinhamento DKIMAutenticação−10−1
Resultado DMARCAutenticação−140
Sender IDAutenticação−5−0.5
SPFAutenticação−18−1
Alinhamento SPFAutenticação−5−0.5
Resolução do nome de anfitrião de envioInfraestrutura e reputação−5−3
Listas de bloqueioInfraestrutura e reputação−25−3
Nome HELOInfraestrutura e reputação−50
Registo MXInfraestrutura e reputação−5−3
DNS inversoInfraestrutura e reputação−12−1.5
Encriptação de transporteInfraestrutura e reputação−50
Avaliação por IAMotores de spam
Veredito combinadoMotores de spam−250
Postmark SpamCheckMotores de spam
RspamdMotores de spam
SpamAssassinMotores de spam0−3
Texto alternativo das imagensConteúdo−4−0.5
Disponibilidade das ligaçõesConteúdo−5−1
Script e iframeConteúdo−10−1
Equilíbrio entre texto e HTMLConteúdo−3−0.3
Partes de texto e HTMLConteúdo−50
Tamanho do HTMLConteúdo−3−0.3
Peso das imagensConteúdo−3−0.3
Destinos das ligações visíveisConteúdo−30
Reputação das ligaçõesConteúdo−400
Análise de anexosConteúdo−600
Pré-cabeçalhoConteúdo−20
Linha de assuntoConteúdo−30
Ligações encurtadasConteúdo−5−0.5
Política DMARC publicadaRegras para remetentes em massa−60
List-UnsubscribeRegras para remetentes em massa−10−1
Cancelamento da subscrição com um cliqueRegras para remetentes em massa−80
TLS para correio em massaRegras para remetentes em massa−50
BIMIRecomendações00
Idade e comprimento da chave DKIMRecomendações00
Entrega de relatórios DMARCRecomendações00
DNSSECRecomendações00
MTA-STSRecomendações00
Comprimento do caminho de retornoRecomendações00
Relatórios TLSRecomendações00

Autenticação

Se o servidor recetor consegue provar que a mensagem veio de onde afirma ter vindo. Esta é a metade da capacidade de entrega que depende exclusivamente de DNS e a metade que o Gmail e o Yahoo tornaram obrigatória para remetentes em massa em 2024.

Cadeia ARC auth.arc

O ARC preserva o resultado da autenticação através de um reencaminhador. Sem ele, uma lista de distribuição que acrescente um rodapé invalida a sua assinatura DKIM e a cópia reencaminhada falha o DMARC no destino final.

Se falhar: Nada a fazer enquanto remetente. Isto é importante se operar uma lista ou um reencaminhador e explica por que motivo algumas das suas mensagens falham o DMARC depois de alguém as reencaminhar.

Desconta até 2 pontos em 100 na nossa pontuação.

RFC 7960 §1 — Introduction

DMARC with restrictive policies causes problems for many Mailing Lists.

RFC 8617 §2.1 — Evidence

In ARC's situation, the "evidence" is a message's authentication assessment at any point along the delivery path between origination and final delivery.

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Assinatura DKIM auth.dkim

DKIM assina partes da mensagem com uma chave privada e publica a chave pública no DNS. Verificamos todas as assinaturas incluídas na mensagem e comunicamos o domínio de assinatura, o seletor e o comprimento da chave.

Se falhar: Ative o DKIM na sua plataforma de envio e publique a chave que esta lhe fornece. Utilize 2048 bits: 1024 ainda permite a verificação, mas uma chave tão curta pode ser quebrada e já não é segura.

Desconta até 18 pontos em 100 na nossa pontuação e até 1 em 10 na pontuação clássica.

RFC 6376 §3.5 — The DKIM-Signature Header Field

The signature of the email is stored in the DKIM-Signature header field.

RFC 6376 §6.1 — Extract Signatures from the Message

Verifiers MUST NOT attribute ultimate meaning to the order of multiple DKIM-Signature header fields.

RFC 8301 §3.1 — Signing and Verification Algorithms

rsa-sha1 MUST NOT be used for signing or verifying.

RFC 8463 §6 — Transition Considerations

For backward compatibility, signers can add multiple signatures that use old and new signing algorithms.

Google — Set up DKIM

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Alinhamento DKIM auth.dkim_alignment

Uma assinatura válida não é suficiente para o DMARC. O domínio de assinatura tem de corresponder ao domínio do cabeçalho From, exatamente ou por domínio organizacional, consoante a política que publicou.

Se falhar: Assine com o seu próprio domínio em vez do domínio da sua plataforma. A maioria das plataformas permite fazê-lo e chama-lhe domínio de envio personalizado ou autenticado.

Desconta até 10 pontos em 100 na nossa pontuação e até 1 em 10 na pontuação clássica.

RFC 9989 §4.4.1 — DKIM-Authenticated Identifiers

A single email can contain multiple DKIM signatures, and it is considered to produce a DMARC "pass" result if any DKIM-Authenticated Identifier aligns with the Author Domain.

Google — Set up DMARC

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Resultado DMARC auth.dmarc

O DMARC associa o SPF e o DKIM ao domínio que o leitor vê e indica aos recetores o que fazer quando nenhum deles está alinhado. Comunicamos a política publicada e se esta mensagem a cumpriu.

Se falhar: Publique um registo DMARC. Comece com p=none, leia os relatórios durante algumas semanas e depois passe para quarentena quando souber que outros sistemas enviam mensagens em seu nome.

Desconta até 14 pontos em 100 na nossa pontuação.

RFC 9989 §5.3.5 — Determine DMARC "Pass" or "Fail"

If no Authenticated Identifiers exist for the domain, or none of the Authenticated Identifiers align with the Author Domain, the message is considered to fail the DMARC mechanism check.

RFC 9989 §4.7 — DMARC Policy Record Format

DMARC Policy Records follow the extensible "tag-value" syntax for DNS-based key records defined in DKIM [RFC6376].

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Yahoo — Sender requirements and recommendations

Sender ID auth.sender_id

A mesma verificação que o SPF, executada no domínio do cabeçalho From em vez de no envelope. Responde a uma pergunta diferente: se o domínio que o leitor vê autoriza o servidor que enviou a mensagem. Uma mensagem pode passar no SPF do envelope enquanto o domínio visível não avaliza ninguém.

Se falhar: Publique SPF para o domínio do cabeçalho From, não apenas para o domínio de devolução que a sua plataforma lhe forneceu.

Desconta até 5 pontos em 100 na nossa pontuação e até 0.5 em 10 na pontuação clássica.

RFC 4406 §4 — Record Selection

After the above steps, there should be one record remaining and evaluation can proceed.

SPF auth.spf

SPF é um registo DNS que indica quais os servidores que podem enviar mensagens em nome do seu domínio. O servidor recetor usa o endereço no envelope, consulta o registo desse domínio e verifica se o IP que estabelece a ligação está incluído. Comunicamos o resultado e o número de consultas DNS de que o registo necessitou, porque a avaliação para nas dez e qualquer valor acima desse limite constitui um erro permanente em vez de uma aprovação.

Se falhar: Publique um registo que identifique a sua plataforma de envio e nada mais. Se o seu estiver próximo do limite de dez consultas, simplifique as inclusões que não utiliza (um registo que hoje é aprovado começa a falhar no dia em que um fornecedor adiciona uma inclusão própria).

Desconta até 18 pontos em 100 na nossa pontuação e até 1 em 10 na pontuação clássica.

RFC 7208 §4.6.4 — DNS Lookup Limits

SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS. If this limit is exceeded, the implementation MUST return "permerror".

RFC 7208 §2.6 — Results of Evaluation

Section 4 defines check_host(), a model function definition that uses the inputs defined above and the sender's policy published in the DNS to reach a conclusion about client authorization.

Google — Set up SPF

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Alinhamento SPF auth.spf_alignment

Indica se o endereço de devolução corresponde ao endereço From que o leitor vê. O SPF autoriza o envelope, e o DMARC só considera essa autorização quando os dois estão alinhados.

Se falhar: Peça à sua plataforma de envio um subdomínio de devolução do seu próprio domínio. Se o seu DKIM já estiver alinhado, isto não é urgente, mas fica sem alternativa quando o DKIM falha em trânsito.

Desconta até 5 pontos em 100 na nossa pontuação e até 0.5 em 10 na pontuação clássica.

RFC 9989 §4.4.2 — SPF-Authenticated Identifiers

Only an SPF-Authenticated Identifier that has Identifier Alignment with the Author Domain is enough to validate the authorized use of the Author Domain.

RFC 9989 §5.3.5 — Determine DMARC "Pass" or "Fail"

If one or more of the Authenticated Identifiers align with the Author Domain, the message is considered to pass the DMARC mechanism check.

Google — Set up DMARC

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Infraestrutura e reputação

A máquina e o endereço a partir dos quais a mensagem foi enviada e o que o resto da Internet já pensa deles.

Resolução do nome de anfitrião de envio infra.a_record

Se o nome de anfitrião anunciado no HELO tem sequer um registo de endereço.

Se falhar: Publique um registo A para o nome que o seu servidor anuncia.

Desconta até 5 pontos em 100 na nossa pontuação e até 3 em 10 na pontuação clássica.

RFC 5321 §5.1 — Locating the Target Host

If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host.

Google — Set up MX records

Listas de bloqueio infra.dnsbl

Se o IP de envio está listado por alguma das listas de bloqueio que os destinatários realmente consultam. A nossa lista é verificada no ponto de teste documentado de cada zona, em vez de ser compilada a partir de uma pesquisa na Web, porque uma zona inativa responde NXDOMAIN e isso é interpretado como "limpo".

Se falhar: Siga o processo de remoção da lista no site do operador que efetuou a inclusão. Uma inclusão numa zona importante bloqueia imediatamente o correio, por isso trate-a antes de qualquer outra coisa na página.

Desconta até 25 pontos em 100 na nossa pontuação e até 3 em 10 na pontuação clássica.

RFC 5782 §2.1 — IP Address DNSxL

Each IPv4 address listed in the DNSxL has a corresponding DNS entry.

RFC 5782 §5 — Test and Contact Addresses

IPv4-based DNSxLs MUST contain an entry for 127.0.0.2 for testing purposes.

Google — Postmaster Tools: reputation and delivery errors

Google — Email sender guidelines

Nome HELO infra.helo

O nome com que o servidor de envio se anuncia no início da comunicação SMTP. Tem de ser um domínio totalmente qualificado que possa ser resolvido.

Se falhar: Defina o nome de anfitrião do seu servidor de correio como um nome real no seu domínio, não como o ID de um contentor ou um nome interno.

Desconta até 5 pontos em 100 na nossa pontuação.

RFC 5321 §4.1.1.1 — Extended HELLO (EHLO) or HELLO (HELO)

The argument clause contains the fully-qualified domain name of the SMTP client, if one is available.

Google — Email sender guidelines

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Registo MX infra.mx

Se o domínio no cabeçalho From pode receber correio. Sem ele, as respostas e as devoluções não têm para onde ir, e os filtros consideram um domínio de envio que não pode receber correio um mau sinal.

Se falhar: Publique um registo MX para o domínio a partir do qual envia, mesmo que apenas encaminhe para uma caixa de correio que lê uma vez por mês.

Desconta até 5 pontos em 100 na nossa pontuação e até 3 em 10 na pontuação clássica.

RFC 5321 §5.1 — Locating the Target Host

The lookup first attempts to locate an MX record associated with the name.

Google — Set up MX records

DNS inverso infra.rdns

Se o IP de envio é resolvido de volta para um nome de anfitrião e se esse nome de anfitrião é resolvido diretamente para o mesmo IP. A correspondência nos dois sentidos é o essencial: é fácil ter um PTR que aponte para qualquer lado, mas um par correspondente é prova de que o endereço lhe pertence.

Se falhar: Peça a quem for proprietário do IP para definir o PTR como um nome que controla e certifique-se de que esse nome tem um registo A que aponta de volta.

Desconta até 12 pontos em 100 na nossa pontuação e até 1.5 em 10 na pontuação clássica.

RFC 1912 §2.1 — Inconsistent, Missing, or Bad Data

Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain.

Google — Email sender guidelines

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Encriptação de transporte infra.tls

Se a mensagem chegou através de TLS e com que algoritmo de cifra. Todos os sistemas modernos o negoceiam; uma mensagem que chega sem encriptação revela algo sobre a configuração de envio.

Se falhar: Ative STARTTLS no servidor de envio. Todas as plataformas comuns já o fazem, pelo que uma falha neste ponto significa normalmente que existe um relay autoalojado no percurso.

Desconta até 5 pontos em 100 na nossa pontuação.

RFC 3207 §2 — STARTTLS Extension

The STARTTLS extension to SMTP is laid out as follows:

Google — Send email over a secure TLS connection

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Motores de spam

Como filtros de conteúdo independentes avaliam a mensagem. Dois motores em vez de um, porque a pontuação de um único motor é a opinião desse motor.

Avaliação por IA spam.ai_judge

Um modelo estima como um filtro moderno de aprendizagem automática trataria a mensagem, com base nas conclusões técnicas e nas medições do conteúdo. Vê os factos, não o texto do corpo.

Se falhar: Isoladamente, é apenas informativo. A sua estimativa contribui para o veredito combinado abaixo.

Apresentado para referência. Nunca afeta a pontuação.

Veredito combinado spam.panel

Um número proveniente dos motores que responderam, ponderado para que o mais categórico não seja simplesmente diluído pela média. SpamAssassin e Postmark contam como um único voto porque partilham uma base de regras.

Se falhar: Analise as conclusões individuais. Esta linha muda quando elas mudam.

Desconta até 25 pontos em 100 na nossa pontuação.

Google — Why Gmail marks messages as spam

How this score is calculated

Postmark SpamCheck spam.postmark

Uma terceira opinião, desativada por predefinição. O respetivo endpoint recebe a mensagem completa e não podemos ocultar nenhuma parte sem destruir aquilo que está a ser medido, pelo que ativá-la significa aceitar que cada mensagem testada é copiada para terceiros.

Se falhar: Não há nada a fazer. Quando está desativada, a verificação indica que está desativada, o que não é o mesmo que uma aprovação.

Apresentado para referência. Nunca afeta a pontuação.

Rspamd spam.rspamd

Um segundo filtro, desenvolvido de forma independente. Diverge do SpamAssassin com frequência suficiente para justificar a consulta, razão pela qual está aqui.

Se falhar: Apenas informativo. A avaliação deste motor é incorporada no veredito combinado, em vez de receber uma pontuação própria.

Apresentado para referência. Nunca afeta a pontuação.

SpamAssassin spam.spamassassin

O filtro clássico baseado em regras, que continua a ser o motor por detrás da maioria das ferramentas de teste de correio eletrónico. Todas as regras acionadas são apresentadas com o respetivo peso.

Se falhar: Leia as regras acionadas em vez do total. A maioria é fácil de resolver quando consegue ver quais são.

Desconta até 3 em 10 na pontuação clássica.

Google — Why Gmail marks messages as spam

Apache SpamAssassin — rule documentation

Conteúdo

A própria mensagem: a sua estrutura, as suas ligações, as suas imagens, os elementos que um filtro analisa antes de tomar uma decisão.

Texto alternativo das imagens content.alt_attributes

Se as imagens incluem atributos alt. Os clientes de correio bloqueiam imagens remotas por predefinição, pelo que, durante os primeiros segundos, o texto alternativo é a sua mensagem.

Se falhar: Escreva texto alternativo que transmita o significado e nunca deixe o elemento visual principal sem um.

Desconta até 4 pontos em 100 na nossa pontuação e até 0.5 em 10 na pontuação clássica.

Google — Email sender guidelines

Script e iframe content.forbidden_tags

Se o HTML contém etiquetas que nenhum cliente de correio executa. Na melhor das hipóteses, são removidas e, na pior, são tratadas como um sinal de evasão.

Se falhar: Remova script, iframe, object e embed. Qualquer elemento interativo deve estar acessível através de uma ligação.

Desconta até 10 pontos em 100 na nossa pontuação e até 1 em 10 na pontuação clássica.

Google — Email sender guidelines

Equilíbrio entre texto e HTML content.html_text_ratio

Quanto da mensagem é marcação em comparação com a quantidade de texto legível. Uma página de marcação em torno de uma única frase é um padrão que os filtros reconhecem.

Se falhar: Escreva uma parte de texto que diga o mesmo que o HTML, em vez de um marcador de posição.

Desconta até 3 pontos em 100 na nossa pontuação e até 0.3 em 10 na pontuação clássica.

RFC 2046 §5.1.4 — Alternative Subtype

Systems should recognize that the content of the various parts are interchangeable.

Google — Why Gmail marks messages as spam

Partes de texto e HTML content.html_version

Se a mensagem inclui uma alternativa em texto simples juntamente com o HTML. Alguns filtros atribuem peso à sua ausência, e todos os leitores de ecrã precisam de uma.

Se falhar: Envie multipart/alternative com uma versão de texto real, não uma parte vazia nem uma linha a indicar que deve ser visualizada num navegador.

Desconta até 5 pontos em 100 na nossa pontuação.

RFC 2046 §5.1.4 — Alternative Subtype

The "multipart/alternative" type is syntactically identical to "multipart/mixed", but the semantics are different. In particular, each of the body parts is an "alternative" version of the same information.

Google — Email sender guidelines

Tamanho do HTML content.html_weight

O tamanho da parte HTML. O Gmail corta uma mensagem acima de aproximadamente 102 KB e oculta o resto atrás de uma ligação, levando consigo o rodapé de cancelamento da subscrição.

Se falhar: Reduza o CSS inline e os blocos de estilos repetidos (a maioria dos modelos cabe num terço do limite depois de remover as regras não utilizadas).

Desconta até 3 pontos em 100 na nossa pontuação e até 0.3 em 10 na pontuação clássica.

Google — Email sender guidelines

Peso das imagens content.images_weight

O tamanho total das imagens que a mensagem carrega. Imagens pesadas tornam uma mensagem lenta num telemóvel, e uma mensagem composta apenas por imagens é um formato que os filtros tratam com desconfiança.

Se falhar: Comprima-as e certifique-se de que a mensagem continua legível com as imagens desativadas.

Desconta até 3 pontos em 100 na nossa pontuação e até 0.3 em 10 na pontuação clássica.

Google — Email sender guidelines

Análise de anexos content.malware

Se os anexos contêm malware conhecido. Em implementações nas quais o analisador está desativado, este resultado indica que a análise não foi executada, em vez de indicar que não foram detetadas ameaças.

Se falhar: Se este alerta for acionado, pare de enviar e descubra o que está na máquina que criou a mensagem.

Desconta até 60 pontos em 100 na nossa pontuação.

Google — Why Gmail marks messages as spam

ClamAV — how detection works

Pré-cabeçalho content.preheader

A linha de pré-visualização que um cliente apresenta junto ao assunto. Sem uma, apresenta o que surgir primeiro no corpo, o que normalmente é uma ligação para ver a mensagem no navegador.

Se falhar: Adicione um bloco de pré-cabeçalho oculto como primeiro elemento do corpo.

Desconta até 2 pontos em 100 na nossa pontuação.

Google — Email sender guidelines

Linha de assunto content.subject

O comprimento, o uso de maiúsculas e os padrões avaliados pelos filtros. Medimos o assunto descodificado, pelo que uma linha em cirílico ou CJK é avaliada como texto e não como a respetiva codificação.

Se falhar: Mantenha-o abaixo de cerca de 60 caracteres e elimine as maiúsculas excessivas e os pontos de exclamação.

Desconta até 3 pontos em 100 na nossa pontuação.

RFC 5322 §2.2 — Header Fields

Header fields are lines beginning with a field name, followed by a colon (":"), followed by a field body, and terminated by CRLF.

RFC 2047 §2 — Syntax of encoded-words

An 'encoded-word' is defined by the following ABNF grammar.

Google — Why Gmail marks messages as spam

Ligações encurtadas content.url_shortener

Se as ligações passam por um encurtador público. Os encurtadores ocultam o destino, que é exatamente aquilo em que os filtros são treinados para não confiar.

Se falhar: Use ligações para o seu próprio domínio ou utilize o domínio de seguimento da sua plataforma num subdomínio seu.

Desconta até 5 pontos em 100 na nossa pontuação e até 0.5 em 10 na pontuação clássica.

Google — Why Gmail marks messages as spam

Regras para remetentes em massa

Os requisitos publicados pelo Gmail e pelo Yahoo para quem envia grandes volumes. Aplicam-se a envios em massa e são ignorados para mensagens que não pareçam fazer parte de um.

Política DMARC publicada compliance.dmarc_present

Se o domínio From publica algum registo DMARC, independentemente de esta mensagem ter passado a verificação. Gmail e Yahoo exigem-no aos remetentes de correio em massa.

Se falhar: Publique um registo. p=none é suficiente para cumprir o requisito e fornece-lhe relatórios com os quais pode trabalhar.

Desconta até 6 pontos em 100 na nossa pontuação.

RFC 9989 §4.7 — DMARC Policy Record Format

If this tag is not present in an otherwise syntactically valid DMARC Policy Record, then the record is treated as if it included "p=none".

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Yahoo — Sender requirements and recommendations

List-Unsubscribe compliance.list_unsubscribe

Se a mensagem contém um cabeçalho de cancelamento da subscrição que um cliente de correio pode utilizar. Gmail e Yahoo exigem-no aos remetentes em massa, e a sua ausência é usada como critério de filtragem independentemente de tudo o resto. A regra aplica-se a mailings. Uma mensagem que pede ao destinatário para confirmar uma subscrição, ou lhe diz que esta foi concluída, é enviada a uma pessoa sobre algo que acabou de fazer; a CAN-SPAM classifica-a como uma mensagem transacional ou de relacionamento, e nem Gmail nem Yahoo exigem um cabeçalho de cancelamento da subscrição nesse caso. Por isso, esta verificação lê primeiro a mensagem. Uma confirmação de subscrição, uma mensagem de boas-vindas, uma mensagem transacional ou uma notificação sem cabeçalhos de lista não é penalizada, e o relatório indica como a mensagem foi classificada. Uma mensagem de boas-vindas recheada de ofertas é, na prática, a primeira edição do mailing; sem cabeçalhos de lista, a verificação não consegue distinguir as duas, e não penaliza com base numa suposição. Se a mensagem contiver List-Unsubscribe ou List-Id, foi o próprio remetente que a declarou como correio de lista, e a verificação é executada como sempre foi.

Se falhar: Adicione um cabeçalho List-Unsubscribe com um URI HTTPS. Todas as plataformas de envio permitem fazê-lo.

Desconta até 10 pontos em 100 na nossa pontuação e até 1 em 10 na pontuação clássica.

RFC 2369 §3.2 — List-Unsubscribe

The List-Unsubscribe field describes the command (preferably using mail) to directly unsubscribe the user (removing them from the list).

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Yahoo — Sender requirements and recommendations

Cancelamento da subscrição com um clique compliance.one_click_unsubscribe

A forma mais rigorosa: um URI HTTPS, um cabeçalho "List-Unsubscribe-Post" e uma única assinatura DKIM válida que abranja ambos os cabeçalhos. Os três, ou o destinatário não apresenta o botão. Tal como a verificação List-Unsubscribe, aplica-se a mailings, não a uma confirmação ou a uma mensagem de boas-vindas.

Se falhar: A falha habitual está na assinatura: as plataformas assinam "List-Unsubscribe" e esquecem-se de "List-Unsubscribe-Post". Os nomes de ambos os cabeçalhos têm de aparecer na tag h= da mesma assinatura.

Desconta até 8 pontos em 100 na nossa pontuação.

RFC 8058 §4 — Additional Requirements

The List-Unsubscribe and List-Unsubscribe-Post headers MUST be covered by the signature and included in the "h=" tag of a valid DKIM-Signature header field.

RFC 8058 §3.1 — Mail Senders

The List-Unsubscribe header field MUST contain one HTTPS URI.

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Yahoo — Sender requirements and recommendations

Recomendações

Vale a pena seguir estas recomendações e nunca afetam a pontuação. Nada nesta secção pode descontar pontos, o que é uma decisão de produto aplicada pelos testes.

BIMI advisory.bimi

Se o domínio publica um registo BIMI, que coloca um logótipo junto às suas mensagens em alguns clientes. Primeiro, requer uma política DMARC aplicada e um certificado de marca verificada que tem custos.

Se falhar: Vale a pena fazê-lo quando DMARC estiver em quarantine ou reject e o volume justificar o certificado.

Recomendação. Não desconta pontos.

BIMI — draft specification, not yet an RFC

Idade e comprimento da chave DKIM advisory.dkim_key_rotation

O comprimento da chave de assinatura e há quanto tempo está a ser utilizada. As chaves curtas tornam-se mais baratas de atacar offline a cada ano que passa.

Se falhar: Passe para 2048 bits e efetue a rotação segundo um calendário. Publique o novo seletor, passe a assinar com ele e, em seguida, desative o antigo.

Recomendação. Não desconta pontos.

RFC 8301 §3.2 — Key Sizes

Since short RSA keys more easily succumb to off-line attacks, Signers MUST use RSA keys of at least 1024 bits for all keys. Signers SHOULD use RSA keys of at least 2048 bits.

Google — Set up DKIM

Entrega de relatórios DMARC advisory.dmarc_reporting

Se os endereços no seu registo DMARC irão efetivamente receber alguma coisa. Se um endereço de relatório estiver fora do seu próprio domínio, a RFC 9990 exige que esse domínio publique primeiro a sua própria autorização, como um registo TXT em your-domain._report._dmarc.their-domain. Sem esse registo, um destinatário ignora o endereço: sem mensagem de devolução, sem erro, sem relatório. Esta é a configuração habitual, e não uma configuração invulgar, porque o endereço está normalmente num fornecedor de monitorização, ou no seu domínio principal enquanto a política está num subdomínio de envio. A mesma regra abrange os relatórios de falhas, com a RFC 9991 a indicar o mesmo procedimento para a etiqueta ruf. Consultamos os mesmos registos que um destinatário consultaria e mostramos-lhe os nomes que procurámos.

Se falhar: Peça a quem gere o domínio de destino para publicar um registo TXT que contenha v=DMARC1 no nome apresentado no resultado. Normalmente, os fornecedores de monitorização fazem isto por si quando adiciona o domínio à conta que tem com eles, pelo que, se o registo estiver em falta, é provável que o domínio nunca tenha sido adicionado do lado deles. Se, em vez disso, os relatórios forem enviados para o seu próprio domínio, não é necessário fazer nada.

Recomendação. Não desconta pontos.

RFC 9990 §4 — Verifying External Destinations

When a Mail Receiver discovers a DMARC Policy Record in the DNS, and the Organizational Domain at which that record was discovered is not identical to the Organizational Domain of the host part of the authority component of a [RFC3986] specified in the "rua" tag, the following verification steps MUST be taken:

RFC 9990 §4 — Verifying External Destinations

Where the above algorithm fails to confirm that the external reporting was authorized by the Report Consumer, the URI MUST be ignored by the Mail Receiver generating the report.

RFC 9991 §5 — Verifying External Destinations

In case of external destinations, a Mail Receiver who generates failure reports MUST use the Verifying External Destinations procedure described in Section 4 of [RFC9990], substituting the "ruf" tag where the "rua" tag appears in that procedure.

Google — Set up DMARC

DNSSEC advisory.dnssec

Se o domínio está assinado. SPF, DKIM e DMARC residem todos no DNS, pelo que um atacante que consiga falsificar respostas DNS pode falsificar os três.

Se falhar: Ative-o no seu agente de registo. Normalmente, basta ativar uma opção, e o agente de registo trata do resto.

Recomendação. Não desconta pontos.

RFC 4033 §2 — Definitions of Important DNSSEC Terms

Authentication Chain: An alternating sequence of DNS public key (DNSKEY) RRsets and Delegation Signer (DS) RRsets

MTA-STS advisory.mta_sts

Se o domínio publica uma política que indica aos outros servidores que devem recusar entregas não encriptadas para si. Protege o correio que lhe é enviado, em vez do correio que envia.

Se falhar: Publique o registo TXT e o ficheiro de política através de HTTPS (uma tarde de trabalho, e impede um ataque de downgrade).

Recomendação. Não desconta pontos.

RFC 8461 §3 — Policy Discovery

To discover if a recipient domain implements MTA-STS, a sender need only resolve a single TXT record.

Comprimento do caminho de retorno advisory.return_path_length

Qual é o comprimento do endereço de devolução. A RFC 5321 obriga um servidor recetor a aceitar 64 octetos antes do @ e afirma, na mesma secção, que nenhuma implementação deve impor um limite que possa evitar. Ainda assim, muitas impõem um, e uma mensagem que ultrapasse o limite é recusada em MAIL FROM, antes mesmo de o corpo ser enviado. As plataformas de envio deparam-se com isto ao codificarem o destinatário no caminho de retorno para poderem associar as devoluções, o que faz com que o comprimento dependa de quem recebe a mensagem e não de si.

Se falhar: Encurte a parte fixa que a sua plataforma acrescenta no início ou mude o domínio de devolução para um mais curto. Se não puder alterar nenhum dos dois, os endereços em risco são os dos seus subscritores com endereços mais longos, pelo que vale a pena medir o pior caso da sua lista em vez de uma média.

Recomendação. Não desconta pontos.

RFC 5321 §4.5.3.1.1 — Local-part

The maximum total length of a user name or other local-part is 64 octets.

RFC 5321 §4.5.3.1 — Size Limits and Minimums

Every implementation MUST be able to receive objects of at least these sizes.

Haraka — the address parser that enforces the 64-octet local-part, and the flag that relaxes it

Relatórios TLS advisory.tls_rpt

Se o domínio solicita relatórios quando alguém não consegue entregar-lhe mensagens através de TLS. Funciona em conjunto com MTA-STS: a política sem os relatórios impede-o de saber se está a funcionar.

Se falhar: Adicione o registo TXT com um endereço que receba os relatórios diários.

Recomendação. Não desconta pontos.

RFC 8460 §3 — Reporting Policy

A domain publishes a record to its DNS indicating that it wishes to receive reports.