SPF, DKIM & DMARC para SMTP.com.
O SMTP.com é um relay SMTP e uma API de e-mail — você aponta seu app, CRM ou servidor de e-mail para ele e ele entrega em seu nome, então o seu próprio domínio precisa autorizá-lo. A configuração são três registros DNS mais uma chave do lado da conta: um include SPF legítimo (include:_spf.smtp.com) que você mescla no SPF do domínio raiz, um CNAME de DKIM com domínio personalizado no seletor smtpkey que o SMTP.com também precisa habilitar na sua conta para que o e-mail assine como seu domínio em vez do domínio compartilhado dele, e um registro de política DMARC que você mesmo publica. Deixe os três alinhados e o SMTP.com fará o relay totalmente autenticado como você, com o DKIM alinhado ao seu domínio From para que o DMARC passe em vez de se apoiar no domínio de assinatura compartilhado do SMTP.com.
Por que autenticar o SMTP.com?
Autenticar o domínio pelo qual você faz relay via SMTP.com decide se o seu e-mail chega à caixa de entrada, e para um relay de alto volume o risco é maior do que para um serviço de hospedagem de caixas de correio. Desde fevereiro de 2024, o Gmail e o Yahoo exigem que todo remetente em massa (aproximadamente 5.000+ mensagens por dia) passe em SPF, DKIM e DMARC com alinhamento, e a Microsoft começou a exigir o mesmo para e-mails de alto volume no Outlook.com/Hotmail/Live em 2025 — exatamente os volumes para os quais as pessoas usam o SMTP.com. A pegadinha específica de relay: por padrão, o SMTP.com assina seu e-mail de saída com DKIM usando um dos seus próprios domínios compartilhados (d=smtpsend.com) e trata os bounces no próprio return-path, então nem o SPF nem o DKIM se alinham ao seu domínio From. Isso significa que um domínio SMTP.com não configurado não tem nenhum mecanismo alinhado — o DMARC não pode passar, os destinatários podem exibir uma observação "via smtpsend.com", e a reputação de envio que você está pagando para construir se mistura com a de todos os outros remetentes não autenticados na infraestrutura compartilhada. Habilitar o include SPF e, crucialmente, o DKIM com domínio personalizado é o que torna o e-mail criptograficamente seu, faz o DMARC passar e permite que a reputação se acumule sob o seu próprio domínio.
A realidade do SPF para o SMTP.com
O SMTP.com é um verdadeiro provedor de "include": você adiciona um mecanismo compartilhado, include:_spf.smtp.com, ao único registro SPF TXT do seu domínio raiz, resultando em v=spf1 include:_spf.smtp.com ~all. É um include compartilhado de verdade — todo cliente do SMTP.com usa o mesmo — e é enxuto: o include resolve para um registro plano contendo apenas dois intervalos IPv4 e seu próprio softfail (v=spf1 ip4:192.40.160.0/19 ip4:74.91.80.0/20 ~all), então custa apenas UMA das suas 10 consultas DNS de SPF, não as duas ou três que alguns verificadores com cache reportam. Aqui está a nuance honesta que confunde as pessoas, porém: adicionar esse include autoriza os IPs de envio do SMTP.com, mas não faz, por si só, o DMARC passar. Por padrão, o SMTP.com faz o relay com seu próprio domínio de envelope sender / return-path (ele processa seus bounces), e o SPF é sempre avaliado em relação a esse domínio de envelope — então a verificação passa em relação à infraestrutura do SMTP.com em vez de se alinhar ao seu domínio From. O include continua sendo o passo de SPF correto, documentado e recomendado (ele evita falhas brutas de SPF e é o que a configuração do SMTP.com espera), e é por isso que você deve publicá-lo — mas o mecanismo que de fato carrega o seu DMARC pass é o CNAME de DKIM com domínio personalizado, que assina como d=yourdomain.com. Trate o include como necessário, mas não suficiente: publique-o e depois confie no DKIM para o alinhamento (a única outra rota para um SPF alinhado é providenciar um domínio de return-path/bounce personalizado no seu próprio domínio junto ao SMTP.com, o que a maioria das contas dispensa em favor do DKIM). E mantenha exatamente um registro SPF no domínio — se você também envia pelo Google Workspace, Microsoft 365 ou outra ferramenta, mescle include:_spf.smtp.com nessa única linha v=spf1 em vez de publicar um segundo SPF TXT (dois registros SPF são um PermError).
Passo a passo
- 1
Identifique o domínio pelo qual você faz relay
Faça login no Painel de Controle do SMTP.com e anote o domínio From pelo qual seu app/API envia (o domínio no seu cabeçalho From:, por exemplo yourdomain.com). O SMTP.com faz relay de e-mail para qualquer endereço From que você definir, então a autenticação é feita nesse domínio organizacional — não em um host de propriedade do SMTP.com. É também aqui que ficam as suas credenciais de Sender/relay e as configurações do Reputation Defender.
- 2
Adicione ou mescle o include SPF
No seu provedor de DNS, crie UM registro TXT no domínio raiz (host @ ou em branco) com v=spf1 include:_spf.smtp.com ~all. Se já existir um registro v=spf1 (Google Workspace, Microsoft 365, outro relay), não adicione um segundo — mescle include:_spf.smtp.com nesse único registro junto aos outros mecanismos. Mantenha o softfail ~all que o SMTP.com usa, a menos que você tenha certeza de que todo remetente está listado.
- 3
Ative a assinatura DKIM com domínio personalizado
Por padrão, o SMTP.com assina com seu domínio compartilhado (d=smtpsend.com), que NÃO se alinha. Para ter o e-mail assinado como d=yourdomain.com no seletor smtpkey, a assinatura DKIM com domínio personalizado precisa estar habilitada na sua conta — isso é uma chave do lado da conta, então solicite-a via suporte do SMTP.com ou seu gerente de conta e confirme o seletor/destino exatos que eles atribuírem a você (o par amplamente publicado está abaixo).
- 4
Adicione o CNAME de DKIM
Crie um registro CNAME: host smtpkey._domainkey (ou seja, smtpkey._domainkey.yourdomain.com) apontando para smtpcustomer._domainkey.smtpsend.com. Isso é uma delegação — o SMTP.com guarda a chave privada por trás desse destino compartilhado e assina em seu nome. Mantenha o tipo como CNAME; não o troque para TXT ou A.
- 5
Publique o registro DMARC
O SMTP.com não cria o DMARC para você. Adicione um registro TXT no host _dmarc com v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none é apenas monitoramento, então nada muda na entrega enquanto você confirma que o e-mail do SMTP.com está assinando e alinhando; você o apertará mais tarde.
- 6
Corrija a duplicação de host e o proxy do Cloudflare
Se o seu registrador anexa o domínio automaticamente, insira apenas o rótulo (smtpkey._domainkey, e @ para o SPF) para não acabar com smtpkey._domainkey.yourdomain.com.yourdomain.com. No Cloudflare, defina o CNAME de DKIM como 'DNS only' (nuvem cinza) — um CNAME com proxy de nuvem laranja não resolve para smtpsend.com e a validação do DKIM falha.
- 7
Envie um teste e leia os cabeçalhos
Assim que o DKIM personalizado estiver habilitado e os registros se propagarem (normalmente minutos, até 24–72 horas), faça o relay de um teste pelo SMTP.com para um endereço do Gmail, abra-o e escolha ⋮ → Show original. Você quer DKIM: PASS com d=yourdomain.com e seletor smtpkey (a falha reveladora é d=smtpsend.com, indicando que a assinatura personalizada ainda não está ativa), SPF: PASS e DMARC: PASS.
- 8
Confirme que todos os registros resolvem
Passe seu domínio pela verificação de saúde de domínio da Qualisend para confirmar que o SPF permanece como um único registro dentro do limite de 10 consultas, que o CNAME smtpkey._domainkey resolve para smtpsend.com e que o registro DMARC está presente. Assim que os relatórios agregados começarem a chegar, jogue um deles no analisador de relatórios DMARC para ver o SMTP.com aparecer como uma fonte alinhada e aprovada.
Registros a adicionar
O SMTP.com gera os valores exatos no seu assistente de configuração — estes mostram o formato do que você vai adicionar no seu provedor de DNS.
| Tipo | Host | Valor |
|---|---|---|
| TXT | @ | v=spf1 include:_spf.smtp.com ~allSPF do domínio raiz — mantenha exatamente UM registro SPF; mescle este include se você já tiver uma linha v=spf1. include:_spf.smtp.com resolve de forma plana (dois intervalos ip4 + ~all), então custa 1 consulta DNS. Autoriza os IPs do SMTP.com mas não se alinha por padrão. |
| CNAME | smtpkey._domainkey | smtpcustomer._domainkey.smtpsend.comDKIM com domínio personalizado (o mecanismo alinhado). Ilustrativo — este é o destino compartilhado amplamente documentado, mas confirme o seletor/destino exatos que o SMTP.com atribui à sua conta. O SMTP.com TAMBÉM precisa habilitar a assinatura personalizada do lado da conta, ou o CNAME não faz nada. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comVocê adiciona este você mesmo — o SMTP.com nunca o cria. Um registro DMARC por domínio; comece em p=none e depois aperte para quarantine/reject assim que o DKIM alinhar corretamente. |
Mantenha exatamente um registro TXT de SPF (v=spf1) no seu domínio raiz — combine todos os remetentes nele. Ter dois registros SPF já é, por si só, um erro.
O limite de 10 consultas de DNS
O SPF tem um limite rígido de 10 consultas de DNS — se passar disso, ele retorna um permerror e para de validar em todo lugar. Veja quanto a configuração do SMTP.com consome desse limite.
O SMTP.com usa 1 das suas 10 consultas; os mecanismos ip4: e ip6: são gratuitos.
DKIM
O DKIM é a parte que de fato garante o seu DMARC pass com o SMTP.com, e é o passo que a maioria das pessoas ignora porque o SMTP.com "já está assinando" antes de você fazer qualquer coisa — só que com o domínio errado. Por padrão, o relay assina seu e-mail de saída com DKIM usando um dos seus próprios domínios compartilhados (d=smtpsend.com). Essa assinatura é criptograficamente válida, mas como não é o seu domínio, ela não se alinha, então não faz nada pelo DMARC no yourdomain.com. Para corrigir isso, você habilita o DKIM com domínio personalizado, que são duas ações coordenadas: (1) publicar um CNAME em smtpkey._domainkey.yourdomain.com apontando para smtpcustomer._domainkey.smtpsend.com, e (2) fazer o SMTP.com trocar sua conta para assinar com o seu domínio no seletor smtpkey — essa é uma chave do lado da conta que normalmente é providenciada pelo suporte do SMTP.com ou pelo seu gerente de conta, então abra um chamado e confirme o seletor/destino exatos que eles fornecerem (algumas contas podem receber um par diferente). Como o registro é um CNAME (não uma chave TXT que você cola), o SMTP.com guarda a chave privada por trás desse destino compartilhado e pode rotacioná-la sem que você precise mexer no DNS de novo — o trade-off do modelo de destino compartilhado é que a chave não é exclusiva sua, mas o alinhamento não depende da exclusividade da chave: o que importa é que o valor d= da assinatura seja o seu domínio organizacional, o que acontece assim que a assinatura personalizada estiver ativa. O registro publicado do seu lado é pequeno e estático; o trabalho pesado (a assinatura em si) acontece nos servidores do SMTP.com. Até que TANTO o CNAME resolva QUANTO a assinatura personalizada esteja habilitada, o Show original continuará reportando d=smtpsend.com e o DMARC não terá nenhum mecanismo alinhado.
DMARC
O DMARC é um registro TXT de política separado no seu domínio que o SMTP.com não cria — você o publica no seu provedor de DNS. Adicione um registro TXT em _dmarc.yourdomain.com começando com v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none é apenas monitoramento: não muda nada na entrega, mas diz aos destinatários para enviarem a você relatórios agregados (rua) para que você possa confirmar que o e-mail do SMTP.com está passando no DKIM alinhado ao seu domínio antes de aplicar qualquer restrição. Esse passo de monitoramento importa mais do que o normal com o SMTP.com justamente porque o SPF dele não se alinha por padrão — os relatórios são a forma de você verificar que o CNAME de DKIM personalizado está de fato carregando o alinhamento. Acompanhe-os por uma ou duas semanas, certifique-se de que toda fonte legítima (o SMTP.com mais qualquer outro remetente) está autenticando e, então, aperte a política para p=quarantine e, por fim, p=reject. NÃO vá direto para uma política estrita antes de confirmar que o DKIM assina como d=yourdomain.com — se a assinatura personalizada ainda não estiver habilitada, um registro p=reject fará bounce do seu próprio e-mail de relay. Mantenha exatamente um registro _dmarc para todo o domínio, independentemente de quantos remetentes você usar; nunca adicione um segundo registro DMARC especificamente para o SMTP.com.
Confirme que funcionou de verdade
Não confie apenas no Painel de Controle ou em um cronômetro de propagação — confirme a autenticação em uma mensagem real. Faça o relay de um teste pelo SMTP.com para uma caixa do Gmail (ou Outlook), abra-a e escolha ⋮ → Show original. Você quer DKIM: PASS com d=yourdomain.com e seletor smtpkey — se você vir d=smtpsend.com, a assinatura personalizada ainda não está ativa, ou seja, o CNAME está publicado mas o SMTP.com não trocou a sua conta. Você também quer SPF: PASS (ele vai passar, embora lembre que está alinhado ao envelope do SMTP.com, não ao seu domínio, a menos que você tenha providenciado um return-path personalizado) e DMARC: PASS, que aqui deve ser conquistado pelo alinhamento do DKIM. Prefere um relatório completo? Envie um teste para check-auth@verifier.port25.com e ele responde por e-mail com uma análise linha a linha. Depois, passe o domínio pela verificação de saúde de domínio da Qualisend para confirmar que o seu SPF é um único registro dentro do limite de 10 consultas, que o CNAME smtpkey._domainkey resolve corretamente para smtpsend.com e que o DMARC está presente — e, assim que os relatórios agregados chegarem, jogue um deles no analisador de relatórios DMARC para ver o SMTP.com aparecer como uma fonte alinhada e aprovada.
Pegadinhas comuns
- Configuração de DNS
O include SPF passa mas NÃO se alinha por padrão. Por padrão, o SMTP.com faz o relay com seu próprio domínio de return-path/envelope, então include:_spf.smtp.com autoriza os IPs e passa na verificação bruta de SPF em relação ao SMTP.com — não em relação ao seu domínio From. Adicionar apenas o include não vai lhe dar um DMARC pass; o CNAME de DKIM personalizado dá.
- Quebra a autenticação
De fábrica, o DKIM assina como d=smtpsend.com (domínio compartilhado do SMTP.com), o que valida mas não se alinha. Você precisa habilitar o DKIM com domínio personalizado para que o e-mail assine como d=yourdomain.com no seletor smtpkey — caso contrário o DMARC não tem nenhum mecanismo alinhado.
- Quebra a autenticação
O DKIM personalizado é uma chave do lado da conta, não apenas um registro DNS. Publicar o CNAME smtpkey._domainkey não faz nada até que o SMTP.com habilite a assinatura personalizada para a sua conta — abra um chamado de suporte / peça ao seu gerente de conta e depois confirme o seletor e o destino exatos que eles atribuírem a você.
- Configuração de DNS
O destino do CNAME de DKIM é um host compartilhado (smtpcustomer._domainkey.smtpsend.com) e isso é intencional, não um erro de copiar e colar. O SMTP.com guarda a chave privada por trás dele e a rotaciona para você; o alinhamento continua funcionando porque o d= da assinatura é o seu domínio. Mantenha-o como CNAME — nunca como TXT.
- Configuração de DNS
O proxy do Cloudflare quebra o CNAME de DKIM. Defina smtpkey._domainkey como 'DNS only' (nuvem cinza) — um CNAME com proxy de nuvem laranja não resolve para smtpsend.com e a habilitação do DKIM falha.
- Quebra a autenticação
Mantenha exatamente UM registro SPF TXT no domínio raiz. Se você já envia via Google Workspace, Microsoft 365 ou outro relay, mescle include:_spf.smtp.com nessa única linha v=spf1 — dois registros SPF já são um PermError.
- Configuração de DNS
Duplicação no campo de host: muitos registradores anexam o seu domínio automaticamente, então inserir smtpkey._domainkey.yourdomain.com produz smtpkey._domainkey.yourdomain.com.yourdomain.com. Insira apenas o rótulo (smtpkey._domainkey, e @ para o registro SPF) se o painel adicionar o domínio para você.
- Cobertura
Use o ~all que o include do SMTP.com traz, a menos que você tenha inventariado todo remetente. Um -all prematuro pode causar hard-fail em e-mails legítimos de uma ferramenta que você esqueceu de adicionar à mesma linha SPF.
Monte seu registro SPF
O SMTP.com já vem pré-selecionado abaixo. Adicione as outras plataformas pelas quais você envia e publique o registro único e combinado.
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listSPF do SMTP.com — Perguntas frequentes
Leituras relacionadas
Depois de publicado, confirme se tudo resolve corretamente com o verificação de saúde do domínio e, em seguida, veja quem está enviando em seu nome com o analisador de relatórios DMARC. Explore todas as fontes de envio no gerador. A autenticação, porém, é só metade da entregabilidade — um IP ou domínio de envio que esteja listado ainda te joga no spam por mais limpo que seu SPF esteja, então vale a pena acompanhar as blacklists com o monitoramento de blacklists.
Autenticado — agora mantenha a lista limpa
Passar em SPF, DKIM e DMARC te leva à caixa de entrada; uma lista limpa te mantém lá. Verifique a sua — comece grátis com 100 créditos, sem precisar de cartão.