Sophos Email: Absenderauthentifizierung und Smart Banners konfigurieren

Sophos Email prüft eingehende Nachrichten mit DMARC, SPF und DKIM und kann zusätzlich Header- und Domain-Anomalien erkennen. Die Prüfungen allein entscheiden jedoch nicht über die Behandlung: In der passenden Email Security Policy legt man Failure-Typen, Reihenfolge und Aktionen fest. Smart Banners machen das Ergebnis für Empfänger sichtbar und können sichere Benutzeraktionen anbieten.

Empfohlener Schnellweg: Unter My Products > Email Security > Policies die betroffene Email Security Policy öffnen und unter Settings > Inbound > Authentication die Failure-Aktionen für DMARC, SPF und DKIM konfigurieren. Kritische Fehler zunächst auf Quarantine statt sofort auf Reject setzen, Bedingungen von oben nach unten ordnen und anschliessend Header anomaly, Domain anomaly sowie End-user message settings prüfen. Danach legitime und fehlerhafte Testnachrichten in Message History vergleichen, bevor man Ausnahmen zulässt oder schärfere Aktionen aktiviert.

Scope, Test und Rückweg vorbereiten

Vor der Änderung benötigt man geschützte Domains und Mailboxen, bekannte legitime Versanddienste und eine begrenzte Testgruppe. Man dokumentiert:

• die betroffene Policy, ihre Position und ob sie Enforced ist;
• die Richtung Inbound sowie zugewiesene Benutzer, Gruppen und Domains;
• aktuelle DMARC-, SPF-, DKIM- und Sender-check-Regeln in ihrer Reihenfolge;
• bestehende Allow-Einträge und geschäftlich begründete Ausnahmen;
• ursprüngliche Aktionen, Bannertexte und End-user-Optionen;
• Testsender, Testempfänger und erwartete Resultate.

Der Rückweg besteht darin, die vorher dokumentierte Regelreihenfolge, Aktionen und Banneroptionen wiederherzustellen oder eine neue Pilot-Policy auf Policy Bypassed zu setzen. Man ändert im Pilot nur einen zusammenhängenden Regelbereich, damit sich ein unerwartetes Ergebnis eindeutig zuordnen lässt.

Warnung: Eine Authentifizierungsausnahme darf niemals als Grund verwendet werden, den Malware-Scan zu deaktivieren. Auch ein erlaubter oder korrekt authentifizierter Absender kann ein kompromittiertes Konto verwenden oder schädliche Inhalte senden. Eine Ausnahme wird deshalb auf den belegten Authentifizierungsfehler und den kleinsten nötigen Scope begrenzt; die übrigen Schutzprüfungen bleiben aktiv.

DMARC, SPF und DKIM richtig einordnen

Diese drei Verfahren beantworten unterschiedliche Fragen:

• SPF vergleicht den sendenden Mailserver mit den Hosts, IP-Adressen und Netzen, die der Besitzer der Envelope-from-Domain in DNS autorisiert hat.
• DKIM validiert die digitale Signatur einer Nachricht mit dem im DNS der signierenden Domain veröffentlichten öffentlichen Schlüssel.
• DMARC bewertet, ob SPF oder DKIM erfolgreich ist und die dabei verwendete Domain mit der sichtbaren Domain im From-Header ausgerichtet ist. Ohne gültigen DMARC-Record und eine auswertbare SPF- oder DKIM-Prüfung kann Sophos DMARC nicht vollständig bewerten.

Der in der Policy sichtbare Schalter steuert die Aktion bei einem Fehlschlag; die Authentifizierungsprüfungen selbst werden immer ausgeführt. Dieser Artikel betrifft nur die Auswertung eingehender Nachrichten. Er erstellt oder hostet keine DNS-Records für eigene ausgehende Domains und aktiviert keine ausgehende DKIM-Signatur.

Message Authentication konfigurieren

1. Öffne My Products > Email Security > Policies, wähle die richtige Email Security Policy und kontrolliere Zielgruppe und Position.
2. Öffne Settings > Inbound > Authentication.
3. Aktiviere die gewünschten Failure-Aktionen für DMARC, SPF und DKIM.
4. Klicke bei der jeweiligen Prüfung auf Add Rule, wähle einen Failure-Typ und die zugehörige Aktion.
5. Ordne mehrere Bedingungen vom spezifischen zum allgemeineren Fall. Sophos prüft sie von oben nach unten und verwendet den ersten Treffer.
6. Speichere die Policy und kontrolliere, dass sie für die Testempfänger Enforced ist.

Sophos empfiehlt Quarantine für jede Message-Authentication-Kategorie. Das ist auch für einen Pilot sinnvoll, weil eine Nachricht für Analyse und kontrollierte Freigabe erhalten bleibt. Reject weist sie bereits während der Verarbeitung zurück; für abgewiesene Nachrichten stehen keine Raw Headers in Sophos zur Verfügung. Tag subject line markiert und übergibt die Nachricht an die weitere Verarbeitung. Deliver bedeutet ebenfalls nur Übergabe an die nächste Scan-Stufe, nicht automatisch Zustellung an die Mailbox. Mit Include In End User Quarantine kann eine quarantänisierte Nachricht für die Benutzerquarantäne vorgesehen werden.

Failure-Typen bewusst abstufen

Bei DMARC ist Hard failure der Fall, in dem weder SPF noch DKIM mit Alignment besteht. Standardmässig ist dafür Conform to sender policy eingestellt: Die Aktion richtet sich nach der DMARC-Policy des Absenders. Weitere auswählbare Fälle sind p=none, Unsupported, Temporary failure und Permanent failure. Unsupported gilt hier nur für Gateway mode, M365 bestguesspass nur für M365 Mailflow mode. Eine eigene Regel für p=none ist vor allem dann relevant, wenn Hard failure weiterhin auf Conform to sender policy steht.

Bei SPF stehen neben Hard failure die Fälle Soft failure, Neutral, Unsupported, Temporary failure und Permanent failure zur Verfügung. Bei DKIM sind es neben Hard failure Unsupported, Temporary failure und Permanent failure. Ein temporärer DNS-Fehler kann sich ohne Eingriff auflösen; ein permanenter Fehler weist auf einen nicht interpretierbaren veröffentlichten Record hin. Man behandelt solche Resultate nicht automatisch wie einen belegten Spoofing-Versuch.

Verarbeitungsreihenfolge und Sender check

Die Message-Authentication-Prüfungen laufen in der Reihenfolge, in der sie in der Policy stehen. Für eine DMARC-Auswertung führt Sophos die nötigen SPF- und DKIM-Prüfungen unabhängig von deren konfigurierten Failure-Aktionen aus. Besteht weder SPF noch DKIM mit dem nötigen Alignment, schlägt DMARC fehl. Bei mehreren Failure-Regeln gilt immer der erste Treffer von oben.

Wenn eine DMARC-, SPF- oder DKIM-Regel mit Quarantine oder Reject trifft, endet die Verarbeitung dieses Zweigs. Bestehen alle drei Prüfungen in einer Konfiguration mit diesen Aktionen, werden Header-Anomalien nicht weiter verarbeitet und die Nachricht wird zugestellt. Die Reihenfolge ist deshalb Teil der Sicherheitswirkung und keine reine Darstellung im Portal.

Unter Sender check ergänzt Sophos zwei Anomalieprüfungen:

• Header anomaly schützt vor externem Spoofing eigener Domains. Sie löst nur aus, wenn die Domain im sichtbaren From-Header einer beliebigen im Sophos-Central-Konto konfigurierten Domain entspricht und diese Header-Adresse von der MAIL FROM-Adresse im SMTP-Envelope abweicht. Geprüft werden alle Domains des Kontos, nicht nur die Domain des Empfängers.
• Domain anomaly erkennt Absenderdomains, für die weder ein MX- noch ein A-Record vorhanden ist.

Für beide Prüfungen kann man Tag subject line, Quarantine, Reject oder Deliver wählen; Tag subject line ist der dokumentierte Standard. In einem Pilot verwendet man Tagging oder Quarantäne und kontrolliert legitime Weiterleitungen, CRM-Systeme, Ticketplattformen und externe Versanddienste, bevor man Reject aktiviert.

Smart Banners konfigurieren

Unter End-user message settings schaltet man die Bannerarten einzeln ein, passt den vordefinierten Text an und wählt angebotene Benutzeraktionen. Die Einstellungen gelten für eingehende externe HTML- und Plain-Text-Nachrichten. Sophos-Nachrichten wie Quarantäne-Zusammenfassungen erhalten keinen Smart Banner.

Die Bannerfarbe und Aussage beruhen auf Allow-List und DMARC-Ergebnis:

• Trusted ist grün: Der Absender steht auf der Allow-Liste und die Nachricht hat DMARC bestanden.
• External ist gelb: Der Absender hat DMARC bestanden, steht aber nicht auf der Allow-Liste; oder er steht auf der Allow-Liste und Trusted ist ausgeschaltet; oder der Absender hat keinen DMARC-Record, sodass kein Pass/Fail bewertet werden kann.
• Untrusted ist orange: Eine DMARC-Policy ist vorhanden, aber die Nachricht hat DMARC nicht bestanden.

Ein Banner ist eine Entscheidungshilfe, kein Beweis für Harmlosigkeit. Auch ein grüner Banner ersetzt weder Inhaltsprüfung noch Aufmerksamkeit beim Öffnen von Links und Anhängen.

Aktionen für Benutzer sicher freigeben

Je Banner kann man Allow sender, Block sender und Report Spam messages to Sophos anbieten. Allow und Block öffnen eine Bestätigungsseite und pflegen die persönliche Liste des Benutzers; Report übermittelt die Nachricht als Spam an SophosLabs.

Wie persönliche und globale Einträge zusammenwirken und wie man sie mit Authentifizierung, Export, Import und Rücknahme absichert, beschreibt die Anleitung zu Inbound Allow/Block-Ausnahmen.

Damit Allow sender und Block sender im HTML-Banner funktionieren, öffnet man das Symbol Global Settings > Products and Services > Email > User Settings, aktiviert zuerst Release/Delete, danach Allow/Block List, und speichert. In Plain-Text-Bannern stehen Allow- und Block-Links nicht zur Verfügung.

Ausgehende E-Mails müssen durch Sophos Fusion (ehemals Sophos Central) geroutet werden, wenn Links in Smart Banners verwendet werden sollen. Sophos empfiehlt dieses Routing bereits vor dem Einschalten der End-user message settings; andernfalls können externe Empfänger den Banner in Antworten oder weitergeleiteten Nachrichten sehen. In HTML steht er farbig am Anfang, in Plain Text als Text am Anfang des Bodys. Bei einer internen Antwort oder Weiterleitung kann ein vorhandener Banner sichtbar bleiben.

Wirkung in Message History validieren

Für jeden relevanten Policy-Scope sendet man kontrollierte eingehende Nachrichten an einen Pilotempfänger:

1. eine legitime Nachricht mit erwartbar erfolgreicher Authentifizierung;
2. eine legitime Nachricht über einen bekannten Weiterleitungs- oder Versanddienst;
3. soweit sicher verfügbar, eine Testnachricht aus einer eigenen Testdomain mit bewusst dokumentiertem Authentifizierungsfehler.

Man erzeugt keine gefälschte Produktionsmail und verändert keine fremden DNS-Records zum Test. In Message History sucht man nach Absender, Empfänger und Zeitfenster, öffnet die Nachricht und vergleicht angewendete Policy, Kategorie, Authentifizierungs- beziehungsweise Sender-check-Details und tatsächliche Aktion. Bei zugestellten Nachrichten kontrolliert man zusätzlich Typ, Text, Farbe und sichtbare Aktionen des Banners in HTML und Plain Text. Erfolg bedeutet, dass gute Nachrichten die erwartete nächste Scan-Stufe beziehungsweise Mailbox erreichen, Fehler die konfigurierte erste passende Aktion auslösen und keine unerwarteten Benutzeraktionen erscheinen.

Fehler systematisch eingrenzen

• Unerwarteter DMARC- oder DKIM-Fehler: Raw Headers und Sender-check-Details sichern. Prüfen, ob ein vorgeschaltetes Gateway, Disclaimer, eine Mailingliste oder Weiterleitung Body beziehungsweise signierte Header verändert hat. Besonders bei Sophos EMS hinter einem anderen primären E-Mail-Security-System können modifizierte Nachrichten DKIM und DMARC-Alignment brechen; ein Fehlschlag allein beweist dann keine Gefahr.
• Falsche Aktion trotz passender Regel: Zuerst Policy-Scope, Enforcement und Policy-Reihenfolge prüfen, danach die Failure-Regeln von oben nach unten. Ein früher allgemeiner Treffer kann eine spätere spezifische Regel verdecken.
• Header anomaly bei legitimem Dienst: Sichtbaren From-Header und MAIL FROM im Envelope vergleichen und prüfen, welche eigene Domain getroffen hat. Erst Versandkonfiguration oder Alignment korrigieren; nur wenn das nicht möglich und der Dienst eindeutig belegt ist, eine enge Authentifizierungsausnahme erwägen.
• Domain anomaly bei legitimer Mail: MX- und A-Auflösung der Absenderdomain getrennt prüfen. Temporäre DNS-Probleme nicht mit einer dauerhaften globalen Allow-Regel beantworten.
• Banner fehlt: Prüfen, ob die richtige Policy und Bannerart aktiv sind, die Nachricht extern und eingehend war und ob es sich nicht um eine Sophos-Systemnachricht handelt.
• Allow/Block fehlt oder funktioniert nicht: Release/Delete und Allow/Block List in User Settings, HTML-Format und ausgehendes Routing durch Sophos kontrollieren. Plain Text bietet diese Links nicht.

Erst nach dieser Eingrenzung korrigiert man Reihenfolge, Aktion oder den engsten nötigen Allow-Eintrag und wiederholt denselben Test. Bleibt das Resultat unklar, sammelt man Message-ID, Zeitstempel, Absender, Empfänger, Policy-Name, tatsächliche Aktion und die vollständigen Raw Headers für die Eskalation, statt Authentifizierung oder Malware-Schutz pauschal zu umgehen.