SPF (Sender Policy Framework) beschreibt, welche Hosts eine Domain im SMTP-Umschlag für den Versand verwenden dürfen. DMARC (Domain-based Message Authentication, Reporting, and Conformance) prüft, ob eine erfolgreich per SPF oder DKIM authentifizierte Domain zur Domain der sichtbaren From-Adresse passt. Dazu veröffentlicht die Domain eine Richtlinie für Nachrichten, die diesen Abgleich nicht bestehen. MX beantwortet eine eigene Frage: Wohin sollen eingehende E-Mails für die Domain gehen?
Wenn Sie eine Kundendomain mit Domain Intelligence prüfen, beginnen Sie mit Ihrer konkreten Frage. Für den eingehenden Mailweg lesen Sie MX, für die Versandkonfiguration SPF und DMARC. Eine Frage zu einem bestimmten Postfach braucht Belege zur einzelnen E-Mail-Adresse.
Der Unterschied zwischen SPF, DMARC und MX
| Eintrag | Kernfrage | Was der veröffentlichte Eintrag allein nicht belegt |
|---|---|---|
| MX | Wohin geht Mail, die an diese Domain adressiert ist? | Ob ein bestimmtes Postfach existiert oder ein Server eine Nachricht annimmt |
| SPF | Darf der sendende Host die SMTP-Domainidentität verwenden? | Ob die sichtbare From-Domain authentifiziert ist |
| DMARC | Passt eine erfolgreich per SPF oder DKIM authentifizierte Domain zur sichtbaren From-Domain? |
Ob eine bestimmte Nachricht die Authentifizierung bestanden hat oder im Posteingang ankam |
SPF verwendet die SMTP-Identität MAIL FROM und kann auch HELO prüfen. Für DMARC zählt die sichtbare From-Domain. Diese Rollen beschreiben die Standards im SPF-Protokollüberblick und im DMARC-Prüfmodell.
Beim Empfang sucht SMTP nach MX-Zielen, um den Mailweg zu bestimmen. Die SMTP-Routingregeln und unser Glossar zu MX-Einträgen erklären den Ablauf.
Die Einträge einer Domain getrennt lesen
Die folgende DNS-Konfiguration ist ein erfundenes Beispiel. Alle Namen verwenden den reservierten Namensraum .example. Sie dient zur Erklärung und ist keine Vorlage für den Produktivbetrieb.
atelier.example. IN MX 10 inbound.gateway.example.
atelier.example. IN TXT "v=spf1 include:_spf.sender.example -all"
_dmarc.atelier.example. IN TXT "v=DMARC1; p=reject; aspf=s; adkim=s"
Der MX-Eintrag nennt ein Ziel für eingehende Mail. Dahinter kann ein Filter-Gateway liegen, das Nachrichten an einen anderen Postfachdienst weiterleitet. Der im SPF-Eintrag genannte Versanddienst kann ein anderer sein. Der Artikel zum Ermitteln des E-Mail-Anbieters anhand der MX-Einträge erklärt die Grenzen dieser Zuordnung.
Der SPF-Mechanismus include verweist für die Auswertung auf die SPF-Richtlinie einer anderen Domain. Das abschließende -all liefert ein SPF-Fail-Ergebnis, wenn die Auswertung diesen Mechanismus erreicht, ohne zuvor einen Treffer zu finden. Für eine echte SMTP-Transaktion braucht die Prüfung die sendende IP-Adresse, die SMTP-Identität und die referenzierte Richtlinie. Der veröffentlichte Eintrag ist nur der Ausgangspunkt. RFC 7208 definiert diese Mechanismen.
Der DMARC-Eintrag veröffentlicht p=reject und wählt mit aspf=s und adkim=s den strikten Abgleich. Dafür müssen die Domains identisch sein. Beim gelockerten Abgleich genügt dieselbe organisatorische Domain. Die Richtlinie betrifft Nachrichten mit atelier.example in der sichtbaren From-Adresse, nicht Nachrichten an atelier.example. DMARC definiert Abgleich und Richtlinie getrennt.
Die weiteren Richtlinienwerte sind none, das keine Behandlung für DMARC-Fehler vorgibt, und quarantine, das solche Nachrichten als verdächtig einstuft. Der empfangende Dienst wendet zusätzlich eigene Regeln an. Der veröffentlichte Wert garantiert keine Zustellung. DMARC-Richtlinienwerte.
SPF kann erfolgreich sein, während DMARC scheitert
Angenommen, ein Versanddienst übermittelt eine Nachricht mit diesen Identitäten:
Visible From: hello@atelier.example
SMTP MAIL FROM: bounce@sender.example
SPF result for sender.example: pass
DKIM: no passing aligned signature
Dieses Nachrichtenszenario ist erfunden und kein Ergebnis von Domain Intelligence. Nehmen wir an, der empfangende Dienst hat SPF für sender.example erfolgreich geprüft. Die Domain unterscheidet sich von atelier.example; damit erfüllt das SPF-Ergebnis den DMARC-Abgleich nicht. Ohne eine gültige DKIM-Signatur mit passender Domain scheitert DMARC. Die DMARC-Anleitung von Google erklärt diesen SPF-Abgleich.
Ein zusätzlicher Versanddienst in der SPF-include-Liste von atelier.example ändert die MAIL FROM-Identität einer Nachricht nicht. Prüfen Sie, welche Domain der Dienst tatsächlich im SMTP-Umschlag verwendet.
DKIM (DomainKeys Identified Mail) authentifiziert eine signierende Domain über eine Nachrichtensignatur. Hat die Nachricht eine gültige DKIM-Signatur mit atelier.example als Domain im Feld d=, kann sie DMARC bestehen, auch wenn die SPF-Identität nicht passt. Für DMARC genügt eine erfolgreiche Authentifizierung mit passender Domain. Das erklären die DKIM-Spezifikation und Googles Beschreibung des DMARC-Abgleichs.
Welche Belege Domain Intelligence liefert
Domain Intelligence von Emvero liest Mailweg und MX-Einträge, ordnet den sichtbaren empfangenden Anbieter zu, soweit er erkannt wird, und gibt unterstützte Felder aus veröffentlichten SPF- und DMARC-Einträgen zurück. Die Abfrage öffnet keine SMTP-Verbindung und authentifiziert keine Nachricht.
| Profilfeld | Bedeutung |
|---|---|
mail_routing.status |
routable bedeutet, dass DNS einen Mailweg bereitstellt; die Annahme für einen Empfänger wurde nicht geprüft |
SPF present und syntax |
Ob der Eintrag beobachtet wurde und seine Veröffentlichungssyntax geprüft werden konnte |
SPF includes, redirect, all_qualifier |
Ausgelesene Teile des Eintrags; referenzierte SPF-Richtlinien werden nicht rekursiv ausgewertet |
DMARC policy_domain und inherited |
Woher die gefundene Richtlinie stammt und ob sie geerbt wurde |
DMARC published_policy und effective_policy |
Veröffentlichte und wirksame Richtlinie nach den unterstützten Such- und Richtlinienregeln; beide sind kein Ergebnis für eine Nachricht |
SPF/DMARC evaluation |
not_performed: Es wurde kein Sender und keine Nachricht auf Authentifizierung geprüft |
Ein Profil mit partial kann einen bekannten Mailweg enthalten, während eine andere Beobachtung fehlt. Lesen Sie die Metadaten des betroffenen Feldes, insbesondere observed_at, expires_at und stale. Ein veralteter Wert beschreibt einen früheren Befund. Bei unknown bleibt die Frage offen. Keiner der beiden Zustände rechtfertigt einen negativen Befund in Ihrer Anwendung.
Die Dokumentation zur Domain-Intelligence-Antwort beschreibt diese Felder. Das Profil umfasst keine DKIM-Prüfung, kein DMARC-Monitoring, keine Bewertung der Versandreputation und keinen Test der Posteingangsplatzierung.
Die passenden Belege für Ihre Entscheidung wählen
Wenn Sie wissen möchten, ob eine Domain einen eingehenden Mailweg hat, beginnen Sie beim Routing. Fehlende SPF- oder DMARC-Einträge belegen nicht, dass die Domain keine Mail empfangen kann. Auch p=reject schließt ihre Postfächer nicht.
Fehlt MX, lesen Sie die Erklärung zur Domain ohne MX-Eintrag. SMTP kann dann einen impliziten Mailweg verwenden. Ein Null-MX-Eintrag erklärt dagegen ausdrücklich, dass die Domain keine Mail annimmt.
Geht es um eine einzelne E-Mail-Adresse, wählen Sie die passende vollständige Prüfung oder Domain-Prüfung. Domain-Belege reichen nicht bis zum Postfach. Eine vollständige Prüfung kann Belege zur Annahme für den Empfänger sammeln, soweit der Zielserver dies zulässt.
Bei einem Problem mit der Versandauthentifizierung untersuchen Sie eine echte Nachricht in einem empfangenden System, das Sie kontrollieren. Vergleichen Sie die Domain im SMTP-Umschlag, die sichtbare From-Domain, die DKIM-Signaturdomain und die Authentifizierungsergebnisse. Veröffentlichte DNS-Einträge allein liefern diese Ergebnisse nicht.
Um die Domainkonfiguration zu prüfen, öffnen Sie Domain Intelligence in Ihrem Emvero-Konto. Lesen Sie zuerst den Mailweg, dann die SPF- und DMARC-Beobachtungen mit ihrem jeweiligen Status und ihrer Aktualität.