Zendesk ativa o perfil Minimal: um SPF em falha pode bloquear as suas mensagens para o suporte

Escreveu ao suporte de um fornecedor de software e continua à espera de resposta. Desde 23 de setembro de 2026, a sua mensagem pode ter ficado fora da fila de tickets. A Zendesk está a passar para o perfil «Minimal» as contas que não tinham ativado nenhum controlo do remetente. Com este perfil, um SPF em falha sem DKIM válido basta para que um email nunca se torne um ticket.

⚡TL;DR

• Desde 23 de setembro de 2026, as contas Zendesk com a autenticação de remetentes desativada estão a passar gradualmente para o perfil «Minimal».
• Neste perfil, um SPF em falha é pior do que um SPF ausente: sem DKIM válido, o primeiro envia o email para os tickets suspensos e o segundo deixa-o passar com uma sinalização.
• Verifique o SPF e a assinatura DKIM do seu domínio. Se administra o Zendesk, acompanhe a vista «Suspended tickets».

O que muda com o perfil Minimal por defeito

A 18 de junho de 2026, a Zendesk anunciou uma nova regra de segurança para a autenticação de remetentes. O anúncio oficial, atualizado a 28 de setembro de 2026, descreve uma implementação em duas fases.

A fase 1 abrange as contas novas, que já são criadas com o perfil «Minimal» por defeito. A fase 2 visa as contas existentes com a autenticação de remetentes desativada: a Zendesk aplica-lhes «Minimal» como perfil por defeito.

O calendário desta fase 2 apresenta duas datas de fim na mesma página. A tabela indica um início a 23 de setembro de 2026 e um fim a 22 de outubro de 2026. Já o texto fala de uma implementação gradual de 23 de setembro a 16 de dezembro de 2026. Citamos as duas, porque a página oficial não diz qual prevalece. Uma conta ainda desativada hoje pode, portanto, mudar de perfil nas próximas semanas, sem data precisa.

Quem administra a conta mantém o controlo. Pode desativar a autenticação ou escolher um perfil mais rigoroso: «Native traffic» ou «Native and forwarded traffic (ARC)». Há uma regra que não muda: para os emails enviados pelos agentes, a autenticação está sempre ativa e não pode ser desativada.

Suspenso, sinalizado ou aceite: os três desfechos

A documentação da Zendesk sobre a autenticação do email recebido apresenta o «Minimal» como o perfil menos rigoroso. Cruza dois resultados. O SPF verifica se o servidor que envia a mensagem consta da lista publicada pelo domínio do remetente. O DKIM verifica uma assinatura criptográfica acrescentada no envio.

Resultado SPF	Resultado DKIM	Desfecho no Zendesk
Em falha	Ausente ou em falha	Suspenso: vista «Suspended tickets», causa «Email authentication failed»
Não configurado para o domínio remetente	Em falha	Aceite, marcado como «Potential spoofing» (possível usurpação)
Todos os outros casos	Todos os outros casos	Aceite

Uma mensagem suspensa não se torna um ticket. Fica na vista «Suspended tickets» (tickets suspensos), com a causa «Email authentication failed» (falha na autenticação do email). Nenhum agente a verá na sua fila habitual.

A segunda linha merece atenção. Um domínio que não publica nenhum SPF, com uma assinatura DKIM em falha, passa na mesma. O agente vê um aviso, mas recebe o ticket.

Porque é que um SPF em falha é pior do que um SPF ausente

Vejamos a situação do lado do cliente, não do fornecedor. Escreve a partir do seu domínio para o suporte de um software que funciona com o Zendesk. O seu domínio publica um SPF, mas o servidor que entregou a mensagem não consta dele: um novo serviço de envio esquecido, um include retirado por engano. O SPF falha. Se a mensagem não tiver uma assinatura DKIM válida, a Zendesk suspende-a. Fica à espera de resposta; o fornecedor, por seu lado, não tem nenhum ticket para tratar.

A mesma mensagem, vinda de um domínio sem SPF e com o mesmo DKIM em falha, teria chegado com a sinalização «Potential spoofing». Neste perfil, um SPF em falha pesa, portanto, mais do que um SPF ausente.

Não conclua daqui que deve retirar o seu SPF. Sem ele, o seu domínio torna-se mais fácil de usurpar, e o DMARC perde um dos dois mecanismos em que se apoia. A resposta certa é corrigir o SPF e assinar as mensagens com DKIM. No perfil «Minimal», um DKIM válido basta para evitar a suspensão, mesmo quando o SPF falha.

Os reencaminhamentos tornam este ponto ainda mais concreto. Muitos fornecedores publicam um endereço de suporte no seu próprio domínio e depois reencaminham-no para o Zendesk. O servidor que entrega a mensagem ao Zendesk deixa então de ser o seu, e o seu SPF falha muitas vezes sem que o registo tenha qualquer problema. A assinatura DKIM, essa, continua válida enquanto o relay não alterar a mensagem. É ela que leva a mensagem até ao ticket.

O que verificar, primeiro como remetente e depois como administrador do Zendesk

Como remetente, comece pelo SPF. Faça a lista dos serviços que enviam emails com o seu domínio: serviço de correio, CRM, faturação, ferramenta de campanhas de email. Cada um tem de estar autorizado pelo seu registo. O verificador SPF da CaptainDNS lê o registo publicado, expande os include e testa se um determinado endereço IP está autorizado.

Verifique depois se cada fluxo de saída tem uma assinatura DKIM válida, feita com o seu domínio e não apenas com o do fornecedor. A assinatura alinhada com o seu domínio é a que o DMARC tem em conta. Se uma mensagem recente enviada a um suporte ficou sem resposta, faça estas duas verificações antes de a reenviar: um novo envio nas mesmas condições terá o mesmo destino.

Do lado da administração do Zendesk, a indicação do fornecedor cabe numa frase: «Monitor your Suspended tickets view regularly», ou seja, acompanhe regularmente a vista dos tickets suspensos. A Zendesk acrescenta que os problemas de spam se resolvem na origem («Spam issues must be resolved at the source»). Um cliente legítimo que apareça nesta vista com a causa «Email authentication failed» não está necessariamente em falta: o SPF ou o DKIM dele pode precisar de correção, mas um reencaminhamento também pode fazer falhar o SPF. Verifique primeiro os seus próprios reencaminhamentos e, se for ele a ter de corrigir o domínio, avise-o por outro canal.

Se o endereço de suporte for um alias reencaminhado para o Zendesk, veja também o perfil «Native and forwarded traffic (ARC)». É mais rigoroso do que o «Minimal», mas apoia-se no ARC, um mecanismo que conserva os resultados de autenticação de um relay para o seguinte.

Um DKIM válido evita a suspensão mesmo quando o SPF falha. Teste cada seletor usado pelos seus serviços de envio.

O que este artigo não é

Este artigo não detalha as regras que o Gmail impõe aos remetentes: o nosso artigo sobre o endurecimento das regras de envio do Gmail a partir de novembro de 2025 trata-as à parte.

Também não é um guia de resolução de problemas de SPF. Para um erro de sintaxe, um mecanismo mal escrito ou a ultrapassagem das 10 consultas DNS, leia o guia de SPF PermError. As assinaturas em falha têm o seu próprio artigo: DKIM fail: todas as causas e como corrigir.

Por fim, este artigo não compara as ferramentas de apoio ao cliente do mercado. Limita-se ao Zendesk e ao seu perfil «Minimal», com base nas duas páginas oficiais citadas mais abaixo.

FAQ

O meu email para um suporte no Zendesk ficou sem resposta. Foi suspenso?

É possível, se o SPF do seu domínio falhou e a mensagem não tinha DKIM válido. Nesse caso, está na vista «Suspended tickets» do fornecedor, com a causa «Email authentication failed». Verifique o SPF e o DKIM e depois contacte o fornecedor por outro canal.

Porque é que um SPF em falha bloqueia e um SPF ausente passa?

No perfil «Minimal», a Zendesk suspende um email quando o SPF falha e o DKIM está ausente ou em falha. Se o domínio não tiver SPF configurado e o DKIM falhar, o email é aceite com a sinalização «Potential spoofing». Corrija o SPF em vez de o eliminar.

Quando é que a minha conta Zendesk passa para o Minimal?

As contas novas já o usam. Para as contas existentes com a autenticação desativada, a página oficial indica um início a 23 de setembro de 2026, com um fim a 22 de outubro de 2026 na tabela e a 16 de dezembro de 2026 no texto. A Zendesk não diz qual prevalece.

Como evitar a suspensão quando um email é reencaminhado?

Assine as mensagens com um DKIM válido e alinhado com o seu domínio: continua válido se o relay não alterar a mensagem, ao passo que o SPF falha muitas vezes depois de um reencaminhamento. Do lado da administração, o perfil «Native and forwarded traffic (ARC)» tem em conta as mensagens reencaminhadas.

Fontes: anúncio da Zendesk sobre a nova norma de autenticação de remetentes e documentação da Zendesk sobre a autenticação do email recebido (SPF, DKIM, DMARC e ARC).