<spf> declare your smtp servers

SPF erklärt

SPF ist die Abkürzung für „Sender Policy Framework“, einen Standard zur E-Mail-Authentifizierung (
), mit dem Sie festlegen können, welche SMTP-Server zum Versenden von E-Mails für Ihre Domain berechtigt sind.

Damit können Sie die Absenderadresse und deren Verbindung zu dem Server, der die Nachricht versendet hat, überprüfen.
Wenn E-Mails über Ihre Absenderdomain versendet werden, kann der Empfänger feststellen, ob sie von einem SMTP-Server stammen, den Sie kennen.

Es wird empfohlen, dies zu konfigurieren, da einige Empfänger Ihre Nachrichten möglicherweise ablehnen, wenn SPF gar nicht eingerichtet ist.

So funktioniert SPF

Es gibt zwei verschiedene Ansätze:

• eine „weiche“ Variante (~all-Tag), die einen „Softfail“-Fehler auslöst, wenn die Nachricht von einem nicht deklarierten Server gesendet wurde
• eine „harte“ Überprüfung (-all-Tag), die einen „Fail“-Fehler ausgibt, wenn die Nachricht von einem nicht deklarierten Server gesendet wurde

Die „sanfte“ Konfiguration führt zu weniger oder gar keinen Ablehnungen seitens der Empfänger.
Die „harte“ Konfiguration führt dazu, dass einige Nachrichten abgelehnt werden, wenn der Server nicht angegeben wurde oder in manchen Fällen, wenn die E-Mail weitergeleitet oder über eine Mailingliste versendet wurde.

Die „harte“ Konfiguration gibt dem Ziel-Mailserver mehr Spielraum bei der Entscheidung, ob die Nachricht angenommen wird oder nicht; dies ist der von uns empfohlene Ansatz.

So konfigurieren Sie SPF

Für die SPF-Konfiguration muss genau bekannt sein, welche Server Sie zum Versenden von E-Mails verwenden.

Bei RealSender sollte der TXT-Eintrag Ihrer Domain (example.com) die Zeichenfolge
a:example.realsender.com enthalten und wie folgt aussehen:

example.com   TXT   "v=spf1 a:example.realsender.com ~all" 

Bei HighSender sollte der TXT-Eintrag Ihrer Domain (example.com) die Zeichenfolge „
include:spf.realsender.com“ enthalten und wie folgt aussehen:

example.com   TXT   "v=spf1 include:spf.realsender.com ~all" 

Diese Tools helfen Ihnen bei der Überprüfung der Konfiguration:
www.kitterman.com/spf/validate.html *
ruft SPF-Einträge für den angegebenen Domainnamen ab und prüft, ob der Eintrag gültig ist
spf check online
überprüft Ihre E-Mail-SPF-Einstellungen durch das Versenden einer E-Mail-Nachricht

* = Link zu einer externen Website, wird in einem neuen Fenster geöffnet

Nachteile von SPF

Selbst wenn alles korrekt eingerichtet ist, kann die Nachrichtenüberprüfung unter
fehlschlagen, wenn die E-Mail weitergeleitet oder über eine Mailingliste versendet wurde.

In these cases, to keep the email authentication consistent,
configure the dkim signature domain to be aligned with the sender’s From address.
See: email authentication advanced » <dkim> alignment for dmarc.

<spf> check online

1. Senden Sie eine E-Mail an:

spf@tester.realsender.com

2. Überprüfen Sie die Ergebnisse der SPF-Validierung online:
   (es dauert etwa eine Minute, bis die Ergebnisse angezeigt werden)

https://tester.realsender.com/spf

Der RealSender-SPF-Check online fügt ein Präfix zum Betreff hinzu, wenn die Nachricht nicht ordnungsgemäß authentifiziert wurde:

!! spf-fail !!       Der SMTP-Server ist nicht unter den autorisierten Servern aufgeführt
                      und die E-Mail sollte abgelehnt oder verworfen werden
!! spf-softfail !!   Der SMTP-Server ist nicht unter den autorisierten Servern aufgeführt
                      dieser Fall sollte jedoch als „Softfail“ behandelt werden  
!! spf-neutral !!    Der SPF-Eintrag gibt ausdrücklich an, dass keine Aussage über die Gültigkeit getroffen werden kann  
!! spf-none !!       Die Absenderdomain enthält keine Informationen zur Authentifizierung der E-Mail  

Manchmal sind die auf Domänenebene gespeicherten Informationen nicht korrekt oder nicht verständlich.

!! spf-permerror !!  Es ist ein dauerhafter Fehler aufgetreten (z. B. ein falsch formatierter SPF-Eintrag)  
!! spf-temperror !!  Es ist ein vorübergehender Fehler aufgetreten

Die SPF-Prüfung erfolgt anhand der „Mail-From“-E-Mail-Adresse, die in den E-Mail-Headern verborgen ist.
Sichtbar ist lediglich die „From“-E-Mail-Adresse. Wenn sich die Stammdomänen unterscheiden, wird folgende Warnung angezeigt:

!! spf-diff !!       Die Stammdomänen von „Mail-From“ und „From“ sind unterschiedlich

Wenn die Nachricht sowohl die SPF-Prüfung als auch die SPF-Alignment-Prüfung für DMARC (Relaxed Alignment) besteht, erhalten Sie folgende Meldung:

|OK| spf-pass        Ihre E-Mail besteht die SPF-Prüfung + die SPF-Abgleichprüfung

Wenn nur eines von beiden, SPF ODER DKIM, die Übereinstimmungsprüfung für DMARC (gelockerte Übereinstimmung) besteht,
wird die Nachricht dennoch als „OK“ (vertrauenswürdig) eingestuft und das Tilde-Zeichen (~) am Anfang hinzugefügt:

|~OK| spf-pass       Ihre E-Mail besteht die SPF-Prüfung (nicht die DKIM-Prüfung) + DKIM-Prüfung

<dkim> seal the email content

DKIM erklärt

DKIM ist die Abkürzung für „DomainKeys Identified Mail“, einen Standard zur E-Mail-Authentifizierung (
), der sicherstellen soll, dass die E-Mail (einschließlich der Anhänge) seit dem Anbringen der „Signatur“ nicht verändert wurde.

Dies geschieht, indem jeder ausgehenden E-Mail-Nachricht eine digitale Signatur hinzugefügt wird, die mit einem Domainnamen verknüpft ist.

Es werden zwei Schlüssel verwendet: ein „öffentlicher“ und ein „privater“ Schlüssel:

1. Der „öffentliche“ Schlüssel wird im TXT-Eintrag der signierenden Domain veröffentlicht
2. Der „private“ Schlüssel wird auf dem SMTP-Server gespeichert und dient dazu, die E-Mail-Nachrichten zu „signieren“

Beim Versenden einer Nachricht generiert der SMTP-Server eine „verschlüsselte Hash-Signatur“, die auf dem Inhalt der E-Mail-Nachricht und dem privaten Schlüssel basiert.

Das Empfängersystem kann die Signatur im E-Mail-Header überprüfen, indem es sie mit dem E-Mail-Inhalt und dem „öffentlichen“ Schlüssel des Absenders abgleicht.

So richten Sie DKIM ein

DKIM-Signaturen sind für Endnutzer nicht unmittelbar sichtbar; sie werden von der E-Mail-Infrastruktur hinzugefügt und überprüft.

Die SMTP-Server von RealSender signieren alle ausgehenden E-Mail-Nachrichten mit einer DKIM-Signatur.

So konfigurieren Sie DKIM

RealSender versieht zunächst alle ausgehenden Nachrichten mit seiner eigenen, mit dem SMTP-Server verbundenen Domain,
. Auf Seiten der Benutzer oder Administratoren ist keine Konfiguration erforderlich.

Um die„DKIM-Domänenabgleichung für DMARC“zu erhalten,
muss die Nachricht mit derselben Domäne wie die des Absenders signiert sein.

Bei RealSender sollten Sie in den DNS-Einstellungen Ihrer Domain (beispiel.com) zwei CNAME-Einträge
hinzufügen, und zwar wie folgt:

key1._domainkey.example.com   CNAME   key1._domainkey.yourcompany.realsender.com
key2._domainkey.example.com   CNAME   key2._domainkey.yourcompany.realsender.com

Dieses Tool hilft Ihnen bei der Überprüfung der Konfiguration:
toolbox.googleapps.com *

* = Link zu einer externen Website, wird in einem neuen Fenster geöffnet

Nachteile von DKIM

Eine mit DKIM signierte Nachricht kann nicht verändert werden, ist aber dennoch für jeden lesbar.

Eine signierte Nachricht, die die Überprüfung nicht besteht, wird in der Regel abgelehnt.
Wenn auf dem Weg vom Absender zum Empfänger keine Änderungen vorgenommen wurden, sollte dies nicht passieren.

Es sind uns seltene Fälle bekannt, die alle mit der Zeilenlänge zusammenhängen (diese darf maximal 990 Zeichen betragen).
Manche Anwendungen senden den Inhalt in einer einzigen Zeile oder übertragen eine sehr lange Zeile innerhalb des HTML-Codes.
In diesen Fällen wird die DKIM-Signatur beschädigt, was zu dem Prüfergebnis „dkim=fail“ führt.

<dkim> check online

1. Senden Sie eine E-Mail an:

dkim@tester.realsender.com

2. Überprüfen Sie die DKIM-Validierungsergebnisse online:
   (es dauert etwa eine Minute, bis die Ergebnisse angezeigt werden)

https://tester.realsender.com/dkim

Der RealSender-DKIM-Check online fügt ein Betreff-Präfix hinzu, wenn die Nachricht nicht korrekt signiert wurde:

!! dkim-none !!      Es wurden keine DKIM-Signature-Header (weder gültige noch ungültige) gefunden  
!! dkim-fail !!      Es wurde ein gültiger DKIM-Signature-Header gefunden, aber die Signatur 
                      enthält keinen korrekten Wert für die Nachricht  

Manchmal ist es nicht möglich, die Überprüfung durchzuführen:

!! dkim-invalid !!   Es liegt ein Problem mit der Signatur selbst oder dem Eintrag des öffentlichen Schlüssels vor. 
                      Das heißt, die Signatur konnte nicht verarbeitet werden.
!! dkim-temperror !! Es wurde ein Fehler festgestellt, der wahrscheinlich nur vorübergehender Natur ist, 
                      wie beispielsweise eine vorübergehende Unmöglichkeit, einen öffentlichen Schlüssel abzurufen.

Wenn die Nachricht mit einer anderen Domain signiert wurde, wird dem Betreff ein „diff“-Hinweis hinzugefügt.
Diese Warnung wird NICHT angezeigt, wenn der Absender die SPF-Prüfung und die SPF-Übereinstimmung für DMARC besteht:

!! dkim-diff !!      Die Nachricht wurde NICHT von der Domain des Absenders signiert

Wenn die Nachricht sowohl die DKIM-Prüfung als auch die DKIM-Übereinstimmungsprüfung für DMARC (gelockerte Übereinstimmung) besteht, erhalten Sie folgende Meldung:

|OK| dkim-pass        Ihre E-Mail besteht die DKIM-Prüfung + die DKIM-Ausrichtungsprüfung

Wenn nur eines von DKIM oder SPF die Übereinstimmungsprüfung für DMARC (gelockerte Übereinstimmung) besteht,
wird die Nachricht dennoch als „OK“ (vertrauenswürdig) eingestuft und das Tilde-Zeichen (~) am Anfang hinzugefügt:

|~OK| dkim-pass       Ihre E-Mail besteht die DKIM-Prüfung (nicht die Übereinstimmung) + SPF-Übereinstimmungsprüfung

<spf> alignment for dmarc

SPF-Domänenabgleich für DMARC

DMARC ist ein Standard zur E-Mail-Authentifizierung, der entwickelt wurde, um gefälschte E-Mails mit gefälschten Domainnamen zu bekämpfen.
Für die Domain-Abgleichung sind folgende Voraussetzungen erforderlich:

   Wenn ein Absender seine E-Mail mittels SPF und/oder DKIM authentifiziert,  
   muss mindestens eine der Domains mit der Absender-Domain übereinstimmen

Um dies im Rahmen des SPF (Sender Policy Framework) zu erreichen, müssen Sie sich mit zwei Domänen befassen:

• die Absenderadresse, die für die Empfänger sichtbar ist
• die „Mail-From“-Adresse (auch als „Envelope-Sender“ oder „Return-Path“ bezeichnet), die verborgen ist

DMARC unterstützt zwei Arten der SPF-Anpassung: die lockere Anpassung und die strenge Anpassung.
Wenn Sie keine strenge Anpassung festlegen, wird standardmäßig die lockere Anpassung angenommen.

lockere Ausrichtung

Bei einer lockeren Übereinstimmung muss lediglich die Stammdomain der „Mail-From“-Adresse mit der Stammdomain der „From“-Adresse übereinstimmen.
Durch die lockere Übereinstimmung können beliebige Subdomains verwendet werden, ohne dass die Anforderung an die Domain-Übereinstimmung verletzt wird.

Beispiel:

• Wenn Ihre „Mail-From“-Domain „mail.abc.com“ und Ihre „From“-Domain „abc.com“ lautet,
  wird Ihre E-Mail die SPF-Prüfung bestehen (die Stammdomains „abc.com“ stimmen überein)

• Wenn Ihre „Mail-From“-Domain „abc.mail.com“ und Ihre „From“-Domain „abc.com“ lautet,
  wird Ihre E-Mail die SPF-Prüfung NICHT bestehen (die Stammdomains „mail.com“ und „abc.com“ stimmen nicht überein)

strikte Ausrichtung

Bei strikter Übereinstimmung muss die Domäne der „Mail-From“-Adresse exakt mit der Domäne der „From“-Adresse übereinstimmen.

Beispiel:

• Wenn Ihre „Mail-From“-Domain „mail.abc.com“ lautet und Ihre „From“-Domain ebenfalls „mail.abc.com“ ist,
  wird Ihre E-Mail die SPF-Prüfung bestehen (die Domains „mail.abc.com“ stimmen überein)

• Wenn Ihre „Mail-From“-Domain „mail.abc.com“ und Ihre „From“-Domain „abc.com“ lautet,
  wird Ihre E-Mail die SPF-Prüfung NICHT bestehen (die Domains „mail.abc.com“ und „abc.com“ stimmen nicht überein)

<dkim> alignment for dmarc

DKIM-Domänenabgleich für DMARC

DMARC ist ein Standard zur E-Mail-Authentifizierung, der entwickelt wurde, um gefälschte E-Mails mit gefälschten Domänen zu bekämpfen.
In Bezug auf die Domänenabgleichung sind folgende Anforderungen zu erfüllen:

   Wenn ein Absender seine E-Mail mittels SPF und/oder DKIM authentifiziert,  
   muss mindestens eine der Domains mit der Absender-Domain übereinstimmen

Damit dies im Rahmen von DKIM (DomainKeys Identified Mail) funktioniert,
muss die DKIM-Signaturdomäne (DKIM-Signature: d=…) mit der Absenderdomäne übereinstimmen.

DMARC unterstützt zwei Arten der DKIM-Anpassung: die lockere Anpassung und die strenge Anpassung.
Wenn Sie keine strenge Anpassung festlegen, wird standardmäßig die lockere Anpassung angenommen.

lockere Ausrichtung

Bei einer lockeren Zuordnung muss lediglich die Stammdomain der DKIM-Signaturdomain mit der Absenderdomain übereinstimmen.
Dank der lockeren Zuordnung kann jede beliebige Subdomain verwendet werden, ohne dass die Anforderungen an die Domain-Zuordnung verfehlt werden.

Beispiel:

• Wenn Ihre DKIM-Signaturdomäne „mail.abc.com“ lautet und Ihre Absenderdomäne „abc.com“,
  wird Ihre E-Mail die DKIM-Überprüfung bestehen (die Stammdomänen „abc.com“ stimmen überein).

• Wenn Ihre DKIM-Signatur „abc.mail.com“ lautet und Ihre „From“-Domain „abc.com“ ist,
  wird Ihre E-Mail die DKIM-Überprüfung NICHT bestehen (die Stammdomains „mail.com“ und „abc.com“ stimmen nicht überein)

strikte Ausrichtung

Bei strikter Übereinstimmung muss die DKIM-Signaturdomäne exakt mit der Domäne der Absenderadresse übereinstimmen.

Beispiel:

• Wenn Ihre DKIM-Signaturdomäne „mail.abc.com“ lautet und Ihre Absenderdomäne „mail.abc.com“ ist,
  wird Ihre E-Mail die DKIM-Überprüfung bestehen (die Domänen „mail.abc.com“ stimmen überein)

• Wenn Ihre DKIM-Signaturdomäne „mail.abc.com“ lautet und Ihre Absenderdomäne „abc.com“,
  wird Ihre E-Mail die DKIM-Überprüfung NICHT bestehen (die Domänen „mail.abc.com“ und „abc.com“ stimmen nicht überein)

<dmarc> detects fake emails

dmarc erklärt

DMARC steht für: Domain-based Message Authentication, Reporting and Conformance.
Es handelt sich um einen Standard zur E-Mail-Authentifizierung, der entwickelt wurde, um gefälschte E-Mails mit gefälschten Domänen zu bekämpfen.

Absender:

• ihre E-Mails mit SPF und DKIM authentifizieren
• eine „DMARC-Richtlinie“ veröffentlichen, in der festgelegt ist, wie mit nicht authentifizierten E-Mails umgegangen werden soll

Empfänger:

• Maßnahmen bei nicht authentifizierten E-Mails ergreifen, basierend auf der „DMARC-Richtlinie“ des Absenders
• dem Absender über das Ergebnis berichten

Bei einigen E-Mail-Anbietern hat dies einen erheblichen Einfluss auf die Zustellbarkeit, siehe:
So funktioniert DMARC mit Gmail und Office 365 im Jahr 2020 *
„Office 365 reagiert im Allgemeinen auf SPF- und DKIM-Authentifizierung.
Der einzige Weg, um konsistente Ergebnisse zu erzielen und den Posteingang zu erreichen, besteht darin, diese mit DMARC zu verknüpfen.“

* = Link zu einer externen Website, wird in einem neuen Fenster geöffnet

So richten Sie DMARC ein

DMARC nutzt die Protokolle SPF (Sender Policy Framework) und DKIM (Domain Keys Identified Mail)
, um Situationen zu regeln, in denen E-Mails die Authentifizierungstests nicht bestehen.

SPF verlangt, dass Sie angeben, welche Server Sie zum Versenden von E-Mails verwenden.
Lesen Sie nach, wie Sie SPF konfigurieren, um mehr darüber zu erfahren und es richtig einzurichten.

Die SMTP-Server von RealSender signieren alle ausgehenden E-Mail-Nachrichten mit einer DKIM-Signatur.
Wenn Sie mit derselben Domain wie der Absender signieren möchten, ist eine entsprechende Konfiguration erforderlich.
Weitere Informationen finden Sie in der Anleitung zur Konfiguration von DKIM.

RealSender stellt Ihnen ein Postfach zur Verfügung, in dem die von den Empfängern generierten DMARC-Berichte gesammelt werden.

So konfigurieren Sie DMARC

1. Zu Beginn sollten Sie das Policy-Tag auf „none“ (p=none) setzen,
   was bedeutet, dass der Mailbox-Anbieter nichts mit den gefälschten/Phishing-E-Mails unternimmt.
   Sie sollten einen TXT-Eintrag für Ihre Domain (example.com) hinzufügen, der wie folgt aussehen sollte:
   

_dmarc.example.com. IN TXT „v=DMARC1; p=none; rua=mailto:dmarc.example@rsbox.com“

2. Ab dem nächsten Tag erhalten Sie die DMARC-RUAs-Berichte online.
   
   Möglicherweise stellen Sie fest, dass Sie vergessen haben, eine E-Mail-Kampagne zu authentifizieren, die von einem Drittanbieter versendet wird.
   Sollte dies der Fall sein, authentifizieren Sie die Kampagne einfach und überprüfen Sie, ob der nächste Versand die DMARC-Tests besteht.

