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.
41 Antworten auf „421 invalid sender domain, possibly misconfigured“
Das könnte noch dauern, ich habe auf dem Gateway (Postfix) mal lieber
eingestellt.
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
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.
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.
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…“).
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.
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….
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
wie ich gerade sehe, sind meine Emails seit 16:15 bei 1&1 angenommen worden. Sry, wenn’s bei Euch noch nicht klappt.
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.
Hmmm, das ist bei uns ja vorher schon so (siehe Ursprungsartikel). Ich mach mal ein paar Experimente…
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.
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…
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…
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
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?
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
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.
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.
Der 1&1-Support hat sich übrigens gemeldet.
Abhilfe:
1. SPF-Record anlegen
2. MX auf A-Record, nicht auf CNAME-Record zeigen lassen
@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).
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.
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 …
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:
😉
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
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
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…
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. 🙂
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?
@Christof: Das ist, hmmm, Auslegungssache. Empfohlen ist es jedenfalls auch außerhalb von 1&1 nicht.
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
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
Danke für den Tipp! Gerade heute bin ich auf das Gleiche Problem gestoßen.
[…] inzwischen die DNS-Anforderungen gut verständlich dokumentiert — das war vor drei Wochen noch nicht so, aber besser spät als […]
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…
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
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
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?
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…
[…] Einwahlcomputer? Eine der Envelope-Adressen falsch? Oder der Quatsch wie bei 1&1: http://shxz.de/1und1/421/ # Microblog […]