SPF e DMARC em domínio só de recebimento: pare a falsificação

Duas direções, e você configurou uma

Apontar um domínio para cá exige um único registro DNS. Esse registro — o MX — responde exatamente uma pergunta: para onde vai o e-mail endereçado a este domínio? É tudo o que um catch-all precisa, e assim que ele resolve, o domínio funciona. Nesse mesmo momento, porém, ele também está só pela metade configurado, porque um nome de domínio é usado em duas direções, e o registro MX não diz nada sobre a segunda.

A segunda direção é a interessante. Nada no protocolo de e-mail impede um estranho de escrever seu domínio na linha From: de uma mensagem que ele envia da própria máquina dele. Ele não precisa de acesso ao seu DNS, à sua registradora ou à sua caixa de entrada — o endereço numa mensagem é uma afirmação, não uma credencial, e sempre foi assim. O que decide se essa afirmação é acreditada é o que o seu domínio diz sobre quem tem permissão para fazê-la:

O domínio que não diz nada

Um servidor receptor não encontra nem SPF nem política DMARC, e precisa recorrer às próprias heurísticas: reputação, conteúdo, como o domínio se comportou antes. Um domínio novinho em folha, sem histórico e sem política, é praticamente o alvo ideal para falsificar, porque não há nada que contradiga a falsificação, e nada para culpar depois.

O domínio que diz não

O mesmo servidor encontra uma política publicada afirmando que nenhuma máquina, em lugar nenhum, está autorizada a enviar como esse domínio, e que as falhas devem ser rejeitadas. Deixa de ser uma questão de julgamento. A mensagem é recusada na porta, geralmente sem sequer chegar a uma pasta de spam.

Isso não é uma hipótese sobre grandes marcas. Domínios sem envio de e-mail são escolhidos precisamente porque não têm política — um nome que ninguém protege, usado por duas semanas e depois descartado, vale mais para quem envia e-mail indesejado do que um nome que reage.

Por que você pode pular a parte que leva seis meses para todo mundo

Se você já leu algo sobre DMARC antes, deve ter lido que é um projeto longo e cuidadoso. Esse conselho está correto, e não é sobre o seu caso. Ele é escrito para um domínio que envia e-mail, e é longo por um motivo: antes de dizer ao mundo para rejeitar tudo que falhar, você precisa encontrar todo sistema que envia legitimamente em seu nome e fazer cada um deles passar. Numa organização normal, essa lista é mais longa do que qualquer um espera, e ela é descoberta, não conhecida de antemão:

1. Publique uma política que não faz nada. p=none pede aos destinatários que relatem, mas não mudem nada, para que um remetente esquecido não seja cortado pela própria política.
2. Leia relatórios por semanas. O sistema de faturamento, o helpdesk, a ferramenta de newsletter, a plataforma de recrutamento em que alguém se cadastrou em 2019 — cada um aparece como uma fonte que falha, e cada um precisa ser autorizado ou aposentado.
3. Aperte em etapas. Passe para quarantine, espere, observe, e só depois para reject, porque cada passo do aperto pode interromper silenciosamente um e-mail do qual alguém depende.

Cada uma dessas etapas existe para proteger remetentes legítimos da sua própria política. Um domínio apontado para uma caixa de entrada somente de recebimento não tem remetentes legítimos. A lista não é longa, nem difícil de descobrir, nem parcialmente desconhecida — ela está vazia. E uma política que rejeita tudo não consegue quebrar um remetente que não existe.

Há também um argumento de segunda ordem para ir direto ao estado final. Um domínio parado em p=none está publicando uma política que não pede nada, e um servidor receptor trata isso quase da mesma forma que um domínio sem política nenhuma. O registro existe, então parece resolvido — o que é pior do que estar claramente inacabado, porque ninguém volta para terminar.

Os três registros

Os três são registros TXT, e todos entram ao lado do MX que você já tem. Os nomes estão escritos como a maioria dos painéis de DNS espera — relativos à zona, com @ significando o próprio domínio. Se o seu pedir um nome totalmente qualificado, escreva yourdomain.com, _dmarc.yourdomain.com e *._domainkey.yourdomain.com em vez disso.

Se o seu provedor exigir que o valor venha entre aspas, coloque as aspas. Alguns painéis já adicionam as aspas por você e acabam armazenando-as em dobro, o que produz um registro que nenhum verificador consegue ler — se um valor voltar do dig com dois pares de aspas ao redor, foi isso que aconteceu.

Os três valores, prontos para colar. Copie em vez de redigitar: um ponto e vírgula faltando no registro DMARC torna toda a lista de tags impossível de interpretar, e uma política impossível de interpretar é tratada como se não houvesse política alguma.

SPF — no próprio domíniov=spf1 -allCopiar

DMARC — no nome _dmarcv=DMARC1; p=reject; sp=reject; adkim=s; aspf=sCopiar

DKIM — no nome *._domainkeyv=DKIM1; p=Copiar

O que cada palavra desses registros realmente faz

Cinco decisões, e vale a pena saber qual é qual — principalmente para que você reconheça, mais tarde, qual delas relaxar se o domínio algum dia começar a enviar e-mail.

-all

O fim do registro SPF, e a única parte dele que importa aqui. Significa tudo o que não está listado acima é falsificação, e nada está listado acima. A alternativa comum, ~all, significa provavelmente falsificação, mas entregue mesmo assim e marque — que é a resposta certa enquanto você ainda está descobrindo seus próprios remetentes, e a errada quando você tem certeza de que não existe nenhum.

p=reject

O que um servidor receptor deve fazer com um e-mail que alega ser deste domínio e falha. none significa apenas relatar, quarantine significa tratar como suspeito, reject significa recusar na própria conversa SMTP. Reject é a opção que mantém a mensagem completamente fora da vista de um humano.

sp=reject

O mesmo, aplicado a todo subdomínio — incluindo os que não existem. Sem isso, um falsificador usa billing.yourdomain.com, que não tem registros próprios, e não herda nada que o impeça. Essa tag assume por padrão o que p disser, então o registro se comporta de forma idêntica sem ela; ela é escrita explicitamente porque uma política que você não vê ao reler o registro é uma política que você vai presumir que está faltando.

adkim=s, aspf=s

Alinhamento estrito. Exige que o domínio autenticado seja exatamente o domínio da linha From:, e não apenas um parente dele — então uma mensagem de anything.yourdomain.com não pode emprestar uma aprovação que pertencia ao domínio pai. O modo relaxado é o padrão, e o estrito é o que um domínio sem nada para autorizar deveria dizer.

v=DKIM1; p=

Uma chave pública DKIM sem chave nenhuma dentro. A especificação é explícita ao dizer que uma chave vazia significa revogada, então qualquer assinatura que cite qualquer seletor sob este domínio falha na verificação, em vez de ser ignorada. O curinga cobre todo nome de seletor que um falsificador possa inventar, porque é ele quem escolhe o nome.

E o registro que precisa continuar exatamente como está

Nada do que veio acima toca no e-mail de entrada, e nada deveria tocar. O registro MX é o que faz de todo endereço do domínio uma caixa de entrada aqui, e ele permanece inalterado por tudo isso:

Registro MX — sem alteração10 smtp.grabmail.ioCopiar

Os três novos registros e este respondem a perguntas diferentes, então eles não interagem: SPF e DMARC são lidos por servidores decidindo se devem aceitar um e-mail que alega ser seu, e o MX é lido por servidores decidindo para onde entregar um e-mail endereçado a você. Um domínio com os quatro é um domínio que recebe tudo e não dá aval para ninguém.

Conferindo o seu trabalho, em três comandos

DNS não é lugar para supor. Cada um desses registros é publicado para ser lido por estranhos, o que significa que você pode lê-lo exatamente como eles vão ler — sem conta, sem ferramenta, sem site para colar o seu domínio:

$ dig +short TXT      yourdomain.com
dig +short TXT _dmarc.yourdomain.com
dig +short MX       yourdomain.com

Substitua pelo seu próprio domínio. O que você está procurando é isto, tirando os outros registros TXT que você já possa ter nesse nome:

"v=spf1 -all"
"v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s"
10 smtp.grabmail.io.

Quatro formas de isso voltar errado, em ordem aproximada de frequência:

O primeiro comando não responde nada

O registro ainda não se propagou, ou foi adicionado ao nome errado. Registros TXT no próprio domínio vão em @, não em www — um painel que assume por padrão o último nome que você editou costuma ser o culpado.

Voltam dois registros SPF

Um domínio pode ter exatamente um. Dois não é mais estrito do que um — é um erro permanente, e um servidor receptor que encontra dois trata a verificação SPF como quebrada, não como reprovada. Se você já tinha um registro SPF, edite esse em vez de adicionar um segundo.

A linha DMARC volta, mas nada a aplica

Leia o valor com atenção: ele precisa começar com v=DMARC1, e as tags são separadas por ponto e vírgula. Um registro sem a tag de versão, ou um em que um ponto e vírgula virou vírgula, não é uma política mais fraca — é uma política impossível de interpretar, o que conta como nenhuma política.

A resposta do MX mudou

Ela não deveria ter mudado. Se a linha MX agora está ausente, ou mostra apenas um ponto, ou lista um host que não é smtp.grabmail.io, pare e restaure antes de fazer qualquer outra coisa — é desse registro que a sua caixa de entrada depende.

A parte que quase todo mundo deixa passar: subdomínios

DMARC e SPF não dividem o espaço de nomes da mesma forma, e é nessa diferença que um domínio cuidadosamente protegido vaza. sp=reject realmente cobre todo subdomínio, existente ou não. O SPF não funciona nada assim: ele é consultado no nome exato do envelope, e um nome sem registro SPF próprio não tem registro SPF nenhum — ele não herda o do domínio pai.

O DMARC já cobre a segunda linha sozinho, então isso é reforço, não um buraco — mas um registro SPF curinga custa uma linha e fecha a brecha também na camada do SPF, o que importa para os destinatários que verificam SPF e não implementam DMARC:

SPF curinga — mais um registro TXT* TXT v=spf1 -allCopiar

Um curinga de DNS só responde por nomes que não têm registros próprios. Se mail.yourdomain.com já tiver qualquer registro TXT, o curinga não é consultado para esse nome, e você precisaria publicar o registro SPF ali explicitamente. Para um domínio usado só como catch-all, essa situação é rara o bastante para valer a pena saber, mas não para planejar em torno dela.

Relatórios, e se vale a pena tê-los

O DMARC tem um lado de relatórios: adicione uma tag rua e os destinatários participantes te enviam um resumo diário de tudo que alegou ser o seu domínio e o que aconteceu em cada caso. É a única parte do DMARC que te conta algo que você ainda não sabia, e num domínio apontado para cá não custa nada coletar, porque o endereço para onde vai pode ser um endereço no próprio domínio:

DMARC com relatórios — substitua o domíniov=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc@yourdomain.comCopiar

Enviar os relatórios para um endereço no mesmo domínio evita uma parte da especificação que costuma pegar as pessoas de surpresa: se rua aponta para um endereço num domínio diferente, esse outro domínio precisa publicar um registro autorizando o recebimento dos seus relatórios, e até que o faça, a maioria dos remetentes não vai enviar nenhum. Mesmo domínio, nenhum registro desses, nada para dar errado. Vale saber o que chega antes de ativar:

• São XML, compactados em gzip, como anexo. Não é um resumo para ler tomando um café. Domínios pequenos recebem um punhado por dia dos grandes provedores de caixa de entrada, cada um com alguns kilobytes; você vai querer algo para descompactar e ler.
• Vazio é o resultado bom. Um domínio que não envia nada deve gerar relatórios listando só falhas, e uma semana tranquila significa que ninguém está te falsificando no momento — o que é uma informação, e a única forma de obtê-la.
• Eles chegam como e-mail comum. Aqui isso significa uma caixa de entrada comum: legível no navegador e pela API como qualquer outra coisa, e apagados depois de 5 dias junto com tudo o mais.

Se preferir não coletá-los, simplesmente deixe a tag de fora. Um registro DMARC sem rua é um registro perfeitamente válido e protege exatamente da mesma forma; os relatórios são como você fica sabendo o que está acontecendo, não como a política é aplicada.

O que isso não faz

Esses registros têm escopo estreito, e ser claro sobre os limites é a diferença entre um controle em que você confia corretamente e um em que você confia de forma errada. Quatro coisas que eles não cobrem:

Eles não filtram a sua própria caixa de entrada

SPF e DMARC no seu domínio são instruções para servidores que recebem e-mail de você. Eles são lidos pelos sistemas de e-mail de outras pessoas, nunca pelo seu, e não têm efeito nenhum sobre o que aparece no catch-all. O que chega continua sendo o que o mundo mandar para um endereço cuja única credencial é saber que ele existe.

Eles não impedem um nome numa linha From

Uma mensagem trazendo Your Company <attacker@gmail.com> passa em toda verificação, porque o domínio autenticado realmente é do atacante. O DMARC protege o domínio, não o nome de exibição na frente dele — e num celular, o nome de exibição é, com frequência, tudo o que aparece.

Eles não afetam um domínio parecido

Um domínio a um caractere de distância do seu é o domínio de outra pessoa, com os registros de outra pessoa. Nada que você publique alcança esse domínio. Isso é um problema de registradora e de monitoramento, e é genuinamente um problema diferente.

Eles não tornam a caixa de entrada privada

Continua não havendo senha num endereço aqui: quem souber o endereço consegue lê-lo, e esse é o trato que todo o serviço faz. Um domínio seu remove a adivinhação, não a leitura — a versão honesta disso está em o guia sobre domínios catch-all.

Fazendo tudo, do início ao fim

O trabalho inteiro, na ordem que mantém o domínio funcionando em cada etapa:

1. Confirme o MX primeiro. dig +short MX yourdomain.com deve responder smtp.grabmail.io e nada mais. Conserte isso antes de adicionar qualquer coisa, porque o resto não vale nada num domínio que não está recebendo.
2. Adicione o registro SPF em @, a não ser que já exista um — nesse caso, edite-o, já que dois são um erro, não uma configuração mais estrita.
3. Adicione o registro DMARC em _dmarc, direto na política estrita. Não há processo gradual para escalonar aqui, e nada para quebrar ao pular essa etapa.
4. Adicione o registro DKIM curinga em *._domainkey, e o registro SPF curinga se você quiser a camada de subdomínios fechada duas vezes.
5. Releia os quatro com dig, contra um resolvedor público, depois que o TTL tiver tido tempo de expirar.
6. Mande algo para você mesmo. Envie um e-mail para um dos seus próprios endereços no domínio, de qualquer lugar, e abra a caixa de entrada. Se ele chegar, o lado de recebimento sobreviveu à mudança, que é a única regressão que vale a pena verificar.

Pronto, o domínio está terminado: ele aceita todo endereço que você algum dia inventar nele, e não dá aval para absolutamente ninguém. Se você ainda não conectou o domínio, comece pelo guia do catch-all — é um registro e os mesmos cinco minutos — e volte para esta página depois, que é a ordem que não deixa nada pela metade.

Perguntas