NoReply-Adresse
Sie kennen das sicher. viele Mails im Postfach kommen mit einer "Noreply/No-reply"-Absenderadresse an. Der Versender will damit sagen, dass er keine Antwort erwartet und diese vermutlich nicht funktionieren wird. Aber sollten Sie als Firma dies nutzen? Es gibt Vorteile aber auch Risiken, wenn sie selbst Adressen zu Versand verwenden, auf die keine Antwort möglich ist.
Posteingang
Ein Blick in ein Postfach liefert sicher auch bei ihnen Treffer:

Wir sehen hier sogar Absender, die ihrer Adresse einen Displaynamen vergeben haben. Andere machen das Noreply in unterschiedlichster Schreibweise sichtbar. Einige Mails sind wirklich nur für den Empfänger relevant und bei DMARC-Reports ist es sogar ein Service des Absenders, mit diese Details zuzustellen und ich bestimmte als Empfänger, wohin diese Mails gehen. Bei den Mails zu ETA und ESTA bin ich als Person ebenfalls in der Pflicht, eine gültige und funktionierende Adresse anzugeben. Auf der anderen Seite wird sich niemand manuell darum kümmern, sich um unzustellbare Mails zu kümmern. Wenn ich aber an Absender wie "Easypark", "Deutsche Bahn", "Zoll-Portal" denke, dann sind das allesamt Dienste mit einem Konto oder App. Diese Absender könnten sehr wohl eine Rückantwort über Zustellfehler o.ä. wieder an das Konto zuordnen und z.B. in einer App oder bei der nächsten Nutzung des Diensts darüber informieren.
Übrigens. Sie können ja durchaus "Noreply" als Absender nutzen aber die Adresse kann ja durchaus gültig sein. Dann müssen aber auch Rückläufer verarbeitet werden.
Technische Mails
Bei der Übermittlung von Mails von SMTP gibt es in der Regel immer einen Absender und einen Empfänger. Die Kommunikation ist im Grunde auf bidirektional ausgelegt, d.h. der Empfänger möchte auch gerne antworten. Es gibt aber systembedingt Nachrichten, auf die eine Antwort nicht erwünscht oder erforderlich ist. Das gilt in erster Linie für Mails, die vom SMTP-Server aus unterschiedlichsten Gründen nicht weiter verarbeitet werden können, z.B.
- Ungültige Domain
Es ist ihnen sicher auch schon passiert, dass Sie sich bei der Eingabe der Domain vertippt haben. Mit etwas Glück gibt es diese Domain nicht und ihre Server hat diese schon mit einem "MX not found" zu ihnen zurückgemeldet. Sollte es diese Domain aber geben, dann wird ihr Server eine Verbindung versuchen und die Gegenseite kann reagieren. - Ungültige Mailadresse
Im einfachsten Fall gibt es die Mailadresse nicht und die Gegenseite lehnt direkt ab. Der Absender muss sich dann keine Gedanken machen, wer die Information aus Versehen bekommen hat (Datenschutz), Bandbreite wurde gespart und der Absender kann die Antwort verarbeiten. - Spam erkannt
Wenn die Empfängerseite schon bei der Übertragung die Mail auf unerwünschte Inhalte prüft, dann kann der Empfänger die SMTP-Verbindung jederzeit mit einer Fehlermeldung beenden damit ihr eigener Server einen NDR erstellt. Es kann aber auch sein, dass der andere Server die Mail erst nachgelagert prüft und dann diese als "unzustellbar" klassifiziert. Ein NDR würde dem Absender bei der Fehlersuche helfen, aber sollten Sie nicht erwarten. Spamfilter senden meinst keinen NDR, weil oft auch der Absender gefälscht ist oder selbst missbraucht wurde. - Systemfehler
Zuletzt gibt es noch ganz viele mögliche Fehler, die auch gute erwünschte und vom Spamfilter nicht gestoppte Mails an der Zustellung verhindern, z.B. ein volles Postfach (Quota) oder andere Empfangsbeschränkungen.
Auf all diese Fälle sollte ein Mailserver mit einem NDR reagieren. Im Idealfall ist es sogar ihr eigener Mailserver, bei Sie sich als Absender erfolgreich authentifiziert haben. Schlecht ist es, wenn ihr Mailserver die Nachricht schon an einen anderen Mailserver übergeben hat, der dann selbst einen NDR erstellt. Wenn ihr nicht durch SPF/DKIM-Checks sichergestellt hat, dass der Absender nicht gefälscht ist, dann besteht das reale Risiko zumindest als Störer (Siehe NDR-Backscatter). Ein NDR vom eigenen Server ist hingegen immer erwünscht, denn sie haben ihre Mail nicht versenden können und wenn ihre Mail wichtig ist, dann sollten Sie Rückmeldungen genauso ernst nehmen.
Automatisierte Mails
Dann gibt es immer wieder Prozesse, die Mails an ihre Anwender versenden. Auf der Seite Cloud Notification Mails habe ich eine lange Liste von allein Microsoft 365 Diensten aufgeführt, die alle als "no-reply" in der ein oder anderen Forme senden. Als Firma werden Sie aber auch eigene Prozesse haben, z.B. Monitoring-Lösungen (Nagios, Icinga, PRTG) und andere Dienste, die per Mail auf sich aufmerksam machen und wo der Betreiber eigentlich keine Rückmeldung erwartet.
Dennoch sollten sie hier nicht leichtsinnig eine "noreply"-Adresse verwenden, denn sonst bekommen Sie z.B. bei Alarm-Nachrichten gar nicht mit, wenn diese Mails nicht zugestellt werden. In meiner Laufbahn als Consultant habe ich mehr als einmal den Fall erlebt, dass wir eine Störung beheben musste, die sich schon lange vorab abgezeichnet hat. Die Meldungen per Mail gingen aber an eine persönliche Mailadresse eines Administrators, der schon lange nicht mehr im Unternehmen war. In einem anderen Fall hat das Monitoring die Mails als "authentifizierter Benutzer" versendet, so dass alle NDRs in diesem Funktionspostfach gelandet sind, bis am Ende das "Senden verbieten"-Quota zugeschlagen hat.
Zudem sollten Sie eine Filterung und Verarbeitung nach der Absenderadresse ermöglichen. Es ist sehr ungeschickt, wenn alle Prozesse mit der gleichen generischen "noreply@<firmedomain>" senden. Wenn Sie einen Prozess definieren, der Mails versendet, dann gibt es mehrere Optionen
- Subdomain
Eine Option wäre die Nutzung einer Subdomain, z.B. info@monitoring.<firmendomain>, report@backup.<firmendomain> oder noreply@meeting.<firmendomain>. Eine Subdomain hat den eleganten Vorteil, dass Sie sowohl den MX-Record als auch SPF/DKIM-Einträge einfach delegieren können. Der Fachverantwortlich muss dazu keine Einträge in ihrer primären "Menschen-Domain" machen und Rückläufer könnten an ein spezielles System geleitet werden - Gültiges (Shared-)Postfach
Sie könnten natürlich auch jedem Absender eine SharedMailbox mit der gewünschten Absenderadresse verpassen. Dann kommen Rückläufer dort an und der Mitarbeiter kann über seine Rechte auf dem Funktionspostfach direkt die Rückläufer bearbeiten. Da das Konto einer Shared-Mailbox aber per Default sich nicht anmelden kann, muss der Versand "anonym" oder über ein Service Principal erfolgen. - Ungültiges Postfach
Sie können natürlich alle Hinweise in den Wind schlagen und weiterhin mit einer "Noreply"-Adresse versenden, die selbst auch nicht erreichbar ist. Dann sollten Sie aber auf jeden Fall auf allen Server, die über den MX-Record für den Empfang an diese Adresse veröffentlicht werden, dafür sorgen, dass Mails an diese Adresse direkt abgelehnt werden. Ansonsten kommen die Rückmeldung bei ihnen herein und werden dann von ihrem Mailserver wieder mit einem NDR quittiert. (Siehe NDR-Backscatter).
Sie könnte aber per Messagetracking dann zumindest ermitteln, wer an diese nicht erreichbaren Adresse etwas sendet.
Im Idealfall haben sie keine oder sehr wenige vom eigenen Server erzeugten NDRs im Messagetracking, da interne Absender über das Adressbuch arbeiten können und externe Absender ihre Mail gar nicht erst einliefern können. Insofern sind plötzlich steigende NDR-Zahlen ein Alarmsignal für einen Konfigurationsfehler oder Einbruch.
Vielleicht haben Sie auch eine Voicemail-Lösung, die verpasste Anrufe oder Aufzeichnungen an die Postfächer zustellt. Würden diese nicht zugestellt und der Absender wäre eine "Noreply"-Adresse, dann würde wichtige Kundenkommunikation verloren gehen
Kundenkommunikation
Kommen wir nun die den "ganz wichtigen" Personen, die "ganz wichtige" Kundenkommunikation betreiben und sehr gerne Newsletter, Presseartikel und andere Informationen an sehr große Empfängerkreise senden. Bis zu einer gewissen Grenze (ca. 2000 externe Empfänger/24h, siehe Exchange Online Message Rate Grenzen) können Sie sogar ein Exchange Postfach dazu missbrauchen. Aber sehr schnell werden sie an Grenzen beim Versand aber auch bei der effektiven Umgang mit den Konversationen bemerken.
Sobald eine Firma ein ERP/CRM-System hat und damit viele Kontakte auch per Mail erfolgen oder sie z.B. Teams Webinare planen, dann gibt es auch automatisierte Nachrichten mit Erinnerungen, Statusmeldungen etc. Sie dienen der Information des externen Empfängers aber niemand erwartet eine Antwort. Aber nur weil Sie keine Rückantwort erwarten und daher eine nicht erreichbare "Noreply"-Adresse gerade prädestiniert erscheint, sollten sie diese Festlegung noch einmal überlegen. Die Reaktion auf eine Mal an einen Kunden kann zwar eine Antwort des Kunden sein aber es kann ebenso eine Unzustellbarkeit des Mailsystems sein. Fragen Sie mal bei Vertrieb oder Marketing nach, wie wichtig ihre Aussendungen sind und ob sie wirklich die Information über eine "Fehler bei der Zustellung " nicht weiter interessiert
Ich könnte es auch etwas direkter sagen: Wenn ein Geschäftspartner Kosten spart, weil er automatisiert Mails sendet statt per Brief, Fax, Telex oder Anruf zu kommunizieren, dann möchte ich als Gegenstelle die gleichen Vorteile nutzen und per Mail antworten. Vor allem wird der Absender sehr schwer die Zustellung beweisen können, wenn er die Unzustellbarkeiten per Design nicht annimmt.
- Mailbox External Recipient Rate (ERR) Limit
- Exchange Online als Outbound Relay
- Exchange Online Message Rate Grenzen
- Exchange Intern/Extern
- HVE - High Volume Email mit Exchange
- Limit Enforcement System
- Mailbox External Recipient Rate (ERR) Limit
- TERRL - Tenant External Recipient Rate Limit
"<>" als Absender
Neben der "Noreply"-Adresse gibt es noch eine ganz besondere Absenderadresse, die ein reguläres Postfach nie nutzen kann. Schon mit der ersten RFC zu SMTP wurden Unzustellbarkeiten definiert und damit sich hier kein Ping-Pong aufschaukeln kann, bei der ein Servers immer weiter eine Unzustellbarkeit auf eine Unzustellbarkeit erzeugt, wurde schon in der RFC821 festgelegt, dass im SMTP-Envelope auch ein leere Absender erlaubt ist.

Quelle:
https://datatracker.ietf.org/doc/html/rfc821 3.6
Relaying
Dies ist eine technische Notwendigkeit und eigentlich ein Problem, denn eine Unzustellbarkeit eines Mailservers ist ja immer eine Reaktion auf eine vorherige Mail in der Gegenrichtung. Bei der Mail sollte der Absender ja gültig sein und funktionieren. Ein Spamfilter des Absenders kann ja auch die ausgehende Mail gelernt haben und damit diese Rückantworten zumindest für einige Zeit zu lassen. Für Spamfilter ist es ansonsten sehr schwer diese Mails mit einem "<>" als Absender im Envelope auf SPF/DKIM/DMARC zu prüfen.
- RFC 821 - SIMPLE MAIL TRANSFER PROTOCOL
https://datatracker.ietf.org/doc/html/rfc821
Ungültige Mailadressen
Ein besonderer Fall ist der Versand mit Mailadressen, die gar nicht gültig sind. Es gibt erschreckend viele Systeme und Administratoren, die eine Phantasie-Adresse beim Versand angeben und bei einem Mailserver anonym einliefert. Wenn der eigene Mailserver dies erlaubt, dann wird die Mail auch weiter bis zum Empfänger geroutet. Wenn die Domain auch per SPF/DKIM abgesichert wird, dann verbessert sich auch die Zustellwahrscheinlichkeit. Es gibt aber in der Folge keine weitere Überprüfung, ob der Absender tatsächlich gültig ist.
Nur wenn der Sender sich beim ersten Mailserver authentifizieren muss, dann prüfen einige Mailserver, ob die Absenderadresse zur Authentifizierung passt. Exchange macht dies z.B. und verhindert so auch, dass ein Anwender sich mit seinen Daten per SMTP anmeldet aber vorgibt jemand anderes zu sein. So wird auch zuverlässig verhindert, dass eine ungültige Absenderadresse verwendet wird.
Aber wenn der Mailserver dies nicht erzwingt oder der Absender sogar eine Subdomain nutzt, dann könnte nur ein interner Spamfilter vielleicht solchen Missbrauch verhindern.
Wir gehen nun mal davon aus, dass Sie oder ihr Prozess ein Mail ja nicht aus Langeweile sendet, sondern sie als Absender schon Interesse an der Zustellung haben. Dann frage ich natürlich, warum Sie Rückmeldungen in Form von NDRs nicht empfangen wollen?
Ich würde keine Mail mit einer Adresse versenden, die nicht in Exchange definiert ist
Kleiner Nebeneffekt: Wenn Sie als interner Empfänger eine Mail von einem nicht existenten Absender ihrer eigenen Domain bekommen, dann klassifiziert Exchange diesen Absender als "Extern", was Auswirkungen auf Regeln etc. haben kann.
Microsoft 365
Auch ihr Microsoft 365-Tenant sendet zum Teil automatisch generierte Nachrichten und nutzt dazu je nach Dienst unterschiedliche Absenderadressen. Als Domains kamen häufig Microsoft-Domänen zum Einsatz, z.B. "norely@teams.microsoft" oder noreply@sharepoint.com und andere Adressen. Details dazu finden Sie auf Cloud Notification Mails. Mittlerweile können Sie für ihren Tenant eine eigene "Noreply"-Adresse für alle Dienste einrichten.

Quelle:
https://admin.cloud.microsoft/#/Settings/OrganizationProfile/:/Settings/L1/SendFromAddressSettings
Achtung:
Verwenden Sie nicht die <tenantname>.onmicrosoft.com-Domäne, da diese beim
Versand beschränkt ist.
Siehe auch
Limiting Onmicrosoft Domain Usage for Sending Emails
https://techcommunity.microsoft.com/blog/exchange/limiting-onmicrosoft-domain-usage-for-sending-emails/4446167
Damit werden aber alle Mails dieser Produkte über ihren Exchange Online Tenant versendet und nicht mehr direkt von Microsoft. Das hat einmal den Vorteil, dass die Mails von ihren eigenen Diensten an ihre Benutzer nun "intern" sind und nicht mehr über den MX-Record eingehend geroutet werden. Allerdings werden dann auch alle ausgehende Mails ins Internet anhand der Connectoren geroutet, ggfls. ARC/DKIM signiert. Wer ausgehende Mails über eigene Relays oder sogar OnPremises Server routet (Stichwort Exchange Online Connector Routing und EXO mit NoSpamProxy), sollte hier seine Konfiguration noch einmal prüfen. Gerade ausgehende Spamfilter erzwingen gültige Absenderadressen und wenn Sie "Noreply" nicht als Empfänger bekannt machen, werden die Mails vermutlich blockiert.
Mails für "Onetime Passcodes" (OTP) sind eine Ausnahme und werden weiter mit "no-reply@notify.microsoft.com" direkt von Microsoft versendet.
- cloud.microsoft-Name
- Teams Notification Mails
- Learn more about which products are affected by this change
https://go.microsoft.com/fwlink/?linkid=2221138 - Select the domain to use for email from Microsoft 365 products
https://learn.microsoft.com/en-us/microsoft-365/admin/email/select-domain-to-use-for-email-from-microsoft-365-products?view=o365-worldwide -
https://admin.cloud.microsoft/#/Domains
Learn more about your current domains
Einschätzung
Sie haben sicher gemerkt, dass ich kein Freund von "Noreply"-Mails bin. Es erscheint nur auf den ersten Blick einfach, Mails mit der Adresse zu senden und dem Empfänger zu signalisieren, dass der Rückweg nicht erwünscht ist und vermutlich nicht funktioniert. Das bedeutet aber auch, dass Sie nie wissen, ob ihre Mail tatsächlich angekommen ist, denn jegliche NDRs gehen ebenfalls an diese Adresse zurück. Sie nehmen sich sogar ein effektives Werkzeug, um Probleme bei der Auslieferung von Mails qualifiziert analysieren zu können.
Ich finde es aber gut, dass Microsoft eine Möglichkeit geschaffen hat, dass man die Systemnachrichten mittlerweile über eine eigenes konfigurierbare Mailadresse versenden kann. Wenn Sie diese Adresse zugleich als Empfänger, z.B. eine Shared Mailbox, anlegen und die Verarbeitung von Rückmeldungen regeln, dann können Sie deutlich ruhiger die zukünftigen Probleme abwarten.
Weitere Links
- Exchange Online und Massenmail
- Limit Enforcement System
- Mailbox External Recipient Rate (ERR) Limit
- TERRL - Tenant External Recipient Rate Limit
- Exchange Online als Outbound Relay
- NDR-Backscatter
- Cloud Notification Mails
- Exchange Online als Outbound Relay
- Exchange Online Message Rate Grenzen
- Exchange Intern/Extern
- CVM Missed Call
- PowerAutomate Mail
- Exchange Online Connector Routing
- Learn more about which products are affected by this change
https://go.microsoft.com/fwlink/?linkid=2221138 - Select the domain to use for email from Microsoft 365 products
https://learn.microsoft.com/en-us/microsoft-365/admin/email/select-domain-to-use-for-email-from-microsoft-365-products?view=o365-worldwide -
Limiting Onmicrosoft Domain Usage for Sending Emails
https://techcommunity.microsoft.com/blog/exchange/limiting-onmicrosoft-domain-usage-for-sending-emails/4446167















