Domain Intelligence für E-Mail führt Belege zur Mailkonfiguration, zur Netzinfrastruktur und, soweit verfügbar, zur Registrierung einer Domain zusammen. Damit können Sie eine Kundendomain untersuchen oder einen CRM-Eintrag um technische Angaben ergänzen. Jede Beobachtung beantwortet eine eigene Frage: Wohin geht die Mail? Welche Versandrichtlinie ist veröffentlicht? Welches Netz kündigt eine IP-Adresse an? Wann wurde die Domain registriert?
Ordnen Sie diese Angaben einzeln ein, bevor Sie entscheiden. Ein nutzbarer Mailweg belegt kein bestimmtes Postfach. Eine lange bestehende Registrierung belegt ebenso wenig, dass Sie der heutigen nutzenden Person vertrauen können. Domain Intelligence von Emvero sammelt Infrastrukturbelege, ohne eine SMTP-Sitzung zu öffnen oder eine E-Mail zu senden.
Zuerst den eingehenden Mailweg prüfen
Prüfen Sie, ob die Domain einen Weg für eingehende E-Mails hat. Im Emvero-Profil kann mail_routing.status den Wert routable enthalten. Damit ist ein Mailweg in der beobachteten DNS-Konfiguration belegt; ein Empfänger wurde nicht geprüft.
MX-Einträge nennen die empfangenden Hosts. Eine Anbieterzuordnung beschreibt den sichtbaren Betreiber des Maileingangs. Das kann ein Filter-Gateway vor dem eigentlichen Postfachdienst sein. Bei mx.provider_match mit dem Wert unknown bleibt der Anbieter unbekannt. Ein ungewohnter Hostname belegt keinen selbst betriebenen Mailserver. Der separate Leitfaden erklärt, wie Sie den E-Mail-Anbieter anhand von MX-Einträgen ermitteln.
Eine leere MX-Antwort braucht eine genauere Einordnung: Ohne MX erlaubt SMTP einen impliziten Mailweg zur Adresse der Domain selbst. RFC 5321 beschreibt diesen Rückfallweg. Die einzelnen Diagnosefälle behandelt der Artikel zur Domain ohne MX-Eintrag.
Versandkonfiguration und Klassifizierungen einordnen
SPF- und DMARC-Felder beschreiben, was die Domain zum E-Mail-Versand veröffentlicht. In Domain Intelligence bedeutet not_performed, dass keine Nachricht auf erfolgreiche Authentifizierung geprüft wurde. Die Abfrage prüft die unterstützte Syntax und Richtlinienfelder der veröffentlichten Einträge. Sie verfolgt keine SPF-Includes zur Bewertung eines Absenders und sucht keine DKIM-Schlüssel. Der Vergleich von SPF und DMARC erklärt den Bezug dieser Verfahren zu einer Nachricht.
Die Klassifizierungen unter email.classification stammen aus Referenzdaten. Eine Domain, die auf keiner Wegwerfliste steht, ist dadurch nicht als sicher bestätigt. Auch ein negatives Merkmal für öffentliche Mailanbieter belegt keine geschäftliche Adresse.
Das Feld email.catch_all.state gibt bereits gespeicherte Belege zur Domain wieder. Diese Abfrage führt keine neue Empfängerprüfung durch. Aus unknown lässt sich weder „akzeptiert jeden Empfänger“ noch „prüft einzelne Postfächer“ ableiten.
Netz- und Registrierungsdaten richtig zuordnen
Sowohl standard als auch extended enthalten Netzdaten. network.mail beschreibt die Adressen der Mailhosts. network.web enthält die für die angefragte Domain aufgelösten Adressen und die dazu verfolgte CNAME-Kette. Eine Autonomous System Number, kurz ASN, kennzeichnet das Netz, das eine Adresse ankündigt.
Damit können Sie die Infrastruktur vergleichen. Mail- und Website-Adressen können zum selben Netz gehören und trotzdem unterschiedliche Aufgaben erfüllen. Das Länderfeld nennt das Registrierungsland des autonomen Systems und erlaubt daher keine Standortbestimmung des Servers. Ist ein CDN oder Proxy sichtbar, können dessen Edge-Adressen den Ursprungsserver verdecken. Eine aufgelöste Adresse belegt außerdem nicht, dass dort eine Website antwortet.
Die Variante extended ergänzt Registrierungsdaten über RDAP, das Registration Data Access Protocol. RDAP unterscheidet Ereignisse wie Registrierung und spätere Änderungen mit jeweils eigenen Datumsangaben. RFC 9083 definiert diese Ereignisfelder.
Prüfen Sie registration.registered_domain, bevor Sie das Alter verwenden. Bei einer Subdomain bezieht sich die Registrierung auf die registrierbare übergeordnete Domain. registration.age_days zählt die vollen Tage vom gemeldeten Registrierungsdatum bis zu generated_at. Daraus folgen weder das Gründungsdatum des Unternehmens noch der Start der Website oder der Zeitpunkt eines Eigentümerwechsels. Manche Registries liefern kein Datum. Halten Sie diese Lücke fest, statt ein Alter von null einzutragen.
Ein Domain-Profil am Beispiel lesen
Angenommen, Sie prüfen example.com, bevor Sie technische Angaben in einen Kundendatensatz übernehmen. Die folgenden Werte stammen aus einem synthetischen Beispiel, nicht aus einer Live-Abfrage. Es handelt sich um ausgewählte Beobachtungen, nicht um eine vollständige API-Antwort.
| Beobachtung | Was Sie festhalten können |
|---|---|
mail_routing.status: routable |
Die beobachtete Konfiguration bietet einen eingehenden Mailweg. |
mx.provider_match: unknown |
Es wurde kein einzelner Anbieter für den Maileingang ermittelt. |
email.catch_all.state: unknown |
Das Catch-all-Verhalten ist nicht belegt. |
| IP-Adressen der Mailhosts liegen in AS64500 und AS64511; IP-Adressen der Website in AS64500 | Einige Mail- und Website-Adressen teilen sich ein Netz. Ein gemeinsamer Dienstbetreiber ist damit nicht ermittelt. |
registration.age_days: 2191 |
Die gemeldete Registrierung ist zum Erstellungszeitpunkt des Beispiels 2191 volle Tage alt. |
SPF -all; DMARC reject |
Das sind veröffentlichte Versandeinstellungen, keine Authentifizierungsergebnisse einer Nachricht. |
Das Profil liefert nützliche Infrastrukturangaben, aber keine Aussage über alex@example.com. Benötigen Sie beim Onboarding Belege zu dieser Adresse, prüfen Sie sie separat. Der Vergleich von vollständiger Prüfung und Domain-Prüfung erklärt die Aussagekraft der beiden Prüftiefen. Wenn die Kontrolle über das Postfach entscheidend ist, braucht es zusätzlich eine Bestätigung durch die betreffende Person. Eine technische Prüfung belegt weder die Einwilligung in Ihre Nachrichten noch garantiert sie die Zustellung in den Posteingang.
Für diese Kundenprüfung könnten Sie den Mailweg und das Registrierungsalter speichern, während Anbieter und Catch-all unbekannt bleiben. Eine kürzlich registrierte Domain könnte nach Ihren eigenen Regeln Anlass für eine Rückfrage sein. Das Registrierungsalter allein rechtfertigt weder die Annahme noch die Ablehnung eines Kunden.
Auch bei einem vollständigen Profil das benötigte Feld prüfen
complete beschreibt den Abschluss der erforderlichen Beobachtungen für die gewählte Variante. Ein vollständiges Profil kann weiterhin einen unbekannten Anbieter oder Catch-all-Status enthalten. Es kann auch belegen, dass eine Domain keine E-Mails annimmt. Netzdaten bestimmen diesen Gesamtstatus nicht; lesen Sie deshalb deren eigene Metadaten.
Ein Profil der Variante extended bleibt partial, wenn das Registrierungsdatum fehlt. Nutzbare Belege zum Mailweg bleiben dadurch erhalten. Fällt dagegen die Quelle für den Mailweg selbst aus, kann der Dienst einen Fehler zurückgeben. Ein DNS-Fehler belegt keinen fehlenden Mailbetrieb.
Prüfen Sie vor der Verwendung eines Feldes meta.status und reason, danach die verfügbaren Werte für source, source_version, observed_at, expires_at und stale. Ein gerade zusammengestelltes Profil kann ältere Beobachtungen enthalten. Die Dokumentation zu Domain Intelligence beschreibt diese Felder.
Zwei Ablaufdaten haben unterschiedliche Bedeutungen: registration.expires_at nennt das Ablaufdatum der Domain laut Registry. registration.meta.expires_at beschreibt dagegen, wie lange die zwischengespeicherte Registrierungsbeobachtung wiederverwendet werden kann. Keines der beiden Daten sagt, wann das Postfach des Kunden nicht mehr funktioniert.
Belege und Entscheidung getrennt speichern
Bewahren Sie in einer CRM-Anbindung die geprüfte Domain, die für Ihren Ablauf benötigten Felder und deren Beobachtungszeiten auf. Halten Sie das Domain-Profil vom Verifizierungsergebnis einer Kontaktadresse getrennt. Teilen mehrere Kontakte eine Domain, liefert das Profil gemeinsame Angaben zur Domain, ohne die Funktionsfähigkeit aller Postfächer zu belegen.
Speichern Sie auch Ihre Entscheidung mit ihrer Begründung separat. Bei neuen Beobachtungen können Sie den Datensatz erneut prüfen. Eine alte Anbieterzuordnung oder ein fehlendes Registrierungsdatum sollte nicht dauerhaft über den Kunden entscheiden. Ihre Anbindung schreibt diese Daten; die Abfrage aktualisiert das CRM nicht automatisch.
Wenn Sie eine abgeschlossene API-Abfrage innerhalb des Wiederholungsfensters mit demselben Idempotency-Key, derselben Domain und derselben Variante wiederholen, erhalten Sie die gespeicherte Antwort. Die Beobachtungen werden dabei nicht aktualisiert. Der Leitfaden zur Domain Intelligence API beschreibt Wiederholungen und neue Abfragen.
Ohne eigene Anbindung können Sie eine Domain mit Emvero untersuchen. Beginnen Sie beim Mailweg und lesen Sie danach die ergänzenden Felder, die Ihre konkrete Prüffrage beantworten.