Saltar para o conteúdo
Portas SMTP em 2026: como escolher entre 587, 465 e por que evitar a 25 para não perder emails no WordPress
Inês Silva
Inês Silva 13 dEurope/Budapest February dEurope/Budapest 2026 · 17 min de leitura

Portas SMTP em 2026: como escolher entre 587, 465 e por que evitar a 25 para não perder emails no WordPress

Se tens um site em produção, assumes que o email “simplesmente funciona”: leads do formulário a cair na caixa de entrada, confirmações de encomenda do WooCommerce a chegar ao cliente, links de recuperação de password entregues em segundos. Quando isso falha, não é só um incómodo técnico – é perda direta de confiança (e de negócio).

O detalhe é que, em muitos sites (e especialmente em WordPress), o envio por defeito tem todas as características que os grandes provedores de inbox (Gmail, Outlook, etc.) associam a spam: falta de autenticação, reputação fraca e infraestruturas partilhadas. A forma moderna de resolver isto é encaminhar os emails do site por um canal profissional e autenticado – e aí entram o SMTP (Simple Mail Transfer Protocol) e, muito concretamente, a porta que escolhes para fazer o submission.

Vou passar pelo essencial: o que é SMTP, porque o wp_mail() costuma falhar, a história (e o estado atual) das portas 25/465/587/2525, a escolha recomendada em 2026 e um guia passo a passo para corrigires o email no WordPress sem perderes tempo às cegas.

Resumo rápido (o que interessa mesmo em 2026)

  • Resposta direta: usa porta 587 com STARTTLS (encriptação). É o padrão moderno e recomendado para envio de email a partir do teu site ou cliente de email.
  • Alternativa sólida: porta 465 com SMTPS (SSL/TLS implícito). Também é comum e segura; há fornecedores que a preferem. Se 587 não funcionar, 465 é a melhor segunda opção.
  • Porta a evitar: não uses a porta 25 para submission (envio a partir do site). É sem encriptação, foi pensada para comunicação servidor-a-servidor e está bloqueada na maioria dos ISPs e hosts modernos como medida anti-spam.
  • O problema real: a função de email por defeito do WordPress (como wp_mail()) é não autenticada e envia a partir do próprio servidor web, que não tem reputação de envio.
  • A solução real: usa um serviço dedicado de SMTP/transactional email (ex.: SendGrid, Brevo, Mailgun) e envia por um servidor autenticado e reputado.
  • “Botão fácil” no WordPress: plugins que fazem encaminhamento sem configuração complexa. Um exemplo é o Site Mailer by Elementor, que contorna o sistema por defeito e encaminha emails transacionais sem exigires configuração de portas ou API keys.
  • Transacional vs marketing: SMTP/transactional é para emails transacionais (recibos, resets, formulários). Para newsletters e envios em massa, usa uma plataforma de email marketing (ESP) para proteger a reputação de envio.

O que é SMTP e por que isto afeta tanto um site WordPress?

Pensa no SMTP (Simple Mail Transfer Protocol) como o “serviço postal” oficial da internet para email. É o conjunto de regras que clientes (Outlook, Apple Mail, etc.) e servidores de email usam para entregar mensagens.

Quando envias um email, não sai diretamente do teu computador para a pessoa do outro lado. O fluxo típico é:

  1. O teu cliente (ou o teu site) envia a mensagem para um servidor de saída (o passo de submission).
  2. Esse servidor encontra o servidor do destinatário e faz o relay (reencaminhamento) para o destino.
  3. O servidor do destinatário guarda o email até a pessoa abrir a inbox.

A “porta SMTP” é, de forma simples, a porta numerada no servidor que está dedicada a esse processo. Escolher a porta certa (e o tipo de TLS) é o que separa um envio profissional de um envio com ar de spam.

O problema clássico do wp_mail() no WordPress

Por defeito, o WordPress nem sequer usa SMTP. Em muitos cenários, o envio passa por wp_mail(), que tenta enviar email a partir do próprio servidor web. Do ponto de vista de entregabilidade, isto é uma receita para falhar – e normalmente falha de formas silenciosas (o email “desaparece”, vai para spam ou é bloqueado).

Os motivos mais comuns:

  1. Não é um servidor de email: o servidor web está otimizado para servir páginas, não para gerir envio e reputação de email.
  2. Não há autenticação: o servidor “diz” que envia em nome do teu domínio, mas não prova nada ao destinatário.
  3. Reputação inexistente: Gmail/Microsoft mantêm reputações para servidores de envio conhecidos. O teu servidor web é um remetente desconhecido e, portanto, suspeito.
  4. IP partilhado e “má vizinhança”: em alojamento partilhado, centenas de sites podem estar no mesmo IP. Se um fizer spam, o IP pode ser bloqueado e arrasta os restantes.

Resultado: para um provedor moderno, isso parece email não confiável. A solução é forçar o WordPress a não depender do envio do servidor web e, em vez disso, usar um fornecedor SMTP/transactional com autenticação e reputação.

Uma breve história das portas SMTP (e por que algumas ficaram obsoletas)

Para perceber por que a escolha em 2026 é tão clara, vale entender por que existem várias portas. A evolução das portas SMTP é, no fundo, a história do combate ao spam e da adoção de encriptação.

Porta 25: a original (e a “autoestrada” do spam)

Em 1982, a porta 25 era o caminho padrão para relay de email entre servidores (MTAs – Mail Transfer Agents). Era aberta, sem autenticação e sem encriptação. Funcionava bem numa internet mais pequena e mais confiável.

O problema é óbvio com a internet moderna: spammers conseguem ligar-se a servidores via porta 25 e despejar volumes enormes de mensagens. Por isso, hoje, quase todos os ISPs, fornecedores de cloud e redes residenciais bloqueiam ligações de saída na porta 25 para reduzir abuso (bots, máquinas infetadas, servidores comprometidos).

Regra prática

Para envio (submission) a partir de um site, não uses a porta 25. Mesmo que o teu host permita, há uma boa probabilidade de a internet do outro lado bloquear ou penalizar.

Porta 465: o primeiro caminho seguro (SMTPS / SSL/TLS implícito)

No fim dos anos 90, a necessidade de encriptação tornou-se inevitável. A porta 465 apareceu para suportar SMTPS (SMTP sobre SSL). Aqui, a ligação começa já dentro de um “túnel” seguro: primeiro acontece o handshake SSL/TLS e só depois os comandos SMTP.

Isto é chamado Implicit SSL/TLS. A porta 465 foi muito adotada, apesar de, durante um período, não ter sido um padrão oficial da IETF e ter sido considerada “deprecated” em favor do STARTTLS.

Na prática, a 465 voltou em força: em 2026 é uma opção segura, aceite e muito popular. Há grandes fornecedores (incluindo o Gmail) que continuam a recomendá-la.

Porta 587: o padrão moderno para submission (STARTTLS / TLS explícito)

Para formalizar um padrão de submission, a IETF designou a porta 587 como a porta oficial para clientes (e sites) enviarem email. Em vez de começar encriptado “logo de entrada”, a 587 usa STARTTLS, também conhecido como Explicit TLS.

O fluxo típico na 587 é:

  1. O site liga-se ao servidor na porta 587 em texto simples.
  2. Envia um EHLO para iniciar a conversa SMTP.
  3. O servidor responde com as capacidades (incluindo STARTTLS).
  4. O site envia o comando STARTTLS para “promover” a ligação.
  5. Cria-se o túnel TLS e só depois seguem credenciais e conteúdo do email.

Em 2026, qualquer servidor que não imponha encriptação na 587 é considerado inseguro. Na prática, a 587 é o padrão recomendado e o primeiro que deves tentar.

Porta 2525: fallback não padrão (para ambientes restritivos)

A porta 2525 não é uma porta SMTP “oficial”. É uma porta alternativa que alguns fornecedores suportam como plano B.

Quando faz sentido? Quando o teu alojamento bloqueia 587 e 465 (não é o comum, mas acontece). Algumas plataformas cloud podem bloquear 587 para reduzir abuso e obrigar ao uso de um relay dedicado que escuta na 2525. Normalmente também usa STARTTLS, tal como a 587.

O veredito para 2026: que porta SMTP usar no teu site

Escolha principal: porta 587 com STARTTLS

É a opção recomendada para submission: padrão moderno, suportado praticamente por todos os fornecedores SMTP, e pensado exatamente para o caso “site/cliente → servidor de envio”.

Escolha secundária: porta 465 com SMTPS

Se a 587 falhar por qualquer motivo, ou se o teu fornecedor indicar explicitamente 465, é uma alternativa excelente e segura, usando SSL/TLS implícito.

Escolha a evitar: porta 25

Hoje, a 25 é essencialmente para relay servidor-a-servidor (o que não é o teu caso quando um WordPress envia emails transacionais). Para submission, tende a ser bloqueada e, além disso, é sem encriptação.

Tabela comparativa rápida

Porta | Protocolo | Segurança                 | Uso comum                     | Recomendada p/ site?
----- | --------- | ------------------------ | ----------------------------- | --------------------
25    | SMTP      | Nenhuma                  | Relay servidor-a-servidor     | NÃO (hosts/ISPs bloqueiam)
465   | SMTPS     | SSL/TLS implícito        | Submission cliente-a-servidor | Sim (segura e comum)
587   | SMTP      | STARTTLS (TLS explícito) | Submission cliente-a-servidor | SIM (padrão recomendado)
2525  | SMTP      | STARTTLS (TLS explícito) | Fallback cliente-a-servidor   | Só se 587/465 estiverem bloqueadas

Como corrigir o email no WordPress (passo a passo)

Saber a porta é metade do trabalho. A outra metade é mudar o canal de envio do WordPress para um fornecedor de email transacional com autenticação e reputação.

Passo 1: escolher um fornecedor dedicado de SMTP (email transacional)

A primeira decisão é parar de usar o servidor web para email e criar conta num serviço de transactional email. Estes serviços existem precisamente para maximizar entregabilidade (e lidar com reputação, filas, retries, etc.).

O que fazem: disponibilizam um servidor de envio reputado para usares via SMTP ou via API.

Fornecedores populares citados com frequência neste contexto:

  • SendGrid (muito usado; bom plano gratuito)
  • Brevo (ex-Sendinblue)
  • Mailgun
  • Postmark (muito conhecido por entregabilidade alta)
  • Amazon SES (potente, mas mais complexo)
  • Google Workspace / Gmail (pode servir para baixo volume, mas não é ideal para negócio por limites de envio)

Para muitos sites pequenos/médios, os planos gratuitos chegam bem para email transacional (não confundir com newsletters).

Passo 2: configurar os registos DNS do domínio (SPF e DKIM)

Este é o passo técnico mais crítico: tens de declarar publicamente (via DNS) que o teu fornecedor tem autorização para enviar email em nome do teu domínio. O fornecedor vai-te dar os registos exatos para copiares/colares no teu DNS (no registo do domínio ou no serviço onde geres DNS).

  • SPF (Sender Policy Framework): é um registo TXT que funciona como “lista de permissões”. Diz aos servidores recetores: “só aceitem emails do meu domínio se vierem destes IPs/servidores (ex.: o meu e o do SendGrid)”. Ajuda a impedir spoofing (alguém falsificar o teu remetente).
  • DKIM (DomainKeys Identified Mail): é um registo TXT que permite uma assinatura digital. O fornecedor assina cada email com uma chave privada; o servidor do destinatário valida com a chave pública publicada no teu DNS. Isso prova que a mensagem não foi adulterada e que o envio é legítimo.

Sem SPF/DKIM, não há milagre

Configurar SPF e DKIM não é “opcional”. Sem estes registos, mesmo um bom fornecedor vai ter dificuldade em escapar ao spam (ou a bloqueios silenciosos).

Passo 3: instalar e configurar um plugin SMTP no WordPress

Depois de escolheres o fornecedor e ajustares DNS, tens de instruir o WordPress a usar esse canal. O caminho mais comum é um plugin que interceta o wp_mail() e reencaminha via fornecedor.

Plugins populares:

  • WP Mail SMTP
  • FluentSMTP
  • Post SMTP

O fluxo de configuração é semelhante em todos. Em termos gerais:

  1. Instala e ativa o plugin SMTP escolhido.
  2. Abre a página de definições do plugin no dashboard do WordPress.
  3. Escolhe o “Mailer” (o fornecedor), por exemplo “SendGrid”.
  4. Introduz as credenciais:
  5. Melhor abordagem (API): muitos plugins recomendam API key. É mais segura e costuma ser mais estável do que username/password SMTP.
  6. Abordagem SMTP (credenciais): se escolheres “Other SMTP”, tens de preencher host/porta/encriptação e credenciais manualmente.
  7. Se estiveres no modo SMTP manual, define:
  8. SMTP Host: o endereço do servidor do fornecedor (ex.: smtp.sendgrid.net, smtp.gmail.com).
  9. Encryption: escolhe TLS (normalmente significa STARTTLS). Se vires “SMTPS”, geralmente equivale a SSL/TLS implícito.
  10. SMTP Port: 587 para TLS/STARTTLS, ou 465 para SMTPS/SSL.
  11. Authentication: ativa (ON).
  12. SMTP Username: fornecido pelo serviço.
  13. SMTP Password: fornecido pelo serviço.
  14. Define “From”:
  15. From Email: tem de ser do teu domínio autenticado.
  16. From Name: nome do site/negócio (consistência ajuda na confiança do utilizador).

Passo 4: enviar um teste e acompanhar os logs

A maioria dos plugins inclui uma área de “Test Email”. Envia um email de teste para um Gmail/Outlook pessoal e valida o comportamento.

  • Se chega à inbox: envio autenticado e funcional.
  • Se vai para spam: revê SPF e DKIM (pode haver atraso de propagação DNS de algumas horas).
  • Se falha o envio: o problema tende a ser porta/encriptação ou credenciais. Confirma host/porta/user/pass. Se 587 + TLS falhar, testa 465 + SSL (ou o inverso).

Quando a “plataforma” resolve por ti: opções integradas no WordPress

Na prática, este processo (fornecedor + DNS + plugin + testes) é pesado para muitos donos de negócio. Tens de coordenar registrador de domínio, serviço SMTP e configurações no WordPress.

Por isso, têm ganho espaço soluções integradas que agregam estes blocos numa experiência mais linear.

Solução 1: email transacional integrado (“zero-config”)

A ideia aqui é simples: se o problema do WordPress é o envio não autenticado, então um plugin que contorne tudo e encaminhe transacionais por um serviço com boa entregabilidade remove quase toda a fricção.

Um exemplo citado frequentemente é o Site Mailer by Elementor, pensado como plugin sem configuração:

  • Como funciona: instalas e ativas.
  • O que faz: reencaminha emails transacionais do site (formulários, WooCommerce, resets de password, etc.) por um serviço autenticado com foco em entregabilidade.
  • Porque é diferente: não tens de abrir conta num fornecedor como SendGrid, não tens de lidar com API keys, não tens de configurar SPF/DKIM e nem tens de escolher portas.

Solução 2: hosting gerido que não te bloqueia portas e boas práticas

Outra parte do puzzle é o ambiente de alojamento. Hosts restritivos podem bloquear portas de saída para reduzir abuso, o que complica a vida quando tentas implementar SMTP corretamente.

A abordagem de hosting gerido é garantir uma base previsível: infraestrutura cloud com foco em performance e configuração compatível com serviços de email, mantendo portas como a 587 disponíveis para integrações via plugin. Um exemplo neste posicionamento é o Elementor Hosting.

Além de SMTP: a distinção que protege a tua reputação (transacional vs marketing)

Depois de corrigires o envio do site, há uma regra que evita dores de cabeça futuras: não uses o teu canal transacional para newsletters e campanhas em massa.

O teu fornecedor SMTP (ou serviço integrado como o Site Mailer) deve ser tratado como canal de email transacional – mensagens esperadas e críticas para o funcionamento do produto/serviço.

Email transacional (usa SMTP/transactional)

  • Resets de password
  • Confirmações de encomenda
  • Mensagens de sucesso de formulários
  • Boas-vindas e emails acionados por ações do utilizador
  • Registos de novos utilizadores
  • Confirmações em eCommerce

São emails 1:1, normalmente acionados por uma ação do utilizador. Têm prioridade máxima e devem chegar sempre à inbox.

Email de marketing (usa uma plataforma ESP)

  • Newsletters semanais
  • Promoções sazonais
  • Anúncios de novos produtos
  • Campanhas para listas grandes (1:many)

Mesmo sendo opt-in, é envio em massa e tende a gerar mais descadastros e queixas de spam. Se disparares uma newsletter de 10.000 contactos pelo canal transacional, arriscas destruir a reputação do domínio – e, com isso, fazer com que emails críticos (como resets) comecem a cair no spam.

Para marketing, usa um ESP (Email Service Provider) dedicado, como Mailchimp ou ConvertKit, que já é desenhado para volume, gestão de unsubscribes e separação de reputação.

Recomendação prática de estratégia de email para 2026

Uma estratégia robusta em 2026 tende a assentar em três camadas:

  1. Base estável: um host de qualidade que não te atrapalha em portas e integrações (por exemplo, Elementor Hosting).
  2. Voz transacional confiável: ou uma solução “zero-config” como o Site Mailer by Elementor, ou um plugin (ex.: WP Mail SMTP) configurado com um fornecedor dedicado (ex.: SendGrid) usando porta 587 como primeira opção.
  3. Canal profissional de marketing: uma plataforma de email marketing (ESP) para newsletters e campanhas, mantendo a reputação transacional protegida.

Conclusão: parar de perder emails é (quase sempre) escolher o canal certo – e a porta certa

Perguntar “que porta SMTP devo usar?” é o primeiro passo. Em 2026, a resposta é objetiva: porta 587 com STARTTLS (e, se necessário, porta 465 com SMTPS).

Mas o ponto principal é mais estrutural: o WordPress por defeito (via wp_mail()) não foi feito para entregabilidade moderna. Trocar para um fornecedor transacional autenticado, configurar SPF/DKIM e validar com testes não é um capricho – é o que garante que os teus clientes recebem recibos, os teus leads chegam e o teu site mantém credibilidade.

FAQ – Perguntas frequentes

1) Qual é a resposta simples? Que porta SMTP devo usar?

Usa porta 587 com STARTTLS. Se não funcionar, a melhor alternativa é porta 465 com SMTPS (SSL/TLS).

2) Porque não devo usar a porta 25?

A porta 25 é a porta SMTP original (1982), sem encriptação, e foi muito abusada para spam. Por isso, é hoje bloqueada pela maioria dos ISPs residenciais e muitos fornecedores de cloud hosting.

3) Qual é a diferença entre 587 (STARTTLS) e 465 (SMTPS)?

As duas são seguras. A 465 usa Implicit TLS (a ligação começa encriptada). A 587 usa Explicit TLS via o comando STARTTLS (liga em texto simples e depois promove para TLS). A 587 é o padrão moderno recomendado, mas ambas funcionam.

4) O que é “email transacional”?

É um email 1:1 acionado por uma ação do utilizador no site: submissões de formulário, resets de password, registos, confirmações de encomenda em eCommerce. Deve ser enviado por um serviço SMTP/transactional dedicado.

5) Em que é que o email transacional difere do email de marketing?

Marketing é envio 1:many (newsletter, campanhas, anúncios). Deve ser feito numa plataforma própria (ESP) para não prejudicar a reputação de envio do teu domínio – o que poderia afetar os emails transacionais.

6) O que são SPF e DKIM e eu preciso mesmo disso?

Sim, precisas. São registos DNS que legitimam o teu envio. SPF lista os servidores autorizados a enviar pelo teu domínio. DKIM é uma assinatura digital que prova integridade e autenticidade. Sem isto, os teus emails parecem spam.

7) O plugin SMTP pede “Host”. O que é isso?

É o endereço do servidor do teu fornecedor SMTP. Exemplos: SendGrid usa smtp.sendgrid.net e o Google usa smtp.gmail.com. O teu fornecedor indica o valor correto.

8) Posso usar a minha conta normal do Gmail para enviar emails do site?

É possível, mas não é recomendado. Implica teres credenciais no dashboard do WordPress (risco de segurança) e existem limites de envio. Num pico de tráfego, o Google pode bloquear temporariamente. Para negócio, é preferível um fornecedor dedicado.

9) Qual é a forma mais fácil de resolver todos os problemas de email no WordPress?

Uma abordagem simples é usar um plugin “zero-config” como o Site Mailer by Elementor, que instala com um clique e trata do encaminhamento e entregabilidade sem exigir configuração de serviço externo, portas ou API keys.

10) Como testo se a configuração SMTP está a funcionar?

Plugins como WP Mail SMTP costumam ter uma área de “Test Email”. Envia um teste do dashboard para um email pessoal; se chegar à inbox, está operacional.

Junte-se à comunidade HelloWP!

Converse conosco sobre WordPress, desenvolvimento web e compartilhe experiências com outros desenvolvedores.

- membros
- online
Participar

Usamos cookies para melhorar a sua experiência. Ao continuar, concorda com a nossa Política de Cookies.