Um subdomínio de envio de e-mail é um hostname dedicado — algo como
mail.example.com, news.example.com ou e.example.com — que você usa para enviar
e-mails em massa ou de marketing em vez do seu domínio raiz. O objetivo é o isolamento: a
reputação que suas campanhas constroem ou queimam fica no subdomínio, para que um único envio
ruim não arraste para baixo os e-mails corporativos e transacionais que saem do próprio
example.com. Este guia cobre quando um subdomínio de envio vale a pena,
como a divisão de reputação realmente funciona, como autenticá-lo com SPF, DKIM
e DMARC, e a única ressalva que pega todo mundo: um subdomínio novinho começa
sem reputação alguma.
A resposta curta#
Envie tipos diferentes de e-mail a partir de subdomínios diferentes, e mantenha seu domínio
raiz totalmente fora do negócio de envio em massa. Um layout comum é um
subdomínio transacional, um subdomínio de marketing e — se você fizer isso — um subdomínio
separado para prospecção fria. Cada subdomínio carrega sua própria
reputação de remetente, de modo que um pico de reclamações
de spam no fluxo de marketing não acompanhe suas redefinições de senha e
recibos até a pasta de spam. A autenticação é por hostname para SPF e DKIM,
mas pode ser governada de forma centralizada pela tag sp= do DMARC. A contrapartida: qualquer novo
subdomínio precisa ser aquecido antes de
enviar em volume, porque para um provedor de caixa de entrada ele é um desconhecido.
Por que usar um subdomínio de envio de e-mail dedicado#
O argumento a favor de um subdomínio de envio se resume ao raio de impacto. Provedores de caixa de entrada
constroem um perfil de reputação para o domínio no seu endereço "De" visível, e
esse perfil é um dos maiores fatores que determinam se seu e-mail chega à
caixa de entrada ou ao spam. Se tudo o que você envia — recibos transacionais, prospecção de vendas
e uma newsletter para 200.000 destinatários — sai todo de example.com, então esses
fluxos compartilham uma única reputação. A taxa de reclamações da newsletter, os
retornos da campanha fria e o engajamento quase perfeito dos recibos são todos misturados
em uma única pontuação.
Essa mistura funciona bem até o momento em que não funciona mais. No instante em que um fluxo se comporta mal
— uma lista que você não limpou, um disparo de reengajamento para contatos dormentes, uma
campanha comprometida — o dano atinge todas as mensagens daquele domínio. Seus
clientes deixam de receber confirmações de pedido porque sua equipe de marketing enviou para uma
lista desatualizada. Isolar o e-mail arriscado e de alto volume em seu próprio subdomínio contém
o estrago: se news.example.com sofre throttling, example.com e seu
fluxo transacional continuam fluindo.
A proteção funciona nos dois sentidos. O e-mail corporativo do seu domínio raiz — respostas um a um, faturas, contratos — é de baixo volume e alta confiança, e você não quer que um deslize de marketing o coloque em risco. Da mesma forma, você não quer que seu envio em massa seja avaliado com base em um domínio raiz que não tem histórico de envio em massa. Separar os fluxos permite que cada um construa a reputação apropriada a como é de fato usado.
Como a divisão de reputação realmente funciona#
Os provedores avaliam a reputação em mais de um nível: o IP de envio, o
domínio de assinatura/envio e o domínio organizacional mais amplo. Um subdomínio dá a
você uma identidade de domínio de envio distinta, de modo que news.example.com acumula seu próprio
histórico de volume, engajamento, reclamações e acertos em spam-traps, em grande parte separado
de example.com.
"Em grande parte" é a palavra honesta aqui. Um subdomínio não é uma identidade hermeticamente selada. Os provedores ainda associam um subdomínio ao seu domínio pai até certo ponto — um domínio com uma reputação raiz genuinamente tóxica não será totalmente resgatado ao criar um subdomínio novo, e isso é intencional, para impedir que spammers fiquem cunhando infinitamente hostnames de aparência limpa sob um domínio queimado. O que um subdomínio de fato garante de forma confiável é uma superfície de reputação separada para fluxos bem-comportados que, de outra forma, seriam arrastados para baixo por um fluxo mais barulhento sob o mesmo teto. Trate isso como um forte isolamento, não como um firewall.
Como a reputação está ancorada no domínio "De" que seus destinatários veem, o
subdomínio só isola a reputação se você realmente enviar a partir dele — o endereço
From: visível precisa ser algo@news.example.com, e não
algo@example.com com o subdomínio escondido no return path. Se o domínio do From
ainda for o raiz, o domínio raiz continua sendo quem ganha a reputação.
Um layout de subdomínio que escala#
Não existe um esquema único correto, mas o padrão duradouro é separar por tipo de e-mail, porque tipos diferentes têm perfis de risco e engajamento fundamentalmente diferentes:
- Transacional (
t.example.comou similar) — recibos, redefinições de senha, avisos de envio. Disparado por ação do usuário, aberto quase universalmente e objeto de reclamação quase nunca. Esse fluxo merece sua própria reputação imaculada e nunca deve compartilhar um subdomínio com marketing. - Marketing (
news.example.com,mail.example.com) — newsletters, promoções, anúncios de produto. Volume mais alto, engajamento mais baixo e mais variável, reclamações ocasionais. Este é o fluxo que mais vale a pena isolar. - Prospecção fria (um subdomínio separado, ou melhor, um domínio totalmente separado) — a categoria de mais alto risco de longe. O e-mail frio atrai reclamações e acertos em spam-traps, e muitos remetentes deliberadamente o mantêm fora do domínio principal da marca, para que uma reputação de prospecção queimada não possa atingir os e-mails de que o negócio depende.
A regra importante é que transacional e marketing nunca compartilham uma reputação. Se você não fizer mais nada, separe esses dois. Manter cada fluxo em seu próprio subdomínio também torna o diagnóstico muito mais fácil: quando a entrega cai, seu monitoramento aponta para um único hostname, em vez de forçar você a desembaraçar qual de vários fluxos misturados a causou. Isso combina naturalmente com manter cada lista limpa — veja como limpar uma lista de e-mails — já que o isolamento limita o dano, mas é a higiene que o previne.
Autenticando um subdomínio de envio#
Todo subdomínio de envio precisa da pilha completa de autenticação — SPF, DKIM e DMARC — assim como um domínio raiz. A pegadinha que confunde as pessoas é que esses registros se comportam de maneira diferente quando o assunto é herança. Para os conceitos por trás de cada registro, veja o explicativo de SPF, DKIM e DMARC; o que segue é como eles se aplicam especificamente a subdomínios.
SPF não é herdado. Um subdomínio não usa o registro SPF do seu domínio pai. Se
example.com publica um registro SPF e mail.example.com não publica nenhum, o
subdomínio não tem política SPF — o registro do pai não se aplica. Você precisa
publicar um registro TXT SPF separado no subdomínio, listando qualquer serviço que envie
seus e-mails:
mail.example.com. TXT "v=spf1 include:sendgrid.net ~all"
DKIM é publicado sob o subdomínio. Sua plataforma de envio te dá um
seletor, e a chave pública fica nesse seletor sob o hostname de envio. Para
e-mails de mail.example.com, o registro DKIM fica, por exemplo, em:
s1._domainkey.mail.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0G..."
Assine com d=mail.example.com para que o domínio de assinatura corresponda ao domínio do From e
a mensagem permaneça alinhada com o DKIM.
DMARC pode ser herdado — e essa é a parte útil. Quando um receptor verifica
o DMARC de um e-mail de mail.example.com, ele primeiro procura um registro em
_dmarc.mail.example.com. Se nenhum existir, ele recorre ao registro do domínio
organizacional em _dmarc.example.com e aplica a política de subdomínio da
tag sp= se presente, caso contrário a política principal p=. Assim, um único registro no
domínio organizacional pode governar todos os subdomínios de uma vez:
_dmarc.example.com. TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com"
Aqui p=reject cobre o próprio example.com e sp=reject cobre todos os
subdomínios que não têm registro próprio. Se você quiser que um subdomínio siga uma política
diferente — digamos, manter um subdomínio de envio recém-lançado em p=none para
monitoramento enquanto o raiz permanece em reject — publique um registro DMARC dedicado nesse
subdomínio, que sobrepõe o sp= herdado:
_dmarc.mail.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
Mais um ponto sobre alinhamento. O alinhamento relaxado (o padrão do DMARC) trata um
subdomínio e seu domínio pai como o mesmo domínio organizacional, então o DKIM assinado como
d=mail.example.com ainda se alinha com um From: de example.com. Mas como a
razão inteira do subdomínio é enviar como o subdomínio, mantenha o domínio do From,
o d= do DKIM e o return path todos no mesmo hostname — dessa forma
você fica alinhado tanto sob as regras relaxadas quanto sob as estritas, e a reputação recai
exatamente onde você pretende. Se você ainda não está executando o DMARC em modo de imposição,
configure o DMARC primeiro no nível organizacional e deixe o sp=
estender a política aos seus novos subdomínios de envio.
A ressalva do aquecimento que ninguém pula#
Um subdomínio de envio novinho em folha tem zero histórico de envio, o que significa que não tem reputação — e nenhuma reputação, do ponto de vista de um provedor de caixa de entrada, está mais perto de ruim do que de boa. Aponte uma campanha grande para um subdomínio frio no primeiro dia e você convida a throttling, encaminhamento em massa para o lixo ou bloqueios totais, precisamente porque uma enxurrada súbita de um hostname desconhecido é exatamente o que uma operação de spam parece.
Por isso, um novo subdomínio precisa ser aquecido: comece com baixo volume diário para seus destinatários mais engajados e recentemente ativos, e aumente gradualmente ao longo de várias semanas, conforme o subdomínio conquista um histórico positivo. Enviar para pessoas que abrem e clicam ensina os provedores de que o subdomínio é confiável; enviar para uma lista desatualizada ensina o contrário, e em um subdomínio novo não há boa vontade acumulada para absorver o erro. É também por isso que você planeja uma migração de subdomínio antes de precisar dela — transferir todo o seu volume para um novo subdomínio da noite para o dia joga fora a pista de decolagem do aquecimento e pode arruinar a entrega por semanas.
O custo do aquecimento é real, mas é um investimento único, e é exatamente por isso que o isolamento vale a pena: uma vez que cada subdomínio tem sua própria reputação estabelecida, eles falham de forma independente. Se você está avaliando uma mudança para subdomínio como parte de uma correção mais ampla de entrega na caixa de entrada, o guia de entregabilidade de e-mail cobre onde ela se encaixa entre as outras alavancas, e os requisitos de remetente do Google e do Yahoo detalham os limites de autenticação e de taxa de reclamações que todo hostname de envio agora precisa cumprir.
Perguntas frequentes#
Devo enviar e-mail de marketing por um subdomínio ou pelo meu domínio principal?#
Por um subdomínio, em quase todos os casos. Enviar marketing em massa pelo seu domínio
raiz significa que uma campanha ruim — uma lista desatualizada, um pico de reclamações — prejudica a
reputação dos seus e-mails transacionais e corporativos também, já que compartilham o
mesmo domínio "De". Um subdomínio dedicado como news.example.com isola esse
risco, para que um deslize de marketing não mande seus recibos e redefinições de senha para o
spam. O único custo é aquecer o subdomínio antes de enviar em volume.
Os subdomínios herdam SPF e DKIM do domínio raiz?#
Não. SPF e DKIM não são herdados — um subdomínio sem registro SPF não tem política
SPF alguma, independentemente do que o domínio pai publica, e as chaves DKIM precisam ser
publicadas sob o hostname de envio (por exemplo,
selector._domainkey.mail.example.com). O DMARC é a exceção: se um subdomínio
não tem um registro _dmarc próprio, os receptores aplicam a política do domínio
organizacional, usando a tag sp= (política de subdomínio) se ela estiver definida.
O que é a tag sp do DMARC e quando devo usá-la?#
A tag sp= no registro DMARC do seu domínio organizacional define a política para
subdomínios que não publicam seu próprio registro DMARC. Por exemplo,
v=DMARC1; p=reject; sp=reject aplica reject tanto no domínio raiz quanto em todos os
seus subdomínios a partir de um único registro. Use-a para estender uma política rígida a todo
subdomínio de envio automaticamente, e publique um registro _dmarc dedicado em um
subdomínio individual apenas quando precisar que ele siga uma política diferente — como
manter um subdomínio recém-lançado em p=none enquanto ele aquece.
Um novo subdomínio de envio precisa ser aquecido?#
Sim. Um subdomínio novo não tem histórico de envio, e para um provedor de caixa de entrada essa página em branco é tratada com desconfiança, não com confiança. Enviar alto volume por ele imediatamente convida a throttling ou classificação como spam. Aqueça-o começando com baixo volume para seus destinatários mais engajados e aumentando gradualmente ao longo de várias semanas, deixando o subdomínio construir uma reputação positiva antes de assumir toda a sua carga de envio.
Um subdomínio de envio contém o dano de um envio ruim, mas não consegue desfazer o envio ruim em si — isso ainda depende de quem está na sua lista. Passe sua lista pelo verificador de e-mail gratuito para eliminar endereços mortos, erros de digitação e spam-traps antes que eles atinjam qualquer subdomínio, para que a reputação que cada um constrói seja limpa desde a primeira campanha.
