Kategorien
Blog

421 invalid sender domain, possibly misconfigured

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.

Von dentaku

Site Reliability Engineer, Internet-Ureinwohner, Infrastrukturbetreiber, halb 23-Nerd halb 42-Nerd, links, gesichtsblind.

Schreibt mit "obwaltendem selbstironischem Blick auf alles Expertentum" (Süddeutsche Zeitung)

41 Antworten auf „421 invalid sender domain, possibly misconfigured“

dentaku sagt:

Das könnte noch dauern, ich habe auf dem Gateway (Postfix) mal lieber

maximal_queue_lifetime=14d

eingestellt.

Andreas sagt:

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

Udo sagt:

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.

Udo sagt:

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.

dentaku sagt:

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…“).

Heiko sagt:

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.

Christian sagt:

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….

Herbert sagt:

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

Udo sagt:

wie ich gerade sehe, sind meine Emails seit 16:15 bei 1&1 angenommen worden. Sry, wenn’s bei Euch noch nicht klappt.

Udo sagt:

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.

dentaku sagt:

Hmmm, das ist bei uns ja vorher schon so (siehe Ursprungsartikel). Ich mach mal ein paar Experimente…

dentaku sagt:

Test 1: von unserem MX aus an die befreundete Firma Architur senden:

desenberg:~# host -t mx architur.de
architur.de             MX      10 mx01.kundenserver.de
architur.de             MX      10 mx00.kundenserver.de
desenberg:~# telnet mx01.kundenserver.de 25
Trying 212.227.15.186...
Connected to mx01.kundenserver.de.
Escape character is '^]'.
220 mx-b.kundenserver.de (mxbap1) Welcome to Nemesis ESMTP server
EHLO desenberg
250-mx-b.kundenserver.de
250-PIPELINING
250-8BITMIME
250-SIZE 100000000
250 HELP
MAIL FROM:<*PIIEP*@as-gmbh.com>
250 OK
RCPT TO:<*PIIEP*@architur.de>
421 invalid sender domain, possibly misconfigured
QUIT
221 OK
Connection closed by foreign host.
desenberg:~#

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.

dentaku sagt:

Der Server heißt desenberg.advanced-solutions.de, also probieren wir diese Domain in der Absendeadresse:

desenberg:~# telnet mx01.kundenserver.de 25
[...]
MAIL FROM:<*PIIEP*@advanced-solutions.de>
250 OK
RCPT TO:<*PIIEP*@architur.de>
250 OK
DATA
354 Enter mail, end with "." on a line by itself
[...]
.
250 Message 0MKreC-1MRtUd1KKI-000RHM accepted by mxbap0.kundenserver.de
QUIT
221 OK
Connection closed by foreign host.

Ok, das funktioniert. Als nächstes mal testen, ob es an dem einliefernden Host liegt…

dentaku sagt:

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):

MAIL FROM:<*PIIEP*@as-gmbh.com>
250 OK
RCPT TO:<*PIIEP*@architur.de>
421 invalid sender domain, possibly misconfigured
[...]
MAIL FROM:<*PIIEP*@advanced-solutions.de>
250 OK
RCPT TO:<*PIIEP*@architur.de>
250 OK 

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…

Philipp sagt:

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

mx-neu:~# telnet mx01.kundenserver.de 25
Trying 212.227.15.134...
Connected to mx01.kundenserver.de.
Escape character is '^]'.
220 mx-b.kundenserver.de (mxeu3) Welcome to Nemesis ESMTP server
ehlo mx-test.domain.de
250-mx-b.kundenserver.de
250-PIPELINING
250-8BITMIME
250-SIZE 100000000
250 HELP
mail from: test@mx-test.domain.de
250 OK
rcpt to: 
250 OK
QUIT
221 OK

Vielleicht hift es ja auch bei Dir und denen, die diesen Beitrag lesen

dentaku sagt:

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?

Philipp sagt:

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

dentaku sagt:

Ich habe jetzt mal einen einfachen SPF-Eintrag in der Domain eingefügt:

desenberg:~# host -t txt as-gmbh.com
as-gmbh.com             TXT     "v=spf1 mx -all"

Mal abwarten bis das durchs DNS durchpropagiert ist, dann werde ich sehen ob das irgendeinen Effekt hat.

Philipp sagt:

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.

dentaku sagt:

Der 1&1-Support hat sich übrigens gemeldet.

marcus sagt:

Abhilfe:

1. SPF-Record anlegen
2. MX auf A-Record, nicht auf CNAME-Record zeigen lassen

dentaku sagt:

@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).

Christian sagt:

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.

durtro sagt:

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 …

dentaku sagt:

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:

Sehr geehrtes 1&1-Support Team.

Ich erwarte seit heute morgen eine dringende Mail von *PIIEP*@as-gmbh.com, von der einiges abhängt.
Nach mehrmaligen Nachfragen im Unternehmen wurde die Mail von meinem Firmenaccount mehrfach abgeschickt,aber sie kommt nicht durch.
Der Mailadministrator meint, es käme von meiner Domain, d.h. Ihrer Infrastruktur nur ein:
„421 invalid sender domain, possibly misconfigured“ mit dem Vermerk, dass dies auch von anderen 1&1 -Mailadressen zurück käme, ohne daß hier eine Ursache erkennbar wäre..
Da an der Senderdomain keine Änderungs vorgenommen wurde liegt das Problem bei Ihnen.
Bitte sorgen Sie umgehend dafür, das Mails von bisherigen Mailpartnern auch wieder ordentlich zugestellt werden, bzw. klären Sie den tatsächlichen Sachverhalt.
So ist das nicht hinnehmbar und sehe Sie hier in der Pflicht.
Ansonsten sehe ich mich gezwungen, nach einem anderen Provider Ausschau zu halten, der eine funktionierende Mailinfrastruktur bereit hält.

mit angesäuerten Grüßen

😉

Simon sagt:

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

Robert sagt:

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

dentaku sagt:

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…

Zahl sagt:

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. 🙂

Christof sagt:

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?

dentaku sagt:

@Christof: Das ist, hmmm, Auslegungssache. Empfohlen ist es jedenfalls auch außerhalb von 1&1 nicht.

keyJ sagt:

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

Tom Hutter sagt:

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

Ben sagt:

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 […]

Jan Schaumann sagt:

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…

Eq5 sagt:

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

Michael sagt:

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

Michael sagt:

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?

dentaku sagt:

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     […]

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert