![[PLANTÃO DE EDITAIS – NOVO KV] Setembro Lote 2 – Cabeçalho](https://blog-static.infra.grancursosonline.com.br/wp-content/uploads/2026/09/21184659/plantao-de-editais-novo-kv-setembro-2lote-cabecalho.webp)
Olá, querido(a) aluno(a)!
Quando você envia uma mensagem por um aplicativo de e-mail, vários componentes cooperam para que ela saia do dispositivo, atravesse servidores intermediários e alcance a caixa postal do destinatário. O SMTP organiza a parte responsável pela submissão e pela transferência da mensagem. Por isso, compreender esse protocolo ajuda tanto na configuração de serviços de correio eletrônico quanto na resolução de questões de redes de computadores e segurança da informação.
Neste artigo, você verá o que é SMTP, como funciona SMTP, quais comandos formam uma transação, como escolher as portas adequadas e de que modo autenticação e TLS protegem a conexão. Também serão comparados SMTP, IMAP e POP3, com atenção às diferenças que costumam aparecer em provas.
VISÃO RÁPIDA | SMTP é o protocolo da camada de aplicação usado para submeter e transferir mensagens de correio eletrônico. Em uma frase: ele conduz o e-mail do cliente ao servidor de envio e entre servidores, enquanto IMAP e POP3 permitem ao usuário acessar as mensagens armazenadas na caixa postal.
1. O que é SMTP?
SMTP é a sigla de Simple Mail Transfer Protocol, traduzida como Protocolo de Transferência Simples de Correio. Em conteúdos introdutórios, também aparece a forma abreviada “Protocolo de Correio Simples”; tecnicamente, a palavra Transfer identifica sua função de transferência. O protocolo define uma comunicação textual entre cliente e servidor para transportar mensagens de correio eletrônico. Sua especificação consolidada está na RFC 5321, que descreve comandos, respostas, estados da sessão e regras de entrega.
Na arquitetura TCP/IP, o SMTP pertence à camada de aplicação e utiliza TCP, pois a transferência exige um fluxo confiável e ordenado de bytes. O protocolo trabalha segundo o modelo cliente-servidor: o cliente SMTP inicia a conexão e envia comandos; o servidor SMTP responde com códigos numéricos e recebe ou encaminha a mensagem.
O SMTP é frequentemente classificado como protocolo de envio ou de transferência. Essa síntese é útil, mas precisa de precisão: um servidor receptor também recebe mensagens por SMTP quando outro servidor as transfere. O que o SMTP não faz é oferecer ao usuário o acesso cotidiano à caixa postal, função normalmente exercida por IMAP, POP3 ou uma interface de webmail.
2. Para que serve o protocolo SMTP?
A função do SMTP é conduzir a mensagem pelos pontos de submissão e transferência do sistema de correio eletrônico. Quando o remetente envia um e-mail, o aplicativo atua como Mail User Agent (MUA) e entrega a mensagem a um Mail Submission Agent (MSA). Depois, um Mail Transfer Agent (MTA) encaminha a mensagem ao domínio de destino, geralmente após consultar no DNS os registros MX que indicam os servidores responsáveis pelo recebimento.
No destino, outro MTA aceita a transferência e um Mail Delivery Agent (MDA) conduz a mensagem à caixa postal. Mais tarde, o destinatário acessa o conteúdo por IMAP, POP3 ou webmail. Como o encaminhamento pode passar por filas e tentativas posteriores, a arquitetura é conhecida pelo princípio store-and-forward: o servidor armazena temporariamente a mensagem e tenta encaminhá-la ao próximo salto.
| Etapa | Componente | Papel |
|---|---|---|
| 1 | MUA | O usuário redige a mensagem e solicita o envio. |
| 2 | MSA | Recebe a submissão autenticada, aplica políticas e prepara o encaminhamento. |
| 3 | MTA remetente | Consulta o DNS, seleciona o servidor de destino e inicia a transferência SMTP. |
| 4 | MTA destinatário | Aceita, rejeita ou adia a mensagem conforme endereço, política e disponibilidade. |
| 5 | MDA e caixa postal | O MDA entrega e a caixa postal armazena a mensagem para acesso posterior. |
3. Como funciona SMTP
Após estabelecer uma conexão TCP, o servidor envia uma saudação, normalmente com o código 220. O cliente identifica-se com EHLO quando pretende usar o SMTP estendido, conhecido como ESMTP. A resposta ao EHLO pode anunciar extensões como STARTTLS, AUTH e SIZE. Se o servidor não aceitar ESMTP, o cliente pode recorrer ao comando HELO e às funções básicas.
A transação usa um envelope SMTP separado do conteúdo visível da mensagem. MAIL FROM informa o remetente do envelope, RCPT TO apresenta um destinatário por vez e DATA inicia a transmissão dos cabeçalhos e do corpo. Essa separação explica por que o endereço usado no envelope pode diferir do campo From exibido ao leitor, algo relevante em devoluções, listas de distribuição e mecanismos antispam.
| Comando | Função |
|---|---|
| EHLO | Identifica o cliente e solicita as extensões ESMTP disponíveis. |
| HELO | Identifica o cliente quando são usadas apenas as funções SMTP básicas. |
| MAIL FROM | Inicia a transação e informa o endereço de retorno do envelope. |
| RCPT TO | Indica cada destinatário do envelope; pode aparecer várias vezes. |
| DATA | Inicia cabeçalhos e corpo da mensagem; o servidor responde 354 quando está pronto. |
| RSET | Cancela a transação atual sem necessariamente encerrar a conexão. |
| NOOP | Não executa ação sobre a mensagem e permite verificar a sessão. |
| QUIT | Solicita o encerramento ordenado da sessão SMTP. |
3.1. Exemplo simplificado de sessão SMTP
O diálogo abaixo representa uma transação sem mostrar autenticação nem a negociação TLS. As letras C e S identificam, respectivamente, cliente e servidor:
S: 220 mail.exemplo.net ESMTPC: EHLO cliente.exemplo.orgS: 250-mail.exemplo.netS: 250 SIZE 10485760C: MAIL FROM:<[email protected]>S: 250 2.1.0 Sender acceptedC: RCPT TO:<[email protected]>S: 250 2.1.5 Recipient acceptedC: DATAS: 354 End data with <CRLF>.<CRLF>C: Subject: ExemploC: [linha em branco, corpo e terminador]S: 250 2.0.0 Message queuedC: QUITS: 221 2.0.0 Closing connection
PEGADINHA DE PROVA | O ponto final isolado, precedido e seguido por CRLF, encerra os dados da mensagem. O comando DATA não encerra a sessão; depois da aceitação, outra transação pode começar ou o cliente pode enviar QUIT.
4. Diferença entre SMTP, IMAP e POP3
Os três protocolos participam do serviço de correio eletrônico, mas atuam em momentos diferentes. SMTP cuida da submissão e da transferência. IMAP e POP3 são protocolos de acesso à caixa postal: IMAP mantém a organização no servidor e sincroniza estados; POP3 foi concebido para recuperar mensagens de um maildrop e tradicionalmente favorece o download para o cliente.
| Protocolo | Finalidade | Fluxo típico | Portas | Uso principal |
|---|---|---|---|---|
| SMTP | Submeter e transferir mensagens | Cliente para servidor e servidor para servidor | 25, 587 e 465 | Envio e encaminhamento |
| IMAP | Acessar e manipular mensagens no servidor | Cliente para caixa postal | 143 e 993 | Sincronização de pastas e estados |
| POP3 | Recuperar mensagens da caixa postal | Cliente para maildrop | 110 e 995 | Download das mensagens |
5. Portas SMTP e usos mais comuns
A escolha da porta depende da função executada e do modo de proteção da conexão. Em configuração de clientes, convém seguir os parâmetros publicados pelo provedor, pois a porta precisa ser combinada com autenticação e segurança compatíveis.
| Porta | Serviço | Uso | Observação |
|---|---|---|---|
| 25/TCP | SMTP | Transferência e retransmissão entre MTAs | STARTTLS pode ser oferecido; no transporte entre domínios, seu uso pode ser oportunista. |
| 587/TCP | submission | Submissão de mensagens pelo cliente ao servidor | Normalmente combina SMTP AUTH com STARTTLS e políticas próprias para usuários. |
| 465/TCP | submissions | Submissão com TLS implícito | A negociação TLS começa imediatamente após a conexão TCP. |
| 143/TCP | IMAP | Acesso à caixa postal | Pode usar STARTTLS; 993 é a porta de TLS implícito. |
| 993/TCP | IMAPS | Acesso IMAP com TLS implícito | A conexão já se inicia protegida por TLS. |
| 110/TCP | POP3 | Recuperação de mensagens | Pode usar STARTTLS; 995 é a porta de TLS implícito. |
| 995/TCP | POP3S | Acesso POP3 com TLS implícito | A conexão já se inicia protegida por TLS. |
A porta 2525 aparece em serviços comerciais como alternativa operacional, mas não corresponde à porta padrão de SMTP, submission ou submissions registrada pela IANA. Em prova, associe 25 ao SMTP entre servidores, 587 à submissão e 465 à submissão com TLS implícito.
5.1. Por que a porta 25 costuma ser bloqueada?
Provedores de acesso e plataformas de nuvem frequentemente restringem conexões de saída para a porta 25 a fim de reduzir spam, abuso por máquinas comprometidas e danos à reputação dos endereços IP. O bloqueio costuma atingir usuários e instâncias que tentam entregar mensagens diretamente a servidores externos; ele não transforma a porta 25 em obsoleta, pois a transferência legítima entre MTAs continua dependendo dela.
Para aplicações e clientes, a solução usual é enviar por um servidor de submissão autorizado nas portas 587 ou 465. Um administrador que realmente opere um MTA público precisa verificar a política do provedor, solicitar a liberação quando disponível, configurar DNS e reputação e manter controles contra retransmissão aberta. Trocar aleatoriamente a porta sem considerar a função do serviço tende a ocultar o diagnóstico.
6. O que é autenticação SMTP?
A autenticação SMTP é fornecida pela extensão SMTP AUTH, definida na RFC 4954. Após EHLO, o servidor pode anunciar AUTH e os mecanismos aceitos. O cliente usa o comando AUTH para demonstrar sua identidade antes de submeter mensagens. Essa etapa é especialmente apropriada no serviço de submissão, pois permite aplicar permissões, limites, rastreabilidade e políticas diferentes para cada usuário ou aplicação.
A autenticação não deve expor senhas em uma conexão desprotegida. A própria RFC 4954 exige que o servidor possa impedir mecanismos de senha em texto simples quando STARTTLS ou outra camada contra espionagem não estiver ativa. Em serviços modernos, podem ser exigidos senha de aplicativo, token OAuth 2.0 ou mecanismo SASL específico. Esses requisitos dependem do provedor e não alteram a função básica do SMTP.
ATENÇÃO | SMTP AUTH autentica o cliente perante o servidor de submissão. SPF, DKIM e DMARC cumprem papéis distintos na validação do domínio, na assinatura da mensagem e na política de tratamento. Também não se deve confundir autenticação com criptografia do conteúdo de ponta a ponta.
7. SSL, TLS e STARTTLS no SMTP
SSL designa a família histórica que antecedeu o TLS e cujas versões antigas não devem ser utilizadas. TLS é o protocolo criptográfico atual para proteger a conexão contra leitura e alteração em trânsito, além de permitir a autenticação do servidor por certificado. STARTTLS é um comando que atualiza uma sessão SMTP inicialmente estabelecida sem TLS para uma sessão protegida por TLS.
| Termo | O que representa | Aplicação no SMTP |
|---|---|---|
| SSL | Tecnologia predecessora do TLS | O termo ainda aparece em interfaces, muitas vezes como rótulo genérico; versões SSL antigas são obsoletas. |
| TLS | Protocolo criptográfico | Protege a sessão em trânsito. No serviço de submissão, devem ser usadas versões atuais e validação adequada do certificado. |
| STARTTLS | Comando de atualização da conexão | Começa com SMTP em texto claro, negocia TLS e reinicia o estado do protocolo; o cliente envia EHLO novamente. |
| TLS implícito | TLS desde o início da conexão | É usado na porta 465 para submissions; não há comando STARTTLS antes da proteção. |
No SMTP entre servidores pela porta 25, STARTTLS foi historicamente adotado de forma oportunista: se a proteção não puder ser negociada, a entrega pode prosseguir sem TLS para preservar a interoperabilidade. Mecanismos adicionais, como DANE e MTA-STS, podem impor políticas mais fortes. Em submissão autenticada, a configuração deve exigir proteção, e não aceitar credenciais em texto claro.
8. Códigos, erros comuns e soluções
As respostas SMTP possuem três algarismos. Em termos gerais, 2xx indica sucesso; 3xx solicita informação ou etapa adicional; 4xx representa falha temporária, que admite nova tentativa; 5xx indica falha permanente para aquela solicitação, de modo que repetir sem corrigir a causa tende a produzir o mesmo resultado.
| Sintoma ou código | Causa provável | Verificação ou solução |
|---|---|---|
| Timeout ou conexão recusada | Porta bloqueada, host incorreto, serviço parado ou firewall | Testar DNS e conectividade TCP, conferir host e porta e verificar a política do provedor. |
| 421 | Serviço indisponível ou conexão encerrada | Aguardar e repetir com backoff; consultar disponibilidade, fila e limites do servidor. |
| 450, 451 ou 452 | Falha temporária de caixa postal, processamento ou armazenamento | Preservar a mensagem na fila, repetir depois e verificar recursos e políticas. |
| 535 5.7.8 | Credenciais inválidas ou insuficientes | Revisar usuário, senha, token ou senha de aplicativo e confirmar se SMTP AUTH está habilitado. |
| 550 | Caixa inexistente, acesso negado ou rejeição por política | Validar o endereço e consultar logs, reputação, autenticação do domínio e regra que motivou a rejeição. |
| 552 | Cota ou armazenamento excedido | Reduzir a mensagem quando aplicável ou liberar capacidade na caixa de destino. |
| 553 | Nome de caixa postal não permitido | Corrigir a sintaxe ou o endereço usado no envelope. |
| 554 | Transação recusada | Ler o texto e o código aprimorado, pois a causa pode envolver política, conteúdo, reputação ou segurança. |
| Relay access denied | Servidor não autorizou a retransmissão | Autenticar no MSA correto e verificar domínio, remetente, destinatário e permissões de relay. |
8.1. Quando o SMTP não consegue autenticar o usuário
O diagnóstico deve começar pela resposta completa do servidor. Se houver 535 5.7.8, confira se o nome de usuário exige o endereço de e-mail completo, se a credencial ainda é válida e se o provedor exige senha de aplicativo ou OAuth 2.0. Depois, confirme a combinação entre porta e segurança: 587 normalmente usa STARTTLS, enquanto 465 usa TLS implícito.
Também devem ser verificados o nome do servidor, a validade e o nome do certificado, o relógio do sistema, a disponibilidade da extensão AUTH após EHLO, a habilitação do SMTP autenticado para a conta e as permissões para usar o remetente escolhido. Se a falha continuar, os registros do cliente e do servidor são mais confiáveis que tentativas aleatórias de trocar portas ou desativar TLS.
9. Segurança e boas práticas
- Use as portas e os modos de proteção indicados pelo provedor, exigindo TLS para a submissão autenticada.
- Proteja credenciais em cofre de segredos; aplique menor privilégio, rotação, limites de envio e autenticação multifator quando disponível.
- Implemente SPF, DKIM e DMARC de forma coerente para reduzir falsificação de domínio e melhorar a interpretação das mensagens pelos destinatários.
- Monitore filas, devoluções, códigos aprimorados, reputação, taxas de entrega e tentativas de autenticação.
- Mantenha o servidor fechado para relay não autorizado e restrinja a porta 25 aos componentes que realmente executam transferência entre MTAs.
TLS protege cada conexão entre dois pontos, mas não garante criptografia do conteúdo durante todo o caminho nem enquanto a mensagem está armazenada. Quando a exigência for confidencialidade de ponta a ponta, tecnologias como S/MIME ou OpenPGP devem ser avaliadas separadamente.
10. SMTP em provas de concursos
Em concursos de TI, SMTP costuma ser cobrado em redes de computadores, serviços de Internet e segurança. Memorize sua posição na camada de aplicação, o uso de TCP, a função de submissão e transferência, a sequência EHLO ou HELO, MAIL FROM, RCPT TO, DATA e QUIT, além da associação entre portas e modos de segurança.
Uma questão pode tentar afirmar que SMTP é o protocolo usado pelo destinatário para sincronizar pastas. Essa função pertence ao IMAP. Outra armadilha é dizer que a porta 25 deixou de existir porque provedores bloqueiam conexões de saída. A porta 25 continua padronizada para SMTP e é fundamental na transferência entre servidores; a restrição operacional busca combater abuso e separar a submissão do usuário do relay entre MTAs.
Também merece atenção a diferença entre envelope e cabeçalhos. MAIL FROM e RCPT TO pertencem ao envelope SMTP, enquanto From, To e Subject fazem parte do conteúdo transmitido após DATA. Por fim, lembre-se de que STARTTLS não é uma versão de TLS nem uma porta: trata-se do comando que atualiza a conexão existente para TLS.
Conclusão
O SMTP é a base da submissão e da transferência de mensagens no correio eletrônico. Seu funcionamento combina uma sessão sobre TCP, comandos textuais, códigos de resposta, filas e cooperação entre agentes de usuário, submissão, transferência e entrega. Na configuração prática, o ponto decisivo é associar corretamente a função do serviço à porta, à autenticação e ao modo de TLS.
Para provas, concentre a revisão nas diferenças entre SMTP, IMAP e POP3; nas portas 25, 587 e 465; nos comandos da transação; nas classes de resposta; e na distinção entre STARTTLS e TLS implícito. Esse conjunto resolve grande parte das questões conceituais e ainda oferece uma base segura para diagnosticar falhas reais de envio.
FAQ sobre SMTP
1. O que é SMTP?
É o protocolo da camada de aplicação usado para submeter e transferir mensagens de correio eletrônico sobre TCP.
2. Para que serve o protocolo SMTP?
Serve para enviar a mensagem do cliente ao servidor de submissão e transferi-la entre servidores até o domínio de destino.
3. Qual é a diferença entre SMTP, IMAP e POP3?
SMTP submete e transfere e-mails; IMAP sincroniza a caixa postal no servidor; POP3 recupera mensagens para o cliente.
4. O que é autenticação SMTP?
É a extensão SMTP AUTH, usada para o cliente comprovar sua identidade ao servidor, especialmente durante a submissão.
5. Qual é a diferença entre SSL, TLS e STARTTLS no SMTP?
SSL é o antecessor obsoleto do TLS; TLS protege a conexão; STARTTLS atualiza uma sessão SMTP já iniciada para usar TLS.
6. Por que a porta 25 costuma ser bloqueada?
Para reduzir spam e abuso por dispositivos ou servidores comprometidos. Aplicações normalmente devem usar 587 ou 465 para submissão.
7. O que fazer quando o SMTP não consegue autenticar o usuário?
Confira a resposta do servidor, as credenciais, o método exigido, a habilitação do SMTP AUTH e a combinação entre porta e TLS.
8. O SMTP utiliza TCP ou UDP?
O SMTP utiliza TCP, pois depende de uma comunicação confiável e ordenada para transferir comandos, respostas e mensagens.
Referências
AMAZON WEB SERVICES. Amazon EC2 service quotas: restriction on email sent using port 25. Disponível em: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html. Acesso em: 5 set. 2026.
GOOGLE CLOUD. VPC firewall rules: SMTP port 25 traffic. Disponível em: https://cloud.google.com/firewall/docs/firewalls. Acesso em: 5 set. 2026.
IANA. Service Name and Transport Protocol Port Number Registry. Disponível em: https://www.iana.org/assignments/service-names-port-numbers/. Acesso em: 5 set. 2026.
IETF. RFC 1939: Post Office Protocol, Version 3. 1996. Disponível em: https://www.rfc-editor.org/rfc/rfc1939.html. Acesso em: 5 set. 2026.
IETF. RFC 3207: SMTP Service Extension for Secure SMTP over Transport Layer Security. 2002. Disponível em: https://www.rfc-editor.org/rfc/rfc3207.html. Acesso em: 5 set. 2026.
IETF. RFC 4954: SMTP Service Extension for Authentication. 2007. Disponível em: https://www.rfc-editor.org/rfc/rfc4954.html. Acesso em: 5 set. 2026.
IETF. RFC 5321: Simple Mail Transfer Protocol. 2008. Disponível em: https://www.rfc-editor.org/rfc/rfc5321.html. Acesso em: 5 set. 2026.
IETF. RFC 5598: Internet Mail Architecture. 2009. Disponível em: https://www.rfc-editor.org/rfc/rfc5598.html. Acesso em: 5 set. 2026.
IETF. RFC 6376: DomainKeys Identified Mail (DKIM) Signatures. 2011. Disponível em: https://www.rfc-editor.org/rfc/rfc6376.html. Acesso em: 5 set. 2026.
IETF. RFC 6409: Message Submission for Mail. 2011. Disponível em: https://www.rfc-editor.org/rfc/rfc6409.html. Acesso em: 5 set. 2026.
IETF. RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email. 2014. Disponível em: https://www.rfc-editor.org/rfc/rfc7208.html. Acesso em: 5 set. 2026.
IETF. RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC). 2015. Disponível em: https://www.rfc-editor.org/rfc/rfc7489.html. Acesso em: 5 set. 2026.
IETF. RFC 7568: Deprecating Secure Sockets Layer Version 3.0. 2015. Disponível em: https://www.rfc-editor.org/rfc/rfc7568.html. Acesso em: 5 set. 2026.
IETF. RFC 8314: Cleartext Considered Obsolete: Use of TLS for Email Submission and Access. 2018. Disponível em: https://www.rfc-editor.org/rfc/rfc8314.html. Acesso em: 5 set. 2026.
IETF. RFC 9051: Internet Message Access Protocol, Version 4rev2. 2021. Disponível em: https://www.rfc-editor.org/rfc/rfc9051.html. Acesso em: 5 set. 2026.
Prof. Jósis Alves
Analista de TI no Supremo Tribunal Federal
Instagram: @josisalvesprof @aprovati
![[PLANTÃO DE EDITAIS – NOVO KV] Setembro Lote 1 – Post](https://blog-static.infra.grancursosonline.com.br/wp-content/uploads/2026/09/21184923/plantao-de-editais-novo-kv-setembro-2lote-post.webp)