3. Wenn die Berichte über einige Wochen hinweg korrekt sind, weisen Sie die E-Mail-Anbieter an, diese gefälschten oder Phishing-E-Mails zurückzuweisen bzw. zu blockieren.
   
   Der _dmarc-TXT-Eintrag Ihrer Domain sollte wie folgt geändert werden:

"v=DMARC1; p=reject; rua=mailto:dmarc.example@rsbox.com"

Nachteile von DMARC

Falls Ihr Unternehmen DMARC einsetzt, sollten Sie die Seite
sorgfältig prüfen, bevor Sie eine neue Methode zum Versenden von E-Mails einführen.

Dmarc wendet strenge Richtlinien für die Überprüfung von SPF und DKIM an
Dies kann dazu führen, dass E-Mails, die diese Tests ansonsten bestehen würden
von E-Mail-Anbietern abgelehnt werden.

Selbst wenn alles korrekt eingestellt ist, kann die Überprüfung fehlschlagen:

• die SPF-Prüfung, ob die E-Mail weitergeleitet oder über eine Mailingliste versendet wurde
• die DKIM-Prüfung, falls die Nachricht verändert wurde und dadurch die DKIM-Signatur ungültig wurde

<dmarc> rua reports online

RealSender erfasst und analysiert die DMARC-RUA(*)-Berichte für Sie.

* = Bedeutung von „rua“:
Meldungs-URI(s) für aggregierte Daten. 

In RealSender ist die „rua“ die E-Mail-Adresse, die den Kunden zur Verfügung gestellt wird:
. An diese Adresse werden Sammelberichte von Domains gesendet:
, die E-Mails erhalten haben, die angeblich von Ihrer Domain stammen.

Die Berichte werden täglich um 13:00 Uhr (MEZ) erstellt und enthalten die Daten der letzten sieben Tage.

Dies ist ein DMARC-Online-Bericht, Beispielseite:

Statistiken

Ausführliche Berichte

RealSender bietet detaillierte Berichte über die Aktivitäten jedes SMTP-Servers und aller ausgehenden E-Mails.

Die Daten werden alle fünf Minuten automatisch aktualisiert.

Auf Wunsch senden wir Ihnen gerne eine wöchentliche Zusammenfassung per E-Mail zu.

Weitere Informationen auf dieser Seite:

• Zusammenfassung
• Monatsübersicht
• Tage des Monats
• Wochentage
• Öffnungszeiten
• Gastgeber
• E-Mail-Adresse des Absenders
• SMTP-Fehlercodes

Zusammenfassung

Zurück zum Anfang

Monatsübersicht

Zurück zum Anfang

Tage des Monats

Zurück zum Anfang

Wochentage

Zurück zum Anfang

Öffnungszeiten

Zurück zum Anfang

Gastgeber

Zurück zum Anfang

Absender-E-Mail

Zurück zum Anfang

SMTP-Fehlercodes

Hinweis: Diese Fehler werden durch unbefugte Versuche verursacht, E-Mails über den Server zu versenden.

Zurück zum Anfang

Lieferung & Versand

E-Mail-Daten

Mit RealSender können Sie über den Browser auf die verarbeiteten E-Mail-Daten zugreifen:

• Statusseite mit den letzten 100 heute versendeten E-Mails, die in Echtzeit aktualisiert wird
• Seite mit allen an diesem Tag versendeten E-Mails
• Seite mit allen E-Mails, die in den letzten sieben Tagen versendet wurden
• vollständiges Protokoll (unbearbeitet) mit allen an diesem Tag versendeten E-Mails, nützlich zur Überprüfung der Verbindungen
• vollständiges Protokoll (unbearbeitet, im Rohformat) der letzten sieben Tage

Die angezeigten Daten können direkt über den Browser lokal gespeichert werden oder in regelmäßigen Abständen (z. B. einmal täglich) automatisch erfasst werden, um einen Verlauf zu erstellen.

Weitere Informationen auf dieser Seite:

• Beispiele für E-Mail-Protokolle
• Benachrichtigungen zum Lieferstatus (DSN)
• Benachrichtigungen über erfolgreiche Zustellungen

Beispiele für Informationen, die im Protokoll verfügbar sind

31. Mai 06:26:22 rs336 v4V4QL1K030027:from=sender@yourcompany.com
31. Mai 06:26:25 rs336 v4V4QL1K030027:to=recipient@yourcustomer.com, dsn=2.0.0, stat=Gesendet (Nachricht zur Zustellung angenommen)

31. Mai 08:58:04 rs336 v4V6w3jN001390:from=sender@yourcompany.com
31. Mai 08:58:05 rs336 v4V6w3jN001390:to=recipient@yourcustomer.com, dsn=4.0.0, stat=Deferred: 421 recipient@yourcustomer.com Dienst nicht verfügbar – zu ausgelastet
31. Mai 09:02:03 rs336 v4V6w3jN001390:to=recipient@yourcustomer.com, dsn=4.0.0, stat=Deferred: 421 recipient@yourcustomer.com Dienst nicht verfügbar – zu ausgelastet
31. Mai 09:12:42 rs336 v4V6w3jN001390:to=recipient@yourcustomer.com, dsn=2.0.0, stat=Sent (Nachricht zur Zustellung angenommen)

31. Mai 10:00:22 rs336 v4V80L9Z004176:from=sender@yourcompany.com
31. Mai 10:00:24 rs336 v4V80L9Z004176:to=recipient@yourcustomer.com, dsn=4.7.1, stat=Deferred: 451 4.7.1 recipient@yourcustomer.com: Empfängeradresse abgelehnt: Greylisting aktiv, bitte versuchen Sie es später erneut
31. Mai 10:02:03 rs336 v4V80L9Z004176:to=recipient@yourcustomer.com, dsn=4.7.1, stat=Deferred: 451 4.7.1 recipient@yourcustomer.com: Empfängeradresse abgelehnt: Greylisting aktiv, bitte versuchen Sie es später erneut
31. Mai 10:12:04 rs336 v4V80L9Z004176:to=recipient@yourcustomer.com, dsn=2.0.0, stat=Sent (Nachricht zur Zustellung angenommen)

31. Mai 16:17:14 rs336 v4VEHCk6017038:from=sender@yourcompany.com
31. Mai 16:17:15 rs336 v4VEHCk6017038:to=recipient@yourcustomer.com, dsn=5.1.1, stat=Benutzer unbekannt
31. Mai 16:17:15 rs336 v4VEHCk6017038: v4VEHFk5017041: DSN: Benutzer unbekannt

25. Mai 12:43:37 rs336 v4PAhZw1019212:from=sender@yourcompany.com
25. Mai 12:43:38 rs336 v4PAhZw1019212:to=recipient@yourcustomer.com, dsn=5.0.0, stat=Dienst nicht verfügbar
25. Mai 12:43:38 rs336 v4PAhZw1019212: v4PAhcw0019217: DSN: Dienst nicht verfügbar

25. Mai 09:17:41 rs336 v4P7Hc6P011481:from=sender@yourcompany.com
25. Mai 09:17:42 rs336 v4P7Hc6P011481:to=recipient@yourcustomer.com, dsn=4.1.1, stat=Deferred: 452 4.1.1 recipient@yourcustomer.com 4.2.2 Postfach voll
[…] das System wiederholt den Zustellversuch alle zehn Minuten* […]
25. Mai 13:25:47 rs336 v4P7Hc6P011481:to=recipient@yourcustomer.com, dsn=4.1.1, stat=Deferred: 452 4.1.1 recipient@yourcustomer.com 4.2.2 Postfach voll
25. Mai 13:25:48 rs336 v4P7Hc6P011481: v4PBPko0020848: Absenderbenachrichtigung: Nachricht kann 4 Stunden lang nicht gesendet werden*

* = siehe Anmerkung am Ende des nächsten Absatzes

Zurück zum Anfang

Benachrichtigungen zum Lieferstatus (DSN)

Zurückgewiesene E-Mails (z. B. wegen unbekanntem Empfänger) werden an die E-Mail-Adresse des Absenders oder an die Return-Path-Adresse (sofern angegeben) zurückgesendet.

Sollte es zu einer Verzögerung bei der Zustellung der Nachrichten kommen, erhalten Sie nach 30 Minuten* eine entsprechende Benachrichtigung, die wie folgt aussieht:

Betreff:  
      Warnung: In den letzten 30 Minuten konnte keine Nachricht gesendet werden  

Text:  
      **********************************************  
      **      DIES IST NUR EINE WARNUNG      **  
      **  SIE MÜSSEN IHRE NACHRICHT NICHT ERNEUT SENDEN  **  
      **********************************************  
      [...]  

Das System versucht es vier Stunden lang automatisch erneut*. Wenn Sie keine weiteren Benachrichtigungen erhalten, bedeutet dies, dass die Nachricht erfolgreich zugestellt wurde. Sie können die Details in den Protokollen nachlesen (siehe die oben genannten Beispiele).

Nach vier Stunden* erfolgloser Wiederholungsversuche wird eine eindeutige Fehlermeldung an die E-Mail-Adresse des Absenders oder an die Return-Path-Adresse (sofern angegeben) gesendet, und zwar wie folgt:

Subject:  
      Returned mail: see transcript for details  
Body:  
      The original message was received at ...  
      ----- The following addresses had permanent fatal errors -----  
      <recipient@yourcustomer.com>  
      ----- Transcript of session follows -----  
      Deferred: Connection timed out with yourcustomer.com.  
      Message could not be delivered for 4 hours  
      Message will be deleted from queue  
      [...]  

* = beim Versand von Massen-E-Mails:
Benachrichtigungen über verzögerte Zustellungen sind deaktiviert,
das Intervall zwischen den Zustellversuchen wird verlängert (von zehn auf dreißig Minuten),
die maximale Verweildauer in der Warteschlange wird verlängert (von vier auf vierundzwanzig Stunden)

Zurück zum Anfang

Benachrichtigungen über erfolgreiche Zustellungen

Auf Wunsch können wir die „Zustellungsbenachrichtigung“ auch für erfolgreich zugestellte E-Mails aktivieren. Auf diese Weise erhält der Absender für jede zugestellte Nachricht eine Zustellungsbestätigung vom Zielserver, wie im folgenden Beispiel. Diese Option ist nützlich für alle, die für jede versendete E-Mail eine Zustellungsbestätigung benötigen.

Subject: 
      Return receipt
Body:
      The original message was received at ...
      ----- The following addresses had successful delivery notifications -----
      <recipient@yourcustomer.com>  (successfully delivered to mailbox)
      ----- Transcript of session follows -----
      <recipient@yourcustomer.com>... Successfully delivered
      [...]

In seltenen Fällen (bei weniger als 1 % der versendeten E-Mails) wird die Empfangsbestätigung nicht an den Absender gesendet. Dies geschieht, wenn der Empfänger auf seinem Mailserver eine spezielle Option namens „Datenschutz / keine Empfangsbestätigungen“ aktiviert hat. Diese Einstellung wird im Allgemeinen nicht empfohlen, da sie auch den Versand von standardmäßigen Benachrichtigungen über die Nichtzustellung blockiert.

Zurück zum Anfang

E-Mails abrufen

Manchmal muss man sich die versendeten E-Mails ansehen, um zu verstehen, was vor sich geht.

Auf Wunsch kann RealSender die automatische Kopie aller ausgehenden E-Mails in ein spezielles Postfach aktivieren.

Das Postfach ist so eingerichtet, dass es problemlos große Mengen an E-Mails innerhalb kurzer Zeit empfangen kann.
E-Mails werden nach 7 Tagen automatisch gelöscht.

Bitte beachten Sie: Wenn die Nachrichten von privaten E-Mail-Konten versendet werden (auch wenn es sich um Firmenkonten handelt),
müssen Sie den Absender darüber informieren, dass die von ihm gesendeten Nachrichten zu technischen Überprüfungszwecken eingesehen werden können.