Email van eigen server wordt als spam bestempeld

[CU2morO]

Situatie is als volgt:
Eigen server draait een website voor een subdomein van domein X. Hiervoor moeten er ook emails verstuurd worden wanneer iemand zich heeft aangemeld op de desbetreffende website.

Domein X is gehost bij XS4All en om die alles werkend te krijgen heb ik een DNS A record gemaakt voor het desbetreffende subdomein en een MX record die wijst naar domein Y van mijn server.

Echter wanneer ik (automatische) emails verstuur via de website waarbij ik als afzender [e-mail] opgeef, komt deze bijna bij alle grote email providers (hotmail, GMail) automatisch in de spam folder.

In de headers van een email die op deze manier bij GMail aankomt is het volgende te lezen:

Delivered-To: ##########@gmail.com
Received: by 10.204.97.136 with SMTP id l8cs51821bkn;
Wed, 16 Jun 2010 17:03:17 -0700 (PDT)
Received: by 10.227.156.139 with SMTP id x11mr9736065wbw.104.1276732996346;
Wed, 16 Jun 2010 17:03:16 -0700 (PDT)
Return-Path: <[e-mail]>
Received: from Y.nl (Y.nl [##.##.##.##])
by mx.google.com with ESMTP id h22si21031526wbh.47.2010.06.16.17.03.15;
Wed, 16 Jun 2010 17:03:16 -0700 (PDT)
Received-SPF: neutral (google.com: ##.##.##.## is neither permitted nor denied by best guess record for domain of [e-mail]) client-ip=##.##.##.##;
Authentication-Results: mx.google.com; spf=neutral (google.com: ##.##.##.## is neither permitted nor denied by best guess record for domain of [e-mail]) smtp.mail=[e-mail]
Received: from Y.nl (unverified [127.0.0.1])
by Y.nl (SurgeMail 4.0u4) with ESMTP id 422030-1598122
for <########@gmail.com>; Thu, 17 Jun 2010 02:03:14 +0200
Return-Path: <[e-mail]>

Met deze melding kwam ik snel terecht bij SPF records die aangeven of er via een domein wel of geen mail verzonden mag worden, maar aangezien het domein X (Waar de website achter draait) beheerd wordt door XS4all, kan ik enkel de DNS configuratie wijzigen via hun controlepaneel. Hier kan ik geen SPF records (TXT) aanmaken of wijzigen, maar enkel A en MX records.

Via Google kwam ik dan ook niet verder met kreten als SPF en XS4all, waardoor ik eigenlijk denk dat ik in de verkeerde richting aan het zoeken ben.

[Room42]

Jouw mailserver, levert die de mail direct bij de ontvanger af, of gebruik je de smtp-server van je provider?

Het probleem van de eerste situatie is dat je in een 'publieke IP-range' zit. Daardoor wordt je vaak al gemarkeerd als spam. Als je relayed via de server van je provider heb je dat probleem niet. Bleek voor mijn privé mail server de oplossing.

Overigens ga ik er vanuit dat je server thuis staat vanwege het stuk je 'eigen server'. Maar dat is dus een aanname.

[ Voor 14% gewijzigd door Room42 op 17-06-2010 02:44 ]

[servies]

Room42 schreef op donderdag 17 juni 2010 @ 02:44:
Jouw mailserver, levert die de mail direct bij de ontvanger af, of gebruik je de smtp-server van je provider?

Het probleem van de eerste situatie is dat je in een 'publieke IP-range' zit. Daardoor wordt je vaak al gemarkeerd als spam.

Dat is bij XS4All dus niet het geval, dat is dus 1 van de weinige 'consumenten' providers waar dit wel goed is geregeld, dus geen gesloten poorten, reverse DNS instelbaar, niet standaard op blacklists etc. etc.

[CU2morO]

Nee, nee.

De server staat colocated in een datacentre, ik draai hier op mijn eigen mail server (SurgeMail)
Het IP van die server heeft ook niets met XS4all te maken, alleen het domein (DNS) beheer ligt bij XS4all

[vanaalten]

Als ik het goed zie wordt die e-mail als spam bestempeld omdat Google het nogal vaag vindt dat 'Y' mail stuurt namens 'X'. Kan ik mij wel iets bij indenken. De oplossing daarvoor is inderdaad om met SPF records te werken. Helemaal snappen heb ik die dingen nooit gedaan, maar daar kan je inderdaad in aangeven dat 'Y' namens 'X' mag versturen.

Relayen via XS4ALL gaat je, denk ik, ook niet helpen. Dan gaat XS4ALL mail namens 'X' versturen, zelfde probleem. Wat ik zo snel aan oplossingen zie:
1) leg het probleem bij XS4ALL neer - vraag of er mogelijkheden zijn om SPF records toe te voegen. Daarbij uitleggen waarom het nodig is, en dat de huidige situatie je belemmerd om je website fatsoenlijk te gebruiken.
2) Website (of misschien alleen de DNS voor die site) verhuizen naar een hoster waar je wel SPF records kan toevoegen.

Zelf draai ik een webserver/mailserver thuis, consumenten-ADSL lijn, waarbij de domeinnaam registratie/DNS door TransIP gedaan wordt. Heb zonder problemen SPF records ingevoerd en - ondanks een consumenten-IP adres - nooit problemen met spamfilters.

[arjants]

SPF records zijn inderdaad de oplossing voor je probleem.
Ze zijn echt neit moeilijk in te stellen al kan het altijd makkelijker

[ Voor 13% gewijzigd door arjants op 17-06-2010 13:12 ]