Recruiting-E-Mails authentifizieren: Eine Checkliste

Um die Authentifizierung Ihrer Recruiting-E-Mails zu prüfen, senden Sie eine Testnachricht mit fiktiven Bewerberdaten über jeden Dienst, den Sie tatsächlich nutzen. Prüfen Sie im empfangenden Postfach die Ergebnisse für SPF, DKIM und DMARC, den Domain-Abgleich und den Eingang der Antworten. Ein erfolgreicher Versand belegt weder den Eingang im Posteingang noch das Lesen oder eine Antwort.

Die Hacker-News-Diskussion über Mailfullys Authentifizierungsleitfaden greift ein bekanntes Einrichtungsproblem auf. Das Postfach Ihrer Gründerin oder Ihres Gründers, das ATS und der Dienst für die Terminplanung können alle Ihren Firmennamen anzeigen und dabei unterschiedliche Infrastruktur nutzen. Wenn ein Dienst funktioniert, sagt das wenig über die anderen aus.

Halten Sie für jeden Versandweg ein kurzes Prüfprotokoll fest. So erstellen Sie es, ohne funktionierende DNS-Einträge zu ersetzen oder aus einer grünen Statusanzeige ein unbelegtes Versprechen abzuleiten.

Welche Dienste senden Recruiting-E-Mails über Ihre Domain?

Erfassen Sie die Dienste, die Nachrichten an Kandidatinnen und Kandidaten senden, bevor Sie DNS-Einträge ändern. Jeder eigenständige Versandweg braucht einen eigenen Test, auch wenn alle Nachrichten scheinbar von [email protected] kommen.

Beginnen Sie mit dem gewöhnlichen Postfach Ihrer Recruiting-Verantwortlichen oder Gründer. Ergänzen Sie dann das ATS für Eingangsbestätigungen und Antworten an Kandidaten, den Dienst für Intervieweinladungen sowie separate Dienste für Angebote oder Bewertungen. Halten Sie fest, wer jeden Dienst verwaltet und welche Domain er verwenden soll.

Diese Trennung ergibt sich aus der Funktionsweise der E-Mail-Authentifizierung. Die Standards prüfen die Versandinfrastruktur und Domain-Identitäten. Diese können sich trotz gleicher sichtbarer From-Adresse unterscheiden. Deshalb sind getrennte Tests sinnvoll; ein generelles Zustellproblem von ATS lässt sich daraus nicht ableiten.

Erfassen Sie genügend Einzelheiten, um falsche Annahmen zu erkennen:

Verwenden Sie erfundene Bewerberdaten und Postfächer unter der Kontrolle Ihres Teams. So prüfen Sie, ob die Antwort der richtigen Bewerbung zugeordnet wird, ohne einen echten Kandidaten zu kontaktieren oder dessen Gespräch an einen Diagnosedienst weiterzugeben.

Trennen Sie diesen technischen Test von Ihrer Zusage an Bewerber. Unser Antwortplan für die Personalsuche auf Hacker News beschreibt, wer Bewerbungen prüft und wann Bewerber eine Rückmeldung erhalten. Die Authentifizierung unterstützt diesen Ablauf. Sie weist jedoch niemandem eine Prüfung zu und sorgt nicht dafür, dass diese Person antwortet.

Was prüfen SPF, DKIM und DMARC tatsächlich?

SPF autorisiert die Versandinfrastruktur für eine Envelope-Identität. DKIM prüft eine Signatur, die einer signierenden Domain zugeordnet ist. DMARC prüft, ob ein erfolgreiches Ergebnis mit der Domain der sichtbaren From-Adresse übereinstimmt.

Diese Identitäten lassen sich leicht verwechseln, weil Ihr E-Mail-Programm meist nur eine Adresse anzeigt. Die Nachricht enthält jedoch mehrere:

Die SPF-Spezifikation unterscheidet die Envelope-Identität vom sichtbaren From-Header. Die DKIM-Spezifikation beschreibt die Domain-Signatur. Weder ein vertrauter Anzeigename noch eine passende Reply-To-Adresse stellt den von DMARC verlangten Domain-Abgleich her.

Betrachten Sie diese fiktive, direkt versandte Nachricht:

From: Hiring Team <[email protected]>
Envelope sender: [email protected]
DKIM signing domain: example.com

Das SPF-Ergebnis des Anbieters kann für vendor.example.net erfolgreich sein, ohne mit example.com übereinzustimmen. Eine gültige DKIM-Signatur für example.com kann trotzdem das erfolgreiche, domainkonforme Ergebnis liefern, das DMARC benötigt. DMARC verlangt nicht, dass beide Verfahren erfolgreich sind und den Domain-Abgleich bestehen. Mindestens ein erfolgreiches Verfahren mit passender Domain kann die Authentifizierungsprüfung erfüllen. RFC 9989 erklärt diese Regel.

Für den Domain-Abgleich, auch Alignment genannt, gibt es verschiedene Modi. Im gelockerten Modus können Domains übereinstimmen, wenn sie dieselbe organisatorische Domain haben. Der strikte Modus verlangt eine exakte Übereinstimmung. Der Versand über eine Subdomain ist daher nicht automatisch ein Fehler. Erfassen Sie die tatsächlichen Domains und die Richtlinie, statt jede Abweichung als Mangel einzustufen.

Damit prüfen Sie die Domain-Nutzung, nicht die Seriosität eines Stellenangebots oder die Absichten des Absenders. Dazu lesen Sie unseren Artikel über gefälschte Recruiter-Identitäten und das Vertrauen von Kandidaten.

Wie ergänzen Sie einen Absender, ohne bestehende E-Mails zu beeinträchtigen?

Besorgen Sie die aktuellen Domain-Anweisungen des neuen Dienstes und gleichen Sie diese mit den veröffentlichten Einträgen ab. DNS-Beispielwerte erläutern die Einrichtung; sie sind keine Einstellungen für Ihre eigene Domain.

Klären Sie zunächst, ob Sie die Authentifizierung ausgehender Nachrichten, die Weiterleitung eingehender Nachrichten oder beides einrichten. Ein MX-Eintrag steuert den Eingang von E-Mails. Eine Änderung kann Antworten von Mitarbeitern oder Kandidatinnen und Kandidaten an einen anderen Dienst leiten. Sie autorisiert keinen ausgehenden Versand. Wenn Ihre Hauptdomain Mitarbeiter-E-Mails bereits über einen anderen Anbieter empfängt, können Sie den Empfang von Recruiting-E-Mails über eine eigene Subdomain unabhängig davon einrichten.

Behalten Sie bei SPF Ihre bestehenden berechtigten Absender bei. Durch das Hinzufügen eines ATS darf die erforderliche Autorisierung des Mitarbeiterpostfachs nicht unbemerkt entfallen. Eine zweite SPF-Richtlinie ist ebenfalls kein sicherer Ausweg, um die erste unverändert zu lassen: Die Auswahl von SPF-Einträgen führt zu einem dauerhaften Fehler, wenn mehrere auswählbare Einträge vorhanden sind.

SPF begrenzt außerdem die ausgewerteten Mechanismen und Modifikatoren, die DNS-Abfragen auslösen. Die Obergrenze beträgt zehn solcher Ausdrücke; verschachtelte Includes zählen mit. Gemeint ist nicht jede einzelne DNS-Anfrage des Resolvers. Wenn Sie weitere Anbieter in die Richtlinie aufnehmen, prüfen Sie ihre Auswertung, statt die Wörter im TXT-Eintrag zu zählen. Einzelheiten finden Sie in den Auswertungsgrenzen von RFC 7208.

Veröffentlichen Sie für DKIM den Selektor und den Schlüssel beziehungsweise die Delegation Ihres Versanddienstes. Ein Eintrag für den Selektor des Mitarbeiterpostfachs konfiguriert nicht automatisch das ATS. Dokumentieren Sie, welcher Dienst welchen Selektor verwendet. So löschen Sie beim späteren Entfernen eines Anbieters nicht die funktionierende Signatur eines anderen.

Prüfen Sie bei DMARC die bestehende Richtlinie, bevor Sie sie durch ein Beispiel aus einer Anleitung ersetzen. Möglicherweise werden bereits Berichte gesammelt oder strengere Vorgaben durchgesetzt. Legen Sie der für die Domain verantwortlichen Person die vollständige geplante Änderung vor, einschließlich der beibehaltenen Absender und des vorgesehenen Berichtsziels.

Wie testen Sie den tatsächlichen Versandweg für Bewerber-E-Mails?

Senden Sie über den echten Arbeitsablauf, prüfen Sie die Ergebnisse beim Empfänger und antworten Sie auf die Nachricht. Ein Test aus einem Administratorpostfach prüft nicht die ausgehende Konfiguration des ATS.

Wählen Sie für jede Zeile Ihrer Bestandsaufnahme einen eindeutigen Testbetreff. Verwenden Sie ein eigenes Postfach bei dem Empfängeranbieter, den Sie prüfen möchten. Legen Sie im ATS eine fiktive Bewerbung an und nutzen Sie dieselbe Antwortfunktion wie Ihre Recruiting-Verantwortlichen. Lösen Sie im Terminplanungsdienst den echten Einladungsablauf aus, statt dessen Text von Hand nachzubilden.

Öffnen Sie die vollständigen Header oder die Originalansicht der empfangenen Nachricht. Erfassen Sie den sichtbaren Absender, die nach der Zustellung angezeigte Envelope-Domain und die signierende DKIM-Domain. Suchen Sie dann die Authentifizierungsergebnisse, die der empfangende Dienst hinzugefügt hat. Verwenden Sie dessen vertrauenswürdige Ergebnisse. Eine Zeile, die ein früherer Absender in die Nachricht geschrieben hat, ist kein gleichwertiger Nachweis.

Das Prüfprotokoll kann übersichtlich bleiben:

Halten Sie Datum, Versandkonfiguration, Empfängeranbieter und verantwortliche Person fest. Notieren Sie getrennt davon, ob der Test im Posteingang oder im Spamordner erschien. Bewahren Sie genügend Nachweise für eine Fehleranalyse auf. Private Header und Bewerberinhalte gehören jedoch nicht in ein öffentliches Ticket.

Klicken Sie abschließend auf Antworten und senden Sie eine kurze Rückmeldung. Prüfen Sie, ob diese im vorgesehenen Postfach oder Gespräch mit dem Kandidaten ankommt und ob das zuständige Teammitglied sie sehen kann. Ein Terminplanungsdienst kann bewusst einen anderen Antwortweg verwenden. Dokumentieren Sie das Verhalten, statt anzunehmen, dass jede Einladung zum ATS zurückführt.

Eine bestandene Prüfung belegt etwas über diese Nachricht, diesen Versandweg, diese Konfiguration und diesen Empfänger. Wiederholen Sie den Test bei Bedarf mit einem weiteren wichtigen Empfängeranbieter. Weitergeleitete Nachrichten und Mailinglisten können sich bei der Authentifizierung anders verhalten. Untersuchen Sie diese Fälle separat, bevor Sie ein fehlgeschlagenes SPF-Ergebnis als Beleg für einen unberechtigten Absender werten.

Was verlangen Gmail und Yahoo von Ihrer Versanddomain?

Beide Anbieter veröffentlichen Anforderungen an Absender und zusätzliche Vorgaben für Massenversender. Prüfen Sie Empfängeranbieter, Versandvolumen und Nachrichtenzweck, bevor Sie eine Vorgabe in Ihre Checkliste aufnehmen.

Die Absenderrichtlinien von Google gelten für Nachrichten an private Gmail-Konten. Alle Absender benötigen SPF oder DKIM, gültige Vorwärts- und Rückwärtsauflösung im DNS, TLS, eine standardkonforme Formatierung und eine geringe Quote an Spam-Meldungen. Für Massenversender verlangt Google unter anderem SPF, DKIM, DMARC und den Domain-Abgleich.

Googles FAQ für Absender beschreibt die Einstufung als Massenversender bei etwa 5.000 Nachrichten pro Tag an private Gmail-Konten. Dabei werden Subdomains unter der Hauptdomain zusammengezählt. Laut Google bleibt die einmal erfolgte Einstufung bestehen. Berücksichtigen Sie die relevanten Versandaktivitäten der gesamten Domain, nicht nur die täglichen Nachrichten Ihres Recruiting-Teams. Diese Vorgaben beziehen sich auf private Gmail-Empfänger, nicht auf Empfängerkonten in Google Workspace.

Die Anforderungen von Yahoo verlangen ebenfalls SPF oder DKIM von allen Absendern. Massenversender benötigen beide Verfahren und ein erfolgreiches DMARC-Ergebnis. Yahoo akzeptiert mindestens eine Richtlinie mit p=none und einen gelockerten Domain-Abgleich. Die FAQ nennt bewusst keine zahlenmäßige Schwelle für Massenversand. Googles Zahl ist daher keine Yahoo-Regel.

Ordnen Sie Abmeldeanforderungen der jeweiligen Nachrichtenkategorie zu. Google nimmt Transaktionsnachrichten von der Ein-Klick-Vorgabe aus. Das macht aber nicht jede Nachricht eines Recruiting-Teams zur Transaktionsnachricht. Eine Antwort an einen Bewerber und ein werblicher Recruiting-Newsletter haben unterschiedliche Zwecke. Prüfen Sie die konkrete Nachricht und die Anbietervorgaben.

Für Nachrichten, auf die die Vorgabe zutrifft, verlangt Gmail den POST-Mechanismus aus RFC 8058. Ein mailto-Link allein reicht nicht aus. Yahoo akzeptiert derzeit mailto, empfiehlt aber POST und verlangt eine einfache Abmeldung bei Massenversand von Werbung oder abonnierten Nachrichten. Aus dem gemeinsamen Ausdruck „Ein-Klick“ folgen keine identischen Umsetzungsvorgaben.

Warum können authentifizierte Recruiting-E-Mails trotzdem im Spam landen?

Die Authentifizierung ist ein Faktor der Filterung. Ein Empfänger kann eine authentifizierte Nachricht annehmen und sie dennoch aufgrund von Reputation, Beschwerden, Inhalt oder Empfängereinstellungen als Spam einordnen.

Die Gmail-Richtlinien und die Hinweise von Yahoo behandeln diese weiteren Signale. Ein erfolgreiches Authentifizierungsergebnis garantiert bei keinem der beiden Anbieter den Eingang im Posteingang. Wenn Ihr Test die Authentifizierung besteht, aber im Spam landet, untersuchen Sie das beobachtete Filterergebnis, statt wiederholt korrekte DNS-Einträge zu ersetzen.

Unterscheiden Sie Fehler danach, wo sie auftreten:

Schon vor diesen Beobachtungen beim Empfänger gibt es eine weitere Grenze. Eine erfolgreiche SMTP-Übermittlung bedeutet, dass der annehmende Server für diesen Übertragungsschritt Verantwortung übernimmt. Das beschreibt RFC 5321. Wenn Ihre Anwendung die Nachricht an ihren Versandserver übergibt, ist sie noch nicht im Posteingang des Empfängers angekommen.

Unterscheiden Sie im Team vier Ereignisse: SMTP-Übergabe, beobachtete Ablage beim Empfänger, Lesen und Antworten. Ein Zeitstempel mit der Bedeutung „Gesendet“ belegt die letzten drei nicht. Ebenso wenig weist eine ausbleibende Antwort auf einen Authentifizierungsfehler hin. Sie kann auch an der Entscheidung des Kandidaten oder Ihrer Nachricht liegen.

Was sollten Sie nach einem Anbieterwechsel prüfen?

Wiederholen Sie die betroffenen Prüfungen, wenn Sie Absender, Domain, Signaturkonfiguration oder Terminplanungsintegration ändern. Besprechen Sie die DMARC-Richtlinie und Berichte mit der für die Domain verantwortlichen Person.

DMARC p=none legt keine Präferenz für Quarantäne oder Ablehnung fest. Die Übermittlung aggregierter Berichte wird separat mit einer Zieladresse eingerichtet. Die Veröffentlichung allein verhindert keine gefälschten Absender. Um Berichte zu nutzen, richten Sie ein existierendes Berichtsziel ein und benennen Sie eine Person für die Auswertung. Prüfen Sie außerdem, ob ein externes Ziel autorisiert werden muss. Die DMARC-Regeln für Berichte beschreiben diese externe Autorisierung.

Bevor Sie zu quarantine oder reject wechseln, erfassen Sie berechtigte Absender und untersuchen Sie deren Fehler. Prüfen Sie, ob Mitarbeiter-E-Mails, ATS-Antworten, Terminplanung und andere beibehaltene Dienste mit dem vorgesehenen Domain-Abgleich funktionieren. Stimmen Sie die verschärfte Richtlinie mit der zuständigen Person ab und beobachten Sie die Auswirkungen nach der Umstellung. RFC 9989 definiert die Richtlinien. Empfänger entscheiden weiterhin selbst über die Behandlung.

Planen Sie auch das Entfernen eines Anbieters ausdrücklich. Prüfen Sie, welche SPF-Autorisierung und welcher DKIM-Selektor zum bisherigen Dienst gehörten, behalten Sie die übrigen bei und klären Sie den Eingang älterer Antworten. Kandidatinnen und Kandidaten können auf eine Einladung antworten, die vor Ihrer Umstellung versandt wurde. Ein erfolgreicher Test des neuen Versandwegs belegt nicht, dass dieser ältere Eingangsweg erhalten bleibt.

Wie Kit Ihre Recruiting-Domain und Antworten von Kandidaten behandelt

Eine gehostete Recruiting-Domain braucht eine konfigurierte Absenderidentität und einen zuverlässigen Austausch mit Kandidatinnen und Kandidaten. Prüfen Sie die empfangene Nachricht auch dann, wenn die Einrichtungsseite einen Erfolg meldet.

Die Einrichtung von Startupkit Email zeigt Ihnen MX-, DKIM-, SPF- und DMARC-Einträge für Ihre konfigurierte Domain. Kit erzeugt ein domainspezifisches DKIM-Schlüsselpaar und richtet die Signierung über seinen Mailserver ein. Die vorgeschlagene DMARC-Richtlinie beginnt mit p=none.

Bei erfüllten Voraussetzungen können Nachrichten an Kandidaten Ihr konfiguriertes Recruiting-Postfach für den sichtbaren Absender und den Envelope-Absender verwenden. Der Versand unter Ihrer Adresse erfordert eine aktive Integration, Signaturschlüssel, verifizierte Versandeinträge und eine ausdrückliche Aktivierung. DNS-Prüfung und Bereitstellungsstatus sind getrennt: „Aktiv“ bedeutet, dass der Dienst bereitgestellt ist. Es bedeutet nicht, dass jeder DNS-Eintrag bereits überall verfügbar ist.

Diese Prüfungen haben einen begrenzten Umfang. Kit sucht nach dem erwarteten Schlüsselinhalt, seiner SPF-Autorisierungskennung und einer DMARC-Versionskennung. Es verwendet einen zwischengespeicherten Prüfstatus, den asynchrone DNS-Prüfungen aktualisieren. Das ist weder eine vollständige Auswertung der SPF-Richtlinie noch ein Dashboard zur Analyse von DMARC-Berichten oder eine neue DNS-Abfrage für jede Nachricht.

Kit erfasst Antworten von Kandidaten außerdem im Recruiting-Gespräch. Der Zeitstempel für den erfolgreichen Versand wird gesetzt, nachdem die Anwendung die Nachricht an den SMTP-Transport übergeben hat. Er belegt weder den Eingang im Posteingang des Empfängers noch das Lesen. Ihr eigener Empfangstest zeigt, was nach dieser Übergabe geschieht.

Beginnen Sie mit einer Antwort an einen fiktiven Kandidaten: Senden Sie sie über den konfigurierten Kit-Versandweg und prüfen Sie die empfangenen Authentifizierungsergebnisse. Antworten Sie darauf und prüfen Sie den Eingang in der Bewerbung. Ergänzen Sie dann die Prüfungen für Mitarbeiterpostfach und Terminplanungsdienst. Wenn Sie Kit für Ihr Recruiting prüfen, lässt sich diese Aufgabe gut in Ihre Testphase aufnehmen. Benennen Sie eine verantwortliche Person, die die Ergebnisse aktuell hält.