Erros mais comuns

Módulo 8: Mudar de fornecedor e organizar o seu domínio · Tempo de leitura: 13 minutos

Objetivo de aprendizagem: Após esta lição, será capaz de reconhecer os doze erros mais comuns relacionados com o email a partir dos seus sintomas, explicar porque acontecem e resolvê-los.

Conceitos-chave: registo SPF duplicado, demasiadas pesquisas SPF, DMARC demasiado cedo em reject, DKIM não ativado num serviço de envio, redirecionamento para o Gmail, catch-all, visitante como remetente, servidor de saída sem autenticação, nome de servidor mail. sem certificado adequado, caixa de correio cheia, MX esquecido numa mudança, POP3 em vários dispositivos

Como usar esta lição

Cada erro tem a mesma estrutura: o que observa (o sintoma, tal como um cliente o relata), porque acontece e como resolver. Muitas vezes os sintomas parecem semelhantes ("o meu email não chega"), mas a causa é bastante diferente. Por isso, para cada erro indica-se também como confirmar: que prova procurar antes de alterar seja o que for. Não adivinhe, meça primeiro (lição 6.3).

Os números são usados no exercício.

Erros no DNS

Erro 1: dois registos SPF.
Observa: o correio para o Gmail e o Outlook.com passa de repente a cair no spam, desde que associou um novo serviço (Microsoft 365, uma newsletter, um programa de contabilidade). Nas cabeçalhos consta spf=permerror.
Porquê: o serviço disse "adicione este registo SPF", e agora existem dois registos TXT que começam por v=spf1. Segundo a RFC 7208, isso é um erro permanente: o SPF deixa de contar por completo.
Confirme: procure os registos TXT do seu domínio e conte os registos v=spf1.
Solução: junte tudo num único registo (lição 4.2).

Erro 2: mais de dez pesquisas SPF.
Observa: o mesmo, spf=permerror, mas há apenas um registo. Frequentemente após adicionar mais um include.
Porquê: cada include, a, mx, exists e redirect custa uma pesquisa DNS, inclusive dentro dos includes. Acima de dez, o SPF torna-se inválido.
Confirme: faça uma verificação SPF que conte recursivamente (exercício Z4.2).
Solução: remova serviços que já não utiliza, substitua a e mx por ip4/ip6 se forem fixos, ou faça com que um serviço envie através do seu próprio subdomínio de bounce (lição 7.1).

Erro 3: DMARC logo em p=reject.
Observa: desde que foi definido um registo DMARC, as faturas do programa de contabilidade ou o correio do sítio web deixaram de chegar. Os destinatários devolvem 550 5.7.1 com uma referência ao DMARC.
Porquê: nem todos os remetentes estavam identificados. O que não chega através de SPF ou DKIM alinhados é agora rejeitado.
Confirme: o registo DMARC e os relatórios (lição 4.5): que origens estão a falhar?
Solução: voltar a p=none com um endereço de relatório, corrigir todos os remetentes e depois avançar passo a passo para quarantine e reject (lição 4.4). É também a linha de orientação recomendada por este curso.

Erro 4: DKIM não configurado no serviço de envio.
Observa: as newsletters deixam cada vez mais de chegar à caixa de entrada em vários destinatários. Nas cabeçalhos: dkim=pass header.d= o domínio do serviço, dmarc=fail.
Porquê: o serviço assina com o seu próprio domínio, pelo que o DMARC não pode ser validado via DKIM, e o SPF também não está alinhado.
Confirme: cabeçalhos de uma newsletter de teste (exercício Z7.1).
Solução: autentique o seu domínio junto do serviço (DKIM via CNAME, lição 7.1).

Erros com redirecionamento e endereços

Erro 5: redirecionar tudo para o Gmail.
Observa: o correio de alguns remetentes não chega ao endereço Gmail para onde reencaminha o seu correio profissional, ou cai no spam. Por vezes, os remetentes recebem um bounce do Gmail.
Porquê: no redirecionamento, o correio chega ao Gmail proveniente do seu servidor, que não consta no SPF do remetente original. Sem DKIM, ou com um remetente com p=reject, o DMARC falha. Além disso, o spam redirecionado parece ao Gmail spam enviado por si, o que prejudica a sua reputação.
Confirme: o bounce ou as cabeçalhos no Gmail (spf=fail ou softfail com o seu servidor como origem).
Solução: não redirecionar, mas sim adicionar a caixa de correio na aplicação Gmail do telemóvel via IMAP (lições 2.4 e 3.3).

Erro 6: um catch-all.
Observa: muito spam em endereços que nunca existiram (xyz123@example.com), e uma caixa de correio cheia.
Porquê: um catch-all aceita correio para qualquer endereço imaginável. Os spammers testam endereços aleatórios, e todos esses chegam. Se ainda redireciona o catch-all para fora, o erro 5 repete-se em grande escala.
Confirme: veja na caixa de correio para que endereços de destinatário foi o spam.
Solução: desativar o catch-all e criar um alias ou caixa de correio para cada endereço realmente utilizado (lição 3.3).

Erro 7: o endereço do visitante como remetente num formulário.
Observa: as mensagens através do formulário de contacto chegam por vezes sim, por vezes não, sobretudo as de visitantes com endereço num grande fornecedor.
Porquê: o seu sítio web envia "em nome" do domínio do visitante. Se esse domínio tiver p=reject ou p=quarantine, o destinatário rejeita ou filtra o correio (lição 7.3).
Confirme: verifique que From o formulário utiliza.
Solução: endereço próprio no From, visitante no Reply-To.

Erros na configuração

Erro 8: servidor de saída sem autenticação.
Observa: receber funciona, enviar não. Mensagem como "relay access denied", "authentication required" ou 550 5.7.1. No iPhone, frequentemente: os campos do servidor de saída ficaram em branco ("opcional").
Porquê: um servidor de saída só reencaminha correio para quem iniciar sessão. Caso contrário, qualquer pessoa poderia usá-lo como canhão de spam.
Confirme: as definições do servidor de saída no programa de correio.
Solução: ativar a autenticação, com o endereço de email completo e a palavra-passe, porta 587 com STARTTLS ou 465 com SSL/TLS (lições 1.4 e 2.3).

Erro 9: mail.<domínio> como nome de servidor sem certificado adequado.
Observa: uma mensagem sobre um certificado inválido ou "não é possível verificar a identidade do servidor", ou a ligação simplesmente não funciona.
Porquê: o programa verifica se o nome do servidor consta no certificado. mail.example.com pode apontar para o servidor, mas não consta no certificado. Ou o nome ainda aponta para o antigo fornecedor após uma mudança.
Confirme: faça verificar as portas de correio com o nome do servidor (exercícios Z2.1 e Z8.4).
Solução: utilize o nome de servidor indicado pelo fornecedor e nunca clique sem mais em "continuar mesmo assim" (lição 2.1).

Erro 10: uma caixa de correio cheia.
Observa: os remetentes recebem um bounce com 452 4.2.2 ou 552 5.2.2 (mailbox cheia). O próprio utilizador não nota nada, ou apenas que deixa de chegar correio novo.
Porquê: a caixa de correio atingiu a sua quota. Frequentemente devido a anos de anexos, ou a uma pasta Enviados e Lixeira que nunca são esvaziadas.
Confirme: a utilização da caixa de correio no painel ou no webmail.
Solução: limpar, arquivar ou aumentar a quota (lição 3.2).

Erros ao mudar de fornecedor

Erro 11: esquecer o MX numa mudança.
Observa: após mudar o sítio web ou o domínio, deixa de chegar correio, ou este chega a um sítio que ninguém verifica. Ou o contrário: mudou o correio para um novo fornecedor, mas o MX ainda aponta para o antigo.
Porquê: numa mudança de servidores de nomes, toda a zona é transferida. Se os registos MX do fornecedor de correio não constarem na nova zona, o seu correio passa a apontar para o novo servidor web. Ou o MX nunca foi alterado.
Confirme: consulte o MX junto do servidor de nomes com autoridade (exercício Z8.2).
Solução: coloque os registos MX corretos na zona que está realmente ativa e, depois, copie o correio mais uma vez (lição 8.2).

Erro 12: POP3 em vários dispositivos.
Observa: o correio está no portátil mas não no telemóvel, ou o contrário. Após substituir o portátil, anos de correio desaparecem.
Porquê: o POP3 transfere o correio do servidor para um único dispositivo e frequentemente apaga-o aí (lição 1.3).
Confirme: o tipo de conta no programa de correio.
Solução: mudar para IMAP; arraste primeiro o correio que só está localmente para a caixa de correio IMAP.

O que os erros têm em comum

Reveja a lista novamente. Quase todos os erros surgem porque alguém seguiu uma instrução isolada ("adicione este registo", "ative o redirecionamento") sem ver o conjunto. O fio condutor deste curso:

• saiba quem envia correio em nome do seu domínio (inventário, lições 4.2 e 8.1);
• altere uma coisa de cada vez e verifique depois;
• leia a prova: o bounce (lição 6.1), as cabeçalhos (lição 1.5), o relatório DMARC (lição 4.5) e o DNS junto do servidor com autoridade.

Resumo

• Erros de DNS: dois registos SPF, demasiadas pesquisas, DMARC demasiado cedo em reject, DKIM não ativado num serviço de envio.
• Erros de endereço: redirecionamento para o Gmail, catch-all, o endereço do visitante como From.
• Erros de configuração: nenhuma autenticação de saída, um nome de servidor que não consta no certificado, uma caixa de correio cheia.
• Erros de mudança: MX esquecido, POP3 em vários dispositivos.
• Confirme sempre a causa com provas antes de alterar seja o que for.

Quiz

Exercício

Exercício Z8.3: Qual é o erro? Vai receber oito casos curtos, cada um com um sintoma e um fragmento de prova (uma cabeçalho, um bounce, uma resposta DNS ou uma definição). Escolha, para cada caso, o número do erro (1 a 12). O programa verifica com uma chave fixa e, perante uma resposta errada, mostra que prova não teve em conta.

Para saber mais

Os passos descritos nestes artigos aplicam-se aos painéis da WebOké; junto de outros fornecedores o procedimento é semelhante.

• Manual DirectAdmin 18.9: Deixei de receber e-mail
• Manual DirectAdmin 18.10: Não consigo enviar e-mail
• Já não recebo e-mails: como encontrar a causa
• Não consigo enviar e-mail (a receção funciona)
• Reencaminhar o e-mail para outro endereço (reencaminhadores, catch-all não recomendado)
• Curso gratuito de DNS 8.4: Erros comuns