---
title: "Rollenadressen bei der Registrierung sperren? | Emvero"
description: "Wann sollten Sie Rollenadressen bei der Registrierung zulassen? Erfahren Sie, was ROLE_ACCOUNT bedeutet und wie Sie Prüfung, Bestätigung und Kontoregeln trennen."
url: https://emvero.io/de/blog/block-role-based-email-signups/
language: de
updated: 2026-10-10
---

Blog

# Sollten Sie Rollenadressen bei der Registrierung sperren?

Entscheiden Sie, ob eine Rollenadresse zur Anmeldung oder als Kontakt geeignet ist. Behandeln Sie Adressprüfung, Kontoregeln und Postfachbestätigung getrennt.

Veröffentlicht 2026-10-10

Lassen Sie bei einer B2B-Registrierung Rollenadressen zu, sofern Ihr Produkt nicht für jeden Nutzer eine persönliche E-Mail-Adresse verlangt. Eine Adresse wie `support@example.com` kann genau der Kontakt sein, den ein Kunde verwenden möchte. Hängen Anmeldung oder Kontowiederherstellung vom Zugriff auf dieses Postfach ab, verlangen Sie eine Bestätigung, bevor Sie diese Funktionen freigeben.

Wenn Sie für die Anmeldung eine persönliche Adresse verlangen, erklären Sie diese Anforderung. Bieten Sie ein separates Feld für gemeinsame Rechnungs- oder Servicekontakte an. Eine technisch nutzbare Adresse sollte wegen einer Kontoregel nicht als ungültig bezeichnet werden.

## Was der Rollenname aussagt

Eine Rollenadresse ist nach einer Aufgabe wie Support oder Vertrieb benannt. [Abschnitt 3 von RFC 2142](https://www.rfc-editor.org/rfc/rfc2142.html#section-3) beschreibt geschäftliche Postfachnamen wie INFO, SALES und SUPPORT. Der Name belegt nicht, dass eine Organisation dieses Postfach eingerichtet hat.

Die Organisation kann Nachrichten an eine Person, ein gemeinsames Postfach oder ein Ticketsystem weiterleiten. Aus der Einordnung der Adresse geht nicht hervor, welcher Fall vorliegt. Der [Glossareintrag zum Rollenpostfach](https://emvero.io/de/glossary/role-account/) erklärt den Begriff und die Grenzen des Merkmals.

Emvero gleicht den Teil vor `@` mit seiner Liste von Rollennamen ab. Bei einer Übereinstimmung setzt der Dienst `checks.role_account` auf `true` und ergänzt den Reason Code `ROLE_ACCOUNT`. Nur für diesen Vergleich ignoriert Emvero die Groß- und Kleinschreibung und entfernt einen Plus-Zusatz: `support+trial@example.com` kann zum Grundnamen `support` passen. Die eingegebene Empfängeradresse bleibt unverändert. Verwenden Sie für die Bestätigung und spätere Nachrichten die ursprüngliche Adresse. Der [Leitfaden zu Plus-Adressen](https://emvero.io/de/blog/email-address-with-plus-sign/) erklärt, warum das Entfernen des Zusatzes das Ziel verändern kann.

Ein gesetztes Rollenmerkmal sagt nicht, wie viele Menschen das Postfach lesen. Fehlt das Merkmal, kann das Postfach trotzdem gemeinsam genutzt werden. Aus dem Merkmal oder seinem Fehlen lassen sich weder die Identität einer Person noch ihre Einwilligung in eine Kampagne noch ein Missbrauch des Testzugangs ableiten.

## Die Regel nach dem Zweck des Feldes wählen

Ein E-Mail-Feld kann eine Adresse für die Anmeldung, den Rechnungsversand oder den Kontakt zum Support erfassen. Entscheiden Sie nach diesem Zweck, welche Adressen Sie zulassen. Die folgenden Regeln sind Empfehlungen für Ihre Anwendung; Emvero wendet sie nicht automatisch an.

| Zweck der Adresse | Empfohlene Regel für eine Rollenadresse | Was noch zu prüfen ist |
| --- | --- | --- |
| Kontakt für Rechnungen oder Servicemitteilungen | Die vom Kunden für diese Aufgabe gewählte Adresse zulassen. | Ob der Kunde diesen Kontakt gewählt hat und die Adresse technisch nutzbar ist. Den Postfachzugriff bestätigen, wenn der Ablauf davon abhängt. |
| Anmeldung bei einem Konto, für das ein gemeinsames Postfach zulässig ist | Registrierung zulassen. Eine Bestätigung verlangen, bevor Anmeldung oder Kontowiederherstellung per E-Mail freigegeben werden. | Ob jemand die Nachricht empfangen und die Bestätigung abschließen kann. |
| Anmeldung bei einem Konto für eine bestimmte Person | Um eine persönliche geschäftliche Adresse bitten und die Anforderung erklären. Den gemeinsamen Kontakt separat speichern. | Identität und Berechtigung mit den dafür vorgesehenen Verfahren Ihrer Anwendung prüfen. Der Adressname belegt beides nicht. |
| Testzugang, bei dem Sie wiederholte Registrierungen erkennen möchten | Nicht allein wegen eines Funktionsnamens ablehnen. | Kontoverlauf und andere relevante Missbrauchshinweise. Eine Rollenadresse beweist keinen Missbrauch; eine andere Adresse beweist keine neue Person. |

Ein Kunde möchte beispielsweise `alex@example.com` für die Anmeldung und `billing@example.com` für Rechnungen verwenden. Speichern Sie zu jedem Kontakt, wofür er verwendet wird. Eine Einschränkung für das Anmeldefeld sollte den Rechnungskontakt nicht aus dem Kundendatensatz entfernen.

Auch wenn Sie eine persönliche Adresse verlangen, bleiben Ihre Prüfungen von Identität und Berechtigung notwendig. Eine Adresse, die wie ein Personenname aussieht, liefert keinen stärkeren Identitätsbeleg als `support@`.

## ROLE_ACCOUNT im Zusammenhang mit dem Prüfergebnis lesen

Nach den aktuellen Regeln von Emvero verändert das Rollenmerkmal allein weder `status` noch `action`. Das folgende Beispiel zeigt ein abgeschlossenes Ergebnis mit Rollenmerkmal. Es wurde zur Veranschaulichung erstellt und enthält nur einen Teil der Felder; es ist keine Antwort auf eine echte Anfrage:

```
{
  "status": "deliverable",
  "action": "allow",
  "checks": {
    "smtp": "accepted",
    "role_account": true
  },
  "reason_codes": ["SMTP_RCPT_ACCEPTED", "ROLE_ACCOUNT"]
}
```

`allow` bedeutet, dass die Prüfung keinen technischen Grund ergeben hat, die Adresse abzulehnen. Ihre Anwendung kann nach ihren Zugangsregeln weiterhin eine Bestätigung oder eine persönliche Adresse verlangen. Speichern Sie das zurückgegebene Ergebnis und die Entscheidung Ihrer Anwendung getrennt. Ändern Sie `deliverable` nicht in `undeliverable`, um eine Einschränkung durch Ihre Kontoregeln darzustellen.

Andere Befunde können das Gesamtergebnis ändern. Auch bei einer Rollenadresse kann die Postfachprüfung ohne eindeutiges Ergebnis bleiben oder die Domain Catch-all-Verhalten zeigen. Lesen Sie `status`, `action`, `checks` und `reason_codes` zusammen. Der [Leitfaden zum Prüfergebnis](https://emvero.io/de/blog/reading-a-verification-result/) erklärt die Zusammenhänge. Insbesondere steht `risky` nicht für eine einzige festgelegte Aktion.

## Bestätigung und Zulässigkeit getrennt behandeln

Eine abgeschlossene Bestätigung zeigt, dass jemand zu diesem Zeitpunkt Zugriff auf die Nachricht hatte und den Bestätigungsschritt in Ihrer Anwendung ausgeführt hat. Sie belegt weder alleinigen Postfachzugriff noch die Identität einer bestimmten Person im Unternehmen. Bei der Adressprüfung versendet Emvero keine Bestätigungsmail. Ihre Anwendung muss die Nachricht separat senden und prüfen, ob die Bestätigung abgeschlossen wurde. Der [Vergleich von Verifizierung und Bestätigung](https://emvero.io/de/blog/email-verification-vs-email-confirmation/) erläutert, was die beiden Schritte jeweils feststellen.

Speichern Sie auf Ihrem Server getrennt, was die Prüfung ergeben hat, ob Sie die Adresse zulassen und ob sie bestätigt wurde. Die Bestätigung muss sich auf genau die Adresse beziehen, an die Sie die Nachricht gesendet haben. Ändert jemand die Adresse, muss auch die neue Adresse bestätigt werden.

Gibt eine abgeschlossene Prüfung `unknown` zurück, reichen die Belege nicht für eine eindeutige Aussage über die Adresse. Wenn Sie den Postfachzugriff feststellen müssen, lassen Sie die Registrierung fortsetzen. Verlangen Sie aber eine Bestätigung, bevor Sie einen Zugang per E-Mail freigeben. `allow_with_email_confirmation` empfiehlt diesen Ablauf; die Bestätigung führt weiterhin Ihre Anwendung durch. Das unklare Ergebnis bedeutet nicht, dass die Adresse ungültig ist.

`pending` bedeutet, dass die Prüfung noch läuft. Fragen Sie das Ergebnis nach dem in der API-Antwort angegebenen Intervall erneut ab. Legen Sie fest, wie lange Ihre Anwendung wartet und wie sie fortfährt, wenn bis dahin kein Ergebnis vorliegt. Ein HTTP-Fehler weist auf ein Problem mit der Anfrage oder dem Dienst hin. Weder ein Fehler noch `pending` belegt, dass die Adresse `undeliverable` ist. Der [Leitfaden zur Prüfung im Registrierungsformular](https://emvero.io/de/guides/signup-form-validation/) beschreibt den Serverablauf und die Möglichkeiten nach Ablauf der Wartezeit.

## Eine Einschränkung verständlich erklären

Wenn Ihre Regel für persönliche Adressen die Registrierung verhindert, erläutern Sie die Anforderung im Formular. Zum Beispiel:

> Für die Anmeldung bei diesem Konto benötigen Sie Ihre persönliche geschäftliche E-Mail-Adresse. Eine gemeinsame Rechnungs- oder Supportadresse können Sie nach der Registrierung ergänzen.

Verwenden Sie diesen Hinweis nur, wenn das Produkt ein separates Kontaktfeld tatsächlich anbietet. Andernfalls nennen Sie den verfügbaren Weg zur Korrektur. Lassen Sie den eingegebenen Wert stehen, damit er bearbeitet werden kann.

Vermeiden Sie „Diese E-Mail-Adresse ist ungültig“, wenn nur Ihre Regel für Rollenadressen greift. Wer dieses Postfach täglich nutzt, erhält sonst eine falsche Erklärung. Prüfen Sie die Zulässigkeit auf dem Server zusätzlich zu möglichen Hinweisen im Browser. API-Zugangsdaten bleiben auf dem Server.

## Die Regel vor dem Aktivieren prüfen

Testen Sie die Entscheidungen Ihrer Anwendung mit erfundenen Adressen und vorgegebenen Prüfergebnissen. Die Tabelle setzt voraus, dass Ihre Anwendung das genannte Ergebnis erhalten hat. Dafür müssen Sie keine realen Postfächer prüfen.

| Fall | Erwartetes Verhalten Ihrer Anwendung |
| --- | --- |
| Rollenmerkmal mit `deliverable` und `allow`; gemeinsame Kontakte sind erlaubt | Registrierung fortsetzen. Postfachbestätigung verlangen, wenn der Zugang davon abhängt. |
| Dasselbe Ergebnis; zur Anmeldung ist aber eine persönliche Adresse nötig | Kontoregel erklären und um eine andere Anmeldeadresse bitten. Die ursprüngliche Adresse nur auf Wunsch des Kunden als separaten Kontakt behalten. |
| Rollenmerkmal mit `unknown` | Das unklare Ergebnis speichern. Eine Bestätigung verlangen, wenn der Postfachzugriff festgestellt werden muss. |
| Noch laufende Prüfung mit `pending` | Die Prüfung weiterhin als unvollständig führen. Das Ergebnis innerhalb der Wartefrist erneut abfragen; danach nach der festgelegten Regel fortfahren. |
| Kein Rollenmerkmal | Übliche Zugangs- und Bestätigungsregeln anwenden; keine Identität daraus ableiten. |

Beobachten Sie nach dem Aktivieren, an welcher Stelle Nutzer die Registrierung abbrechen oder ihre Adresse korrigieren. Prüfen Sie, ob sie die Bestätigung abschließen und ihre gewählten Rechnungskontakte weiterhin verwenden können. Entscheiden Sie anhand dieser Beobachtungen, ob die Einschränkung hilft, die ursprüngliche Zugangsanforderung zu erfüllen.

Sobald die Regel feststeht, prüfen Sie die eingegebenen Adressen mit der [E-Mail-Verifizierungs-API](https://emvero.io/de/email-verification-api/) auf Ihrem Server. Wenden Sie Ihre Kontoregeln an und bestätigen Sie den Postfachzugriff in separaten Schritten.

## Begriffe, die hier vorkommen

### Funktionsadresse

Eine nach einer Aufgabe benannte Adresse, etwa info@, support@ oder sales@. Der Name zeigt nicht, wer das Postfach nutzt.

### Catch-All-Domain

Eine Domain, deren Mailserver auch Adressen ohne eigenes Postfach annimmt. Die Annahme beweist deshalb kein einzelnes Postfach.

### Wegwerf-E-Mail-Adresse

Eine leicht ersetzbare Adresse bei einem Anbieter temporärer Postfächer. Solange das Postfach aktiv ist, kann es E-Mails empfangen.

## Situationen, für die das gilt

### Eine Adresse im Registrierungsformular prüfen

Auf der anderen Seite der Anfrage wartet jemand - die Latenz bestimmt also das Design, und eine falsche Ablehnung kostet Sie die Kundschaft.

### E-Mail-Prüfung im Checkout

Prüfen Sie die Adresse vor der Zahlung und bieten Sie eine Korrektur an. Legen Sie fest, was geschieht, wenn E-Mail der einzige Weg zur Auslieferung ist. Unklare Belege sind kein Adressfehler.

[Alle Beiträge](https://emvero.io/de/blog/)

## Wählen Sie, was Sie als Nächstes prüfen möchten.

Starten Sie eine Prüfung in Ihrem Konto und sehen Sie sich die Belege im Ergebnis an.

Kostenlos starten