Vom 6. Juli an erhielt unser Mailserver in der Arbeit für alle Mails, deren Mail Exchanger mx*.schlund.de oder mx*.kundenserver.de ist, die Fehlermeldung “421 unable to verify sender domain”. Diese Mailserver gehören alle zu 1&1.
Ein Wenig Suche im Web brachte mich auf diese Hilfseite:
- E-Mails müssen den in RFC 2822 definierten Standards genügen. >> http://www.rfc-editor.org/rfc/rfc2822.txt
- Die E-Mail darf nicht direkt an unsere MX-Server aus Dialup-Netzen heraus zugestellt werden.
- Ein Reverse DNS-Eintrag (FQDN) des einliefernden Servers muss vorhanden sein. >> http://de.wikipedia.org/wiki/Reverse_DNS
- Ein sinnvolles und plausibles HELO/EHLO (Format des Anfangs einer E-Mail im Versandprotokoll) im Sinne von RFC 2821 muss gesendet werden. >> http://www.rfc-editor.org/rfc/rfc2821.txt
- Wir prüfen auf Wunsch des Kunden die >> SPF Records. Die Absenderadressen von weitergeleiteten E-Mails müssen daher mittels >> SRS umgeschrieben werden.
- Der einliefernde Server darf kein Open Proxy sein, das heisst, er muss gegen unberechtigten Zugriff geschützt sein.
- Im Fehlerfall geben wir immer eine aussagekräftige Fehlermeldung im SMTP-Dialog zurück. Bitte verfolgen Sie im Zweifelsfall Ihr Log zurück bis zum ersten Auftreten eines Fehlers.
- Wir prüfen verschiedene etablierte RBLs (Blacklistdatenbanken). Sollte eine davon einen Treffer enthalten, gibt der SMTP-Dialog weitere Auskunft.
Nach meinem Dafürhalten sollte die Domain soweit in Ordnung sein:
desenberg:~# host 217.110.66.114
Name: desenberg.advanced-solutions.de
Address: 217.110.66.114
desenberg:~# host desenberg.advanced-solutions.de
desenberg.advanced-solutions.de A 217.110.66.114
desenberg:~# host -t mx as-gmbh.com
as-gmbh.com MX 0 desenberg.advanced-solutions.de
SPF kommt für die Domain nicht zum Einsatz, und alle anderen Sachen (RFC-Formate, kein offenes Relay, keine Einwahlsadresse,…) sind natürlich auch erfüllt. Ich konnte mir die Ablehnung also nicht erklären.
Nach Frage auf twitter sprang mir @Miss_1and1 (die hat sich inzwischen umbenannt) zur Seite, verriet mir eine Support-eMail-Adresse, an die ich schrieb, und das Problem verschwand (wörtlich! Im Moment des Abschickens der Mail an den Support gingen andere Mails auch raus).
Seit vorgestern ist das Problem wieder da (wenn auch diesmal mit einer leicht anderen Fehlermeldung):
"421 invalid sender domain, possibly misconfigured"
Hat irgendjemand einen Tipp, was an den DNS-Einträgen zu beachten ist, damit 1&1 die für “gültig” hält? Oder spielt 1&1 da nur an seiner Konfiguration rum? Hier stehen inzwischen über 70 Mails an Kunden und Geschäftspartner in 31 verschiedenen Domains in der Warteschlange.

![[*]](http://wazong.de/static/blogpic/2009/07/17/1-1-hilfe.png)



![[*]](http://dentaku.wazong.de/wp-content/themes/wazong3/teaserimages/default.jpg)
![[*]](http://dentaku.wazong.de/wp-content/themes/wazong3/teaserimages/microblog.jpg)
![[*]](http://dentaku.wazong.de/wp-content/themes/wazong3/teaserimages/photoblog.jpg)
![[*]](http://dentaku.wazong.de/wp-content/themes/wazong3/teaserimages/linkdump.jpg)
Tags
#36269: dentaku, Freitag, 17.07.2009 17:13
Das könnte noch dauern, ich habe auf dem Gateway (Postfix) mal lieber
eingestellt.
#36270: Andreas, Freitag, 17.07.2009 17:27
Hi, ich habe das selbe Problem, nur andersrum.
Bei mir kommen einige Mails von Kunden nicht an.
Selbe Meldung..
Bin auch bei 1&1, habe an meiner configuration nix geändert.
Wenn Du was hörst, halte mich bitte auf dem Laufenden.
Gruß
Andreas
#36271: Udo, Freitag, 17.07.2009 17:48
Nur zur Info: Du bist nicht alleine. Bei mir hängen die Emails seit 15.07. 10:23 in der Queue. MX Einträge sind wie bei dir, rDNS ist auch korrekt.
Ein weiterer Server hat keine Probleme, bei 1&1 Emails abzuliefern.
Ich kann keine wirklichen Unterschiede zwischen den beiden Setups feststellen.
Server 1 (funktioniert): Postfix und Bind gefüttert durch ispcp omega
Server 2 (funzt nicht): Postfix und Bind manuell verwaltet.
Die Postfix-Konfigurationen habe ich verglichen und sie unterscheiden sich eigentlich nicht. Problem ist also tatsächlich DNS.
Aber die beiden “dig -t MX domain.tld” unterscheiden sich auch nicht.
#36272: Udo, Freitag, 17.07.2009 17:53
Ach so: meine beiden rDNS sind durch den Provider gesetzt, also nicht selber verwaltet. Haben also die kryptische Form host-xxx-xxx-xxx-xxx.domain1.tld und static.xxx.xxx.xxx.xxx.client.domain2.tld
Macht also auch keinen Unterschied.
#36273: dentaku, Freitag, 17.07.2009 17:57
Ich vermute ja, dass die (wahrscheinlich aus Versehen) irgendeine komplett abwegige Bedingung in ihre Domainverifizierung eingebaut haben (sowas wie z.B. mindest-TTL oder “rDNS muss in der Absendedomain liegen” oder…).
Bleibt zu hoffen, dass sich genug 1&1-Kunden beschweren, damit das zu den Mailserveradmins eskaliert. Sehr wahrscheinlich wissen die noch überhauptnichts von dem Problem, denn bisherige Versuche eines unserer Partnerunternehmen wurden im 1st-Level-Support abgebügelt (“Na da ist die Mail wohl kaputt, schicken Sie uns doch mal die Header…”).
#36274: Heiko, Freitag, 17.07.2009 18:14
Hallo…
hier das selbe Problem. Ein Versand von Mails an 1und1-Server wird mit 421 abgelehnt.
Das kuriose, auf unserem Mailserver laufen einige Domains und das Problem tritt nicht bei allen auf.
Das vereinfacht das Ganze nicht wirklich, was eine Fehlersuche angeht.
#36275: Christian, Freitag, 17.07.2009 18:45
Hallo!
Auch hier das gleiche Problem; scheint allerdings nur Domains zu betreffen, die Exchange mit uns als (legitimen) SmartHost verwenden. Bisher noch keine Lösung gefunden….
#36276: Herbert, Freitag, 17.07.2009 19:19
Das ganze ist sehr ärgerlich und geschäftsschädigend.
Bei uns hängen ca. 100 Aufträge, die unsere Kunden nicht erhalten haben.
Wenn man bei der Hotline anruft wird man gebeten eine Mail an mailsecurity[at]webde.de mit dem Problem zu senden.
Hat jemand von euch schon eine Lösung?
Danke
Herbert
#36278: Udo, Freitag, 17.07.2009 20:54
wie ich gerade sehe, sind meine Emails seit 16:15 bei 1&1 angenommen worden. Sry, wenn’s bei Euch noch nicht klappt.
#36279: Udo, Freitag, 17.07.2009 20:59
Ach so: eine Änderung hatte ich im DNS eingetragen: Als MX habe ich mit geringerer Prio den tatsächlichen rDNS eingetragen. Keine Ahnung, ob das geholfen hat.
#36280: dentaku, Freitag, 17.07.2009 21:37
Hmmm, das ist bei uns ja vorher schon so (siehe Ursprungsartikel). Ich mach mal ein paar Experimente…
#36281: dentaku, Freitag, 17.07.2009 21:45
Test 1: von unserem MX aus an die befreundete Firma Architur senden:
Da tritt der Fehler sofort auf. Aber wir lernen: da die Mail schon im SMTP-Handshake abgelehnt wird, können wir für die weitere Betrachtung solche Feinheiten wie die Received:-Header und die MessageID komplett außer Acht lassen.
#36282: dentaku, Freitag, 17.07.2009 22:02
Der Server heißt desenberg.advanced-solutions.de, also probieren wir diese Domain in der Absendeadresse:
Ok, das funktioniert. Als nächstes mal testen, ob es an dem einliefernden Host liegt…
#36284: dentaku, Freitag, 17.07.2009 22:20
Auf einem Rechner, der mit der Domain garnichts zu tun hat (nämlich auf diesem Webserver, der im Moment für keine Domain als MX eingetragen ist):
Also das erstaunt mich jetzt: 1&1 hat überhaupt nichts dagegen, Mails von advanced-solutions.de auch von nyx.wazong.de anzunehmen, Mails von as-gmbh.com nehmen sie aber auch von dort nicht an. Das widerlegt aber auch die Theorie, die Adresse des einliefernden Mailservers müsse eventuell in der angegebenen Domain liegen…
#36288: Philipp, Samstag, 18.07.2009 10:42
Hallo,
Danke für die Anleitung. Bei mir war der selbe Fehler. Geholfen hat die Installation von SPF nach der Anleitung
http://www.howtoforge.com/postfix_spf
Vielleicht hift es ja auch bei Dir und denen, die diesen Beitrag lesen
#36289: dentaku, Samstag, 18.07.2009 12:04
Das ist interessant. Das Tutorial erklärt doch nur, wie man die SPF-Überprüfung für eingehende Mails in seinen Postfix einbaut (was sicher auch keine schlechte Idee ist). Ich frage mich, wieso das beim Versand weiterhilft?
Oder hast Du gleichzeitig auch die DNS-Einträge für SPF für die Domain eingeführt?
#36292: Philipp, Samstag, 18.07.2009 13:03
Sorry – habe mich zu früh gefreut – auf dem Testsystem hat es danach geklappt auf den Live -Systemen leider nicht …
Liegt es doch am DNS? Ich forsche weiter
#36293: dentaku, Samstag, 18.07.2009 13:08
Ich habe jetzt mal einen einfachen SPF-Eintrag in der Domain eingefügt:
Mal abwarten bis das durchs DNS durchpropagiert ist, dann werde ich sehen ob das irgendeinen Effekt hat.
#36294: Philipp, Samstag, 18.07.2009 15:18
Ich habe es mit einer Beispieldomain jetzt auf einem Live-Server hinbekommen. Der MX-Eintrag des Kunden hatte auf einen CNAME gezeigt, der wiederum auf eine andere virtuelle IP des Servers gezeigt hat. Ich habe den mx-Eintrag jetzt auf den echten Servernamen gesetzt, über den der Kunde verschickt – und mit ein bisschen Geduld geht es, sprich, bis sich das DNS upgedatet hat.
#36302: dentaku, Sonntag, 19.07.2009 09:18
Der 1&1-Support hat sich übrigens gemeldet.
#36303: marcus, Sonntag, 19.07.2009 09:54
Abhilfe:
1. SPF-Record anlegen
2. MX auf A-Record, nicht auf CNAME-Record zeigen lassen
#36304: dentaku, Sonntag, 19.07.2009 10:58
@marcus: soweit waren wir hier in den Kommentaren zusammen auch schon gekommen. Leider hat das “meiner” Domain bisher nicht geholfen. Hoffentlich liegt das jetzt nur noch an langsam aktualisierenden Nameservern (die TTL müsste schon lang abgelaufen sein).
#36310: Christian, Sonntag, 19.07.2009 23:26
Hallo zusammen,
Wir hatten dasselbe Problem. Bei uns lag es wie Marcus bereits sagte ebenfalls am CName des MX-Records. Wir wussten es nur nicht, dass es überhaupt ein CName war, da wir einen externen Antispam-Dienstleister (Trendmicro) nutzen, der uns bei der Einrichtung seinerzeit nur den CNAME für die MX Einstellungen genannt hatte. Nach Update auf den korrekten A-Name funktionierte der Versand aller Queue Mails innerhalb von zwei Minuten wieder wie gewünscht. Vielen Dank für die Lösungsansätze und viel Erfolg mit euren Servern.
#36312: durtro, Montag, 20.07.2009 01:42
Ich hoffe mal, dass es die CNAME-Einträge bei mir waren …
Manchmal übertreibts 1&1 echt n bisschen … diese Hau-Ruck-Aktionen da immer …
#36317: dentaku, Montag, 20.07.2009 12:49
Ein Kollege, der noch eine private Domain bei 1&1 hat, hat jetzt mal eine Beschwerdemail an den Support geschrieben. Vielleicht bekommt der eine definitive Antwort:
#36320: Simon, Montag, 20.07.2009 14:40
Problem wurde bei uns wie folgt behoben:
Der MX zeigte zwar innerhalb unserer Domain auf einen A-Record, dieser war aber beim Mailprovider wiederum ein CNAME. Hier handelte es sich wie bei Christian um den in.mx.trendmicro.eu
Nach Umstellung auf den dortigen A-Record (in.eu.mx.trendmicro-fail-over.akadns.net) dauerts keine zwei Minuten und die Mails an 1und1 können zugestellt werden.
–> SPF musste nicht gesetzt werden!
Ich versteh nicht, wie die grossen Provider immer wieder auf die glorreiche Idee kommen, einfach solche Änderungen ohne irgendwelche RFCs oder Ankündigungen durchzuführen. Antwort von meinem Provider: “ja, die sind halt gross genug, das alle anderen einfach nachbessern müssen”.
Ich mein… CNAMEs sperren? Hallo? Gehts noch?
Viel Glück euch da draussen
#36322: Robert, Montag, 20.07.2009 16:43
Hatten seit letzer Woche das gleiche Problem. Jetzt funktioniert. In unserem Fall war es nicht SPF sondern MX records, die auf CNAME zeigten. Eintraege geaendert und laeuft jetzt.
Gruesse
#36324: dentaku, Montag, 20.07.2009 18:25
Juhuu! Jetzt gingen auch unsere Mails raus. Der Sonderfall war, dass die Domain vor sehr langer Zeit mal tatsächlich bei 1&1 gehostet gewesen war, und dass dort — auf ns5.schlund.de — eine eigene, veraltete Kopie der Zone existierte. In der, oh Wunder, zeigte der MX-Record auf einen CNAME…
#36343: Zahl, Mittwoch, 22.07.2009 18:53
Na hurra!
Gerade beim googlen den Eintrag hier gefunden.
Habe Anfang des Monats zum ersten mal überhaupt einen Mailserver aufgesetzt, und darum jetzt natürlich erst recht angenommen, der Fehler würde auf meiner Seite liegen. Perfektes Timing, sozusagen.
Nunja, MX war natürlich ein CNAME… Hoffentlich läuft jetzt alles.
#36416: Christof, Montag, 27.07.2009 19:31
Was fuer ein Scheiss, ich habe jetzt meine Domains jetzt auch geaendert.
Weiss irgendjemand ob allgemein der MX ein CNAME sein darf oder ob nur 1&1 eine Extrawurst verlangt?
#36418: dentaku, Montag, 27.07.2009 20:19
@Christof: Das ist, hmmm, Auslegungssache. Empfohlen ist es jedenfalls auch außerhalb von 1&1 nicht.
#36428: keyJ, Dienstag, 28.07.2009 03:19
Hallo!
Ich habe heute zum ersten Mal von dem Problem erfahren, weil mein QMail mir ein “failure notice” – Nachricht geschickt hat, mit dem hier diskutierten Fehlercode 421. Ich betreue eine kleine Community-Seite, die ab und zu Rundmails an die Mitglieder verschickt. Einige dieser Mails haben eine Woche in der Queue gehangen und sind jetzt als unzustellbar zurück gekommen.
Wie auch immer, ich wollte mich nur kurz bei den hier Beteiligten für die Fehlersuche und die Lösungsvorschläge bedanken. Ich hab die Mails unter einer anderen Domain rausgeschickt, bei der der MX kein CNAME ist und siehe da: es funktioniert!
Ob die Änderungen auch für die eigentliche Domain greifen, sehe ich erst morgen, wenn die DNS-Einstellungen wirksam geworden sind.
Also: danke nochmals und weiter so!
Viele Grüße
keyJ
#36449: Tom Hutter, Mittwoch, 29.07.2009 15:31
Hey, auch von mir ein Dankeschön
hatte meinen mx auch als CNAME eingetragen und konnte Mails zum Teil nicht zustellen. Jetzt auf A Eintrag geändert und schon klappt es auch mit den Nachbarn
every problem in computer sience can be solved with another layer of
indirection ….
…. but that usually will create another problem.
(David Wheeler)
Gruß
Tom
#36602: Ben, Mittwoch, 05.08.2009 06:32
Danke für den Tipp! Gerade heute bin ich auf das Gleiche Problem gestoßen.
#36784: Dentaku » 1&1 nochmal, Donnerstag, 13.08.2009 16:57
[...] inzwischen die DNS-Anforderungen gut verständlich dokumentiert — das war vor drei Wochen noch nicht so, aber besser spät als [...]
#36865: Jan Schaumann, Montag, 17.08.2009 00:35
Ich habe seit ein paar Tagen das gleiche Problem festgestellt (mx*.kundenserver.de). Vielen Dank fuer dieses Blogposting – es hat mich auf die richtige Faehrte gebracht.
Weiteres rumsuchen ergab dann, dass MX records in der Tat A (or AAAA) records sein sollten, und nicht ein CNAME (siehe auch http://www.exchangepedia.com/blog/2006/12/should-mx-record-point-to-cname-records.html und die daraus verweisenden RFC Referenzen).
Nun ist es bloss seltsam, dass sich bei mir das ganze seit Jahren nicht geaender hat, und nun wirklich ~alle anderen mail server da kein Problem machen.
Nun gut, DNS updated, warten bis das propagiert und dann mal weiterschauen…
#36893: Eq5, Dienstag, 18.08.2009 10:17
Hallo zusammen,
wir haben auch diese Problem und sind 1und1 Kunde. Ich hab mit dem Support von 1und1 geredet. Sie haben am dem 17.07 ihre RFC Richtlinien verschärft. Laut 1und1 ist dies so Standard. Hier mal die Antwort die ich von 1und1 erhalten habe
“Wir haben unsere Mailserver den RFC-Vorgaben angepasst und in diesen heisst es:
“The domain name used as [..] part of the value of a MX resource record must not be an alias. [..] This domain name must have as its value one ore more address records. [..] It can also have other RRs, but never a CNAME RR.”
(Quelle: http://tools.ietf.org/html/rfc2181 )”
Leider ist 1und1 von dieser Änderung nicht abzubringen.
Gruß EQ5
#37217: Michael, Donnerstag, 03.09.2009 17:29
hmm – Schweinerei was 1und1 da macht.
Wenn man den eigenen Exchange Server mit dyndns betreibt dann ist cname eigentlich die einzige Möglichkeit.
Aber selbst wenn ich mit einem smarthost versende dann akzeptiert 1und1 nur die domain des smarthosts und andere domains die über diesen smarthost laufen werden nicht akzeptiert ….komisch komisch
#37218: Michael, Donnerstag, 03.09.2009 19:05
noch vergessen – ich habe versuchsweise den cname auf die IP Adresse geändert aber als Absender den smarthost genommen. Also MX auf Record A – Exchange sendet aber über einen smarthost der reverse DNS kann, kein open relay ist usw….. —-> auch das wurdevom schlund server nicht akzeptiert. Steht irgendwo im RFC dass der sender host gleich mit dem empfangs host sein muss? oder hat 1und1 das falsch konfiguriert?
#37231: dentaku, Freitag, 04.09.2009 09:57
Hmm. Soweit ich weiß wird das nicht überprüft (siehe den Kommentar). Der Einliefernde Server muss einen gültigen FQDN im HELO/EHLO angeben, und die Absendedomain muss für 1&1 als erreichbar gelten (MX-Record blabla, s.o.), Einschränkungen der erlaubten Sendehosts kann man aber mit SPF vornehmen…
#39108: Dentaku » @derdevblogger Einwahlcomputer…, Montag, 23.11.2009 14:07
[...] Einwahlcomputer? Eine der Envelope-Adressen falsch? Oder der Quatsch wie bei 1&1: http://shxz.de/1und1/421/ # Microblog [...]