Eu tenho dois aplicativos da Web em execução no mesmo servidor. O primeiro é www.nimikri.com e o outro é www.hourjar.com. Ambos os aplicativos compartilham o mesmo endereço IP (75.127.100.175). Meu servidor é através de uma empresa de hospedagem compartilhada.
Eu testei meus aplicativos e, no início, todos os meus e-mails estavam sendo entregues para mim. Então, alguns dias atrás, todos os e-mails de ambos os aplicativos foram despejados na minha caixa de spam (no Gmail e no Google Apps). Até agora, os aplicativos enviaram e-mails para mim e para mais ninguém, então sei que as pessoas não estão sinalizando manualmente como spam.
Eu fiz uma pesquisa inversa de DNS para o meu IP e os resultados que obtive foram estes:
100.127.75.in-addr.arpa NS DNS2.GNAX.NET.
100.127.75.in-addr.arpa NS DNS1.GNAX.NET.
A pesquisa inversa de DNS deve apontar para nimikri.com e hourjar.com, ou eles estão bem configurados do jeito que estão?
Eu notei no cabeçalho do e-mail estas duas linhas:
Received: from nimikri.nimikri.com
From: Hour Jar <[email protected]>
Os diferentes nomes de domínio levariam o Gmail a pensar que se trata de spam?
Aqui está o cabeçalho de um dos e-mails. Por favor, deixe-me saber se isso parece uma bandeira vermelha para spam. Obrigado.
Delivered-To: [email protected]
Received: by 10.231.157.85 with SMTP id a21cs54749ibx;
Sun, 25 Apr 2010 10:03:14 -0700 (PDT)
Received: by 10.151.130.18 with SMTP id h18mr3056714ybn.186.1272214992196;
Sun, 25 Apr 2010 10:03:12 -0700 (PDT)
Return-Path: <[email protected]>
Received: from nimikri.nimikri.com ([75.127.100.175])
by mx.google.com with ESMTP id 28si4358025gxk.44.2010.04.25.10.03.11;
Sun, 25 Apr 2010 10:03:11 -0700 (PDT)
Received-SPF: neutral (google.com: 75.127.100.175 is neither permitted nor denied by best guess record for domain of [email protected]) client-ip=75.127.100.175;
Authentication-Results: mx.google.com; spf=neutral (google.com: 75.127.100.175 is neither permitted nor denied by best guess record for domain of [email protected]) [email protected]
Received: from nimikri.nimikri.com (localhost.localdomain [127.0.0.1])
by nimikri.nimikri.com (8.14.3/8.14.3) with ESMTP id o3PH3A7a029986
for <[email protected]>; Sun, 25 Apr 2010 12:03:11 -0500
Date: Sun, 25 Apr 2010 12:03:10 -0500
From: Hour Jar <[email protected]>
To: [email protected]
Message-ID: <[email protected]>
Subject: [email protected] has invited you to New Event
MIME-Version: 1.0
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
ChrisF, aqui está o corpo da mensagem:
<h1>Hour Jar</h1><h3>New Event</h3><p>To view the event, please go to hourjar.com/event?event.id=2&guest.id=2</p>
Chaitanya, sim, cada mensagem do meu servidor vai para spam.
BillThor, obrigado por responder minha pergunta sobre o rDNS. Vou corrigir os problemas que você apontou e ver se eles ajudam.
Jeff recentemente teve um post em seu blog intitulado Então, você gostaria de enviar alguns e-mails (por meio de código) , que detalha várias técnicas que você deve usar para garantir que seu e-mail seja entregue. Resumindo:
Verifique se o seu sistema não está em uma lista negra: link
Publique registros SPF para o seu nome de domínio, bem como DomainKeys, se puder (isso provavelmente não ajudará na maioria dos casos, mas porque não).
SPF e domainkeys não funcionam para fazer com que suas mensagens pareçam menos com spam - os spammers também as têm com frequência.
As principais coisas a garantir são:
Normalmente, o motivo pelo qual suas mensagens não chegam é que você está em listas negras ou é considerado com uma má reputação. Isso acontece principalmente porque você compartilha um revezamento com um remetente de spam ou é você mesmo.
Se você tem um problema de reputação, mas não consegue se livrar dele, pode ser mais fácil alocar um novo endereço IP (mas certifique-se de que no futuro você não envie spam dele - nem mesmo acidentalmente)
Também vimos problemas nos quais alguns administradores de sistemas equivocados decidem que blocos de IP alocados por certos registros de IP não são "bons o suficiente" para enviar mensagens para eles. Esses indivíduos equivocados geralmente trabalham para grandes corporações americanas e decidem que todos os endereços IP não-ARIN são usados por spammers. Infelizmente, não há como resolver isso, exceto pelo uso de espaço IP registrado no ARIN para que seus retransmissores transmitam mensagens para esses perdedores.
Aviso de isenção de responsabilidade: Eu trabalho para uma empresa de segurança que filtra spam.
Você está perdendo um mapeamento do rDNS. Isso indica que seu servidor de e-mail não está configurado corretamente e inicia você no caminho para ser sinalizado como SPAM. O registro SPF ausente no DNS não ajudará, mas também não atrapalhará muito.
A formatação não padrão do corpo do email também criará problemas. O padrão do Unix é usar o término da linha de alimentação de linha. O padrão requer terminação de alimentação de linha de retorno de carro. Além disso, você precisa garantir que as linhas tenham menos de 80 caracteres de comprimento.
Ser compatível com os padrões ajudará muito a resolver seus problemas. Não desanime, vejo muitas empresas grandes cujas correspondências recebem alta classificação de spam porque não são compatíveis.
Most Spam checking these days is Bayesian, which means that that your message is checked using a fuzzy algorithm that tries to guess if resembles known Spam or Ham (good) messages (mainly by checking the frequency of common spam words and phrases).
It is better to send an individual message to each recipient, rather than using multiple addresses in the BCC field because many spam filters (and many ISP's) automatically flag multiple recipients as spam.
Messages sent from a mail server running on your computer may be flagged as spam because some mail servers will try to contact the source IP of the sending server (which will fail with a local IP address).
It would appear that some of the big mail hosts such as Hotmail will recognize when an identical message is sent to a large number of subscribers at one time so you should stagger the delivery of your messages [...] to send your messages in small batches.
What's a reverse PTR record? It's something your ISP has to configure for you -- a way of verifying that the email you send from a particular IP address actually belongs to the domain it is purportedly from.
What's DomainKeys Identified Mail? With DKIM, you "sign" every email you send with your private key, a key only you could possibly know. And this can be verified by attempting to decrypt the email using the public key stored in your public DNS records.
To be honest, SenderID is a bit of a "nice to have" compared to the above two. But if you've gone this far, you might as well go the distance. SenderID, while a little antiquated and kind of.. Microsoft/Hotmail centric.. doesn't take much additional effort.
SenderID isn't complicated. It's another TXT DNS record at the root of, say, example.com, which contains a specially formatted string documenting all the allowed IP addresses that mail can be expected to come from.
Fontes e informações adicionais: