ARC und Secure Email Gateways: indirekte Mailwege und vorgeschaltete Filter einordnen

Worum es geht und für wen es wichtig ist

Beide Themen betreffen denselben Punkt im Mailweg: Eine Station nimmt eine Nachricht an und gibt sie weiter, oft verändert. Welche Frage Sie beantworten müssen, hängt von Ihrer Rolle ab.

„Secure Email Gateway“ ist eine Produktbezeichnung, kein Begriff aus den Mailstandards. In der Architektur der Internet-Mail nach RFC 5598 entspricht ein Filter vor dem Postfach einer weiterleitenden Station mit der Aufgabe eines Grenzfilters (Boundary Filter), der Inhalte prüft und gegebenenfalls verändert. Ein „Gateway“ im Sinne von RFC 5598 ist dagegen ein Übergang zwischen verschiedenartigen Mailsystemen. Wenn dieses Kapitel von einem Gateway spricht, ist der vorgeschaltete Filter gemeint.

ARC: Prüfergebnisse über Zwischenstationen weiterreichen

Eine Weiterleitung verschickt die Nachricht neu. Behält die weiterleitende Station den ursprünglichen Envelope-Absender bei, scheitert SPF in der Regel, weil ihre Adresse nicht zum SPF-Record der Absenderdomain gehört. Schreibt sie den Envelope-Absender auf ihre eigene Domain um, kann SPF bestehen, ist aber nicht mehr zur sichtbaren Absenderdomain ausgerichtet. Für DMARC bleibt dann nur eine gültige, ausgerichtete DKIM-Signatur. RFC 7960, Abschnitt 2.2

DKIM übersteht eine reine Umleitung häufig, weil die signierten Bestandteile unverändert bleiben. Mailinglisten und Filter verändern Nachrichten aber oft: Sie setzen einen Betreff-Präfix, hängen eine Fußzeile an, bauen MIME-Teile um oder ersetzen Links. Das macht die ursprüngliche DKIM-Signatur ungültig. Fehlt danach ein ausgerichteter SPF- oder DKIM-Pass, schlägt DMARC fehl. RFC 6376, Anhang B.2, RFC 7960, Abschnitte 2.3 und 3.2.3, DMARC-Alignment

Hier setzt ARC an. Jede teilnehmende Zwischenstation fügt ein ARC-Set aus drei Kopfzeilen mit derselben Instanznummer i= hinzu; die Nummern beginnen bei 1 und dürfen bis 50 reichen. RFC 8617, Abschnitte 4.1 bis 4.2

Quellen: RFC 8617, Abschnitte 3.4, 4.1.1 bis 4.1.3 und 4.4.

Das erste Set trägt cv=none. Spätere Sets tragen cv=pass, wenn die Station die vorhandene Kette gültig vorgefunden hat. Findet eine Station eine ungültige Kette vor, versiegelt sie mit cv=fail; weitere Stationen setzen eine solche Kette nicht fort. Ein Prüfer (Validator) kontrolliert, ob jedes Set vollständig ist, ob die Nummern lückenlos von 1 bis N laufen und ob die cv-Werte dazu passen. Anschließend prüft er die jüngste Nachrichtensignatur und alle Seals kryptografisch. Sein Ergebnis soll er als arc=pass, arc=fail oder arc=none in sein eigenes Authentication-Results schreiben. Eine Kette mit dem Ergebnis fail muss er so behandeln wie eine Nachricht ohne Kette; auch DNS-Fehler beim Schlüsselabruf gelten dabei als endgültiger Fehler. RFC 8617, Abschnitte 5.1 bis 5.2.1

Eine gültige Kette bindet die signierten Angaben an die versiegelnden Domains. Eine Station erklärt damit, welchen Nachrichtenzustand sie weitergibt, welches Eingangsergebnis sie festgestellt haben will und welche früheren Sets sie vorgefunden hat. Sie kann trotzdem falsche Eingangsergebnisse behaupten; die Signatur macht diese Behauptung nicht wahr. ARC authentifiziert damit die Identität einiger beteiligter Stationen, bewertet aber nicht ihre Vertrauenswürdigkeit. Eine gültige Kette ist weder ein Zeichen für ungefährliche Inhalte noch für eine Zustellung. Die Spezifikation nennt ARC ausdrücklich kein Vertrauensrahmenwerk. RFC 8617, Abschnitte 9 bis 9.4 und Anhang A.2

ARC-Kopfzeilen und Authentication-Results lesen

Das folgende gekürzte Beispiel gehört zur Situation aus der Abbildung. Received-Felder sind weggelassen, Signaturwerte sind Platzhalter. Domains und Adresse stammen aus den für Dokumentation reservierten Bereichen; mx.example.org wird nur für die Erklärung als eigenes, vertrauenswürdiges Empfangssystem angenommen.

Authentication-Results: mx.example.org;
  spf=pass smtp.mailfrom=team-bounces@lists.example.net;
  dkim=fail (body hash did not verify) header.d=example.com header.s=sel2026;
  dkim=pass header.d=lists.example.net header.s=list2026;
  dmarc=fail header.from=example.com;
  arc=pass header.oldest-pass=0 smtp.remote-ip=198.51.100.25
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=lists.example.net; s=arc2026;
  t=1790000000; b=PLATZHALTER
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
  d=lists.example.net; s=arc2026; t=1790000000;
  h=from:to:subject:date:message-id:dkim-signature;
  bh=PLATZHALTER; b=PLATZHALTER
ARC-Authentication-Results: i=1; lists.example.net;
  spf=pass smtp.mailfrom=alice@example.com;
  dkim=pass header.d=example.com header.s=sel2026;
  dmarc=pass header.from=example.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lists.example.net;
  s=list2026; h=from:to:subject:date:message-id; bh=PLATZHALTER;
  b=PLATZHALTER
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;
  s=sel2026; h=from:to:subject:date:message-id; bh=PLATZHALTER;
  b=PLATZHALTER
From: Alice <alice@example.com>
To: team@lists.example.net
Subject: [Team] Protokoll der Sitzung
Date: Mon, 21 Sep 2026 16:12:05 +0200
Message-ID: <protokoll-0921@example.com>

So lesen Sie den Ausschnitt in einer sinnvollen Reihenfolge:

1. Das eigene Prüfergebnis zuerst. Belastbar ist nur ein Authentication-Results, das Ihr eigenes Empfangssystem innerhalb Ihrer Vertrauensgrenze hinzugefügt hat; Sie erkennen es an der Kennung des Prüfdienstes (hier mx.example.org). Ein konformes System muss gleichnamige Felder entfernen, die von außen kommen und fälschlich Ihre Kennung tragen. Bei mehreren Feldern entscheidet deshalb nicht die Position allein. RFC 8601, Abschnitte 1.2 und 5
2. Die Einzelergebnisse. spf=pass gilt hier für die Domain der Liste, nicht für example.com, und ist nicht ausgerichtet. Die Signatur von example.com ist nach den Änderungen der Liste ungültig. Die gültige Signatur von lists.example.net ist ebenfalls nicht ausgerichtet. Daraus folgt dmarc=fail.
3. Das ARC-Ergebnis Ihres Systems. arc=pass heißt: Ihr System hat die Kette strukturell und kryptografisch als gültig befunden. Wer versiegelt hat, steht im d= des ARC-Seal. i=1 mit cv=none zeigt, dass die Liste die erste und einzige teilnehmende Station ist. header.oldest-pass=0 bedeutet, dass auch alle älteren Nachrichtensignaturen der Kette noch gültig waren.
4. Die Aussage der Station. Das AAR mit i=1 meldet, dass die Nachricht beim Eingang in die Liste SPF, DKIM und DMARC für example.com bestanden hat. Das ist eine Angabe von lists.example.net, keine Prüfung Ihres Systems.
5. Die Entscheidung. Ob diese Angabe zählt, entscheidet die lokale Policy des Empfängers. Nur wenn er dem Sealer vertraut, darf er den DMARC-Fehlschlag deshalb anders behandeln. RFC 8617, Abschnitt 7.2.1

Quellen: RFC 8617, Abschnitte 4.4, 5.2 und 6.

Anbieter notieren zusätzliche Angaben unterschiedlich. Microsoft beschreibt für Microsoft 365: Wird ein vertrauenswürdiger Sealer anerkannt, steht im letzten ARC-Authentication-Results neben arc=pass der Wert oda=1; compauth=pass reason=130 im Authentication-Results zeigt, dass das ARC-Ergebnis einen DMARC-Fehlschlag übersteuert hat. Das sind Microsoft-eigene Kennzeichen, keine allgemeine Notation. Microsoft Learn: Configure trusted ARC sealers

Wenn Sie eine Nachricht als .eml-Datei gespeichert haben, listet dieses kleine Python-Skript die relevanten Felder in ihrer Reihenfolge auf. Es liest nur und prüft keine Signatur; die Positionsnummer zeigt, welches Feld weiter oben steht.

# Listet Authentication-Results und ARC-Kopfzeilen einer gespeicherten
# Nachricht in ihrer Reihenfolge auf. Liest nur; prüft keine Signatur.
import sys
from email import policy
from email.parser import BytesParser

FIELD_NAMES = {"authentication-results", "arc-seal",
         "arc-message-signature", "arc-authentication-results"}

with open(sys.argv[1], "rb") as source:
    message = BytesParser(policy=policy.default).parse(source, headersonly=True)

for position, (name, value) in enumerate(message.items(), start=1):
    if name.lower() in FIELD_NAMES:
        print(f"{position:>3}  {name}: {' '.join(str(value).split())}")

Aufruf: python3 arc-felder.py nachricht.eml. Das Skript wurde nur mit eigenen synthetischen Dateien getestet. Eine kryptografische ARC-Prüfung braucht einen ARC-fähigen Prüfer; das Lesen der Felder ersetzt sie nicht.

ARC ist eine Vertrauensentscheidung des Empfängers

Die Spezifikation erlaubt Empfängern, ARC-Ergebnisse in ihre lokale Entscheidung einzubeziehen; sie verlangt es nicht. Wörtlich: Ein DMARC-Prüfer „MAY choose to accept the authentication assessments provided by an Authenticated Received Chain“ – als Frage der lokalen Policy. Zugleich sollen Empfänger jeden Sealer mit Vorsicht behandeln, damit Angreifer nicht eigene Spam- oder Betrugsnachrichten versiegeln, um deren Zustellung zu erleichtern. RFC 8617, Abschnitte 7.2.1 und 9.4

DMARC selbst lässt die endgültige Behandlung jeder Nachricht beim Empfänger. RFC 9989 formuliert für p=reject: „Mail Receivers MUST NOT reject incoming messages solely on the basis of a "p=reject" policy by the sending domain.“ Fehlen weitere Erkenntnisse, müssen Empfänger solche Fehlschläge wie p=quarantine behandeln. Weicht ein Empfänger von der veröffentlichten Policy ab, soll er Tatsache und Grund im Aggregatbericht angeben. RFC 9989, Abschnitte 5.3.6, 5.4 und 7.4

Wie Empfänger ARC tatsächlich verwerten, ist deshalb unterschiedlich und nur dort belegt, wo sie es dokumentieren:

Quellen: Microsoft Learn: Configure trusted ARC sealers, Rspamd: ARC module, Gmail: Authentifizierung prüfen, Gmail: Best practices for forwarding email to Gmail, Gmail: Email sender guidelines, RFC 9989, Abschnitt 7.4.

In DMARC-Aggregatberichten sehen Sie eine solche Ausnahme nicht an den Ergebnisfeldern für DKIM und SPF: Sie müssen die für DMARC ausgewerteten Werte zeigen, nicht die Werte, mit denen der Empfänger übersteuert hat. Ist das Alignment gescheitert und weicht die angewandte Behandlung von der veröffentlichten Policy ab, muss der Bericht ein reason-Element enthalten. Zulässige Typen sind local_policy, mailing_list, trusted_forwarder, policy_test_mode und other; RFC 8617 schlägt für ARC-bedingte Ausnahmen local_policy mit einem Kommentar zu den Sealern vor. Ein Kommentar ist Freitext und kann fehlen. RFC 9990, Abschnitte 3.1.1.9 und 3.1.6, RFC 8617, Abschnitt 7.2.2

<record>
  <row>
    <source_ip>198.51.100.25</source_ip>
    <count>3</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
      <reason>
        <type>local_policy</type>
        <comment>arc=pass as[1].d=lists.example.net as[1].s=arc2026</comment>
      </reason>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>example.com</domain>
      <selector>sel2026</selector>
      <result>fail</result>
    </dkim>
    <dkim>
      <domain>lists.example.net</domain>
      <selector>list2026</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>lists.example.net</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Der erfundene Ausschnitt gehört zu einem Bericht über example.com mit p=reject. Er zeigt drei Nachrichten der Liste, die der Empfänger trotz DMARC-Fehlschlag angenommen hat (disposition none), und nennt als Grund seine lokale Policy. In einen vollständigen synthetischen Bericht eingebettet, ließ er sich lokal gegen das XML-Schema aus RFC 9990 prüfen. Er ist kein echter Bericht. Wie Sie Aggregatberichte insgesamt auswerten, erklärt das DMARC-Kapitel.

Standardstand: Experimental, Historic-Vorschlag und DKIM2

• RFC 8617 wurde im Juli 2019 veröffentlicht. Er ist ausdrücklich kein Standards-Track-Dokument, sondern „published for examination, experimental implementation, and evaluation“. Die Erratensuche zeigt die technischen Meldungen 7910 (Whitespace-Grammatik) und 8357 (fehlende SMTP-Referenz), beide nur „Reported“. Sie werden nicht als beschlossene Normkorrekturen übernommen. RFC 8617, Datatracker
• draft-ietf-dmarc-arc-to-historic-00 ist seit dem 22. April 2026 ein Dokument der DMARC-Arbeitsgruppe, bislang nur in dieser ersten Revision. Der Datatracker zeigt keinen weiteren Verfahrensschritt; ohne neue Revision läuft der Entwurf am 24. Oktober 2026 aus. Er erklärt das Experiment für beendet: Betreiber sollen sich künftig nicht auf ARC verlassen, keine weiteren Internet-weiten Einsätze aufbauen und bestehende Einsätze zurückbauen oder auf kontrollierte Umgebungen mit zweiseitiger Absprache beschränken. RFC 8617 soll als „Historic“ markiert werden. Als Kernlehre nennt der Entwurf, dass Signaturen kein Vertrauen schaffen: Ohne belastbare Reputation für jede Zwischenstation lässt sich DMARC nicht sicher übersteuern. Datatracker: draft-ietf-dmarc-arc-to-historic
• RFC 9989 vom Mai 2026 nennt ARC als bekanntestes Beispiel für Versuche, Mailinglisten ohne Umschreiben des From-Felds DMARC-tauglich zu machen, und hält fest, dass keiner dieser Ansätze breit genutzt wird. RFC 9989, Abschnitt 7.4
• DKIM2 wird in der DKIM-Arbeitsgruppe entwickelt. Aktive Arbeitsgruppenentwürfe sind draft-ietf-dkim-dkim2-spec-06 vom 28. August 2026, draft-ietf-dkim-dkim2-dns-00 vom 20. Juli 2026 und draft-ietf-dkim-dkim2-bcp-01 vom 9. September 2026; der Motivationsentwurf ist abgelaufen. Es gibt keinen RFC und keinen zugesagten Zeitplan, also noch keinen verabschiedeten Standard als fertigen Ersatz. Datatracker: DKIM-Arbeitsgruppe

Was daraus für Ihre Entscheidung folgt, ist eine Einordnung, keine Normaussage:

Weiterleitungen und Mailinglisten: was tatsächlich hilft

Für Domains mit p=reject verlangt RFC 9989: Sie „MUST NOT rely solely on SPF to secure a DMARC pass and MUST apply valid DKIM signatures to their messages“. Grund ist gerade die Weiterleitung, bei der SPF scheitert, DKIM aber meist erhalten bleibt. Für Domains, deren Nutzer an Mailinglisten teilnehmen, rät der RFC von p=reject ab. Wie Sie eine strengere Policy dennoch schrittweise einführen, beschreibt das Kapitel DMARC-Enforcement. RFC 9989, Abschnitt 7.4

Quellen: RFC 7208, Anhang D, RFC 7960, Abschnitte 2.2 und 4.1.3, RFC 6376, Anhang B.2, RFC 9989, Abschnitt 7.4, Gmail: Best practices for forwarding email to Gmail.

Aliasdienste, Hochschul- oder Verbandsadressen haben meist keine Beziehung zur Absenderdomain. Lösungen dürfen deshalb nicht voraussetzen, dass jeder Absender jede weiterleitende Stelle kennt oder in seinen SPF-Record aufnimmt. RFC 7960, Abschnitt 3.2.1

Secure Email Gateway: ein Filter im Mailweg

Ein Secure Email Gateway prüft die Nachrichten, die tatsächlich durch es geleitet werden. Je nach Produkt, Lizenz und Konfiguration gehören dazu Spam- und Schadsoftwareprüfung, Link- und Anhangsanalyse, Quarantäne und Regeln für ausgehende Nachrichten. SPF, DKIM und DMARC prüfen dagegen die Autorisierung und Ausrichtung von Domains, nicht die Identität einer Person oder die Unbedenklichkeit von Inhalten. Beide Aufgaben ergänzen sich.

Filter werden unterschiedlich eingebunden:

• Vor dem Postfachdienst: Die MX-Records zeigen auf das Gateway, das Nachrichten nach der Prüfung an den Postfachdienst weitergibt. Diese Bauart behandelt der nächste Abschnitt im Detail.
• Hinter dem Postfachdienst: Die MX-Records zeigen weiter auf den Postfachdienst, der eingehende Nachrichten zum Filter und zurück leitet. Microsoft beschreibt diese Bauart als eigenes Szenario mit eigenen Herausforderungen. Microsoft Learn: Mail flow with a third-party cloud service
• Über eine Programmierschnittstelle: Manche Produkte greifen nach der Zustellung auf Postfächer zu. Sie verändern keine MX-Records und sind im DNS nicht erkennbar.
• Integriert: Große Postfachdienste bringen eigene Filterfunktionen mit, deren Umfang von Tarif und Einstellungen abhängt.

Quellen für die Änderungsfolgen: RFC 8617, Abschnitt 7.1.1, RFC 7960, Abschnitt 3.2.5.

Gateway vor dem Postfach: Mailfluss, Umgehung und Authentifizierung

Mit einem vorgeschalteten Gateway ändert sich, wer Nachrichten aus dem Internet annimmt und wo Authentifizierung sinnvoll geprüft werden kann. Die folgenden Punkte gelten unabhängig vom Anbieter; wo ein Hersteller konkrete Einstellungen dokumentiert, ist er genannt.

MX-Umstellung und Übergang

Die MX-Records der Domain zeigen auf das Gateway; das Gateway kennt die angenommenen Domains und liefert an den Postfachdienst weiter. Planen Sie die Umstellung mit beiden Betreibern und halten Sie den bisherigen Empfang bereit, bis der neue Weg nachweislich funktioniert. Veröffentlichen Sie MTA-STS, müssen die mx-Einträge Ihrer Policy die Gateway-Hosts abdecken, und die alte Policy soll während des Übergangs weiter funktionieren. Ein Backup-MX muss dieselben Filter durchsetzen, weil jeder veröffentlichte MX direkt angesprochen werden kann. RFC 8461, Abschnitte 4.1 und 8.1, MTA-STS einführen, MX-Infrastruktur

Verwenden Sie DANE auf dem Weg zum Postfachdienst, muss das Gateway die Prüfung unterstützen. Microsoft weist für Exchange Online ausdrücklich darauf hin, dass eingehendes SMTP-DANE mit DNSSEC bei einem Drittanbieter-Gateway nur den Weg vom Gateway zu Exchange Online schützt, wenn das Gateway die DANE-Prüfung beherrscht. Dort gibt es seitdem auch MX-Namen auf mx.microsoft neben dem älteren mail.protection.outlook.com. Microsoft Learn: How SMTP DANE secures email

Direktzustellung am Gateway vorbei verhindern

Der Empfangsserver des Postfachdienstes bleibt aus dem Internet erreichbar, und sein Name ist oft ableitbar. Bei Microsoft 365 folgt er etwa dem Muster <Domain>-com.mail.protection.outlook.com. Nimmt der Postfachdienst Nachrichten von beliebigen Absendern an, können Angreifer das Gateway umgehen und direkt dort einliefern. Microsoft Learn: Direct Send und SMTP-Relay

• Microsoft 365: Microsoft empfiehlt, die Organisation so abzusichern, dass sie nur Nachrichten vom Drittanbieterdienst annimmt: über einen eingehenden Partner-Connector, der an das Zertifikat (bevorzugt) oder die IP-Adressen des Gateways gebunden ist. Direkt eingelieferte Nachrichten werden dann abgelehnt. Die Einstellung RejectDirectSend wirkt enger: Sie weist anonyme Nachrichten mit einer eigenen akzeptierten Domain im Envelope-Absender ab, die zu keinem Connector passen. Microsoft Learn: Mail flow with a third-party cloud service, Microsoft Learn: Set-OrganizationConfig
• Google Workspace: Die Einstellung „Reject all mail not from gateway IPs“ beschränkt den Empfang auf die eingetragenen öffentlichen Gateway-Adressen; „Require TLS for connections“ verlangt TLS für diesen Weg. Google weist zugleich ausdrücklich darauf hin, dass Gmail die DMARC-Policy des Absenders für über das konfigurierte Inbound-Gateway eintreffende Nachrichten nicht durchsetzt. Authentifizierungsdaten fließen weiterhin in die Spam- und Phishingbewertung ein. Diese Entscheidung muss zur Prüfung auf Ihrem Gateway passen. Google: Inbound mail gateway
• Eigener Server: Beschränken Sie die Annahme auf Port 25 für die betroffenen Domains auf die Adressen des Gateways, per Firewall oder MTA-Regel.

Alte Relay- und Weiterleitungsfreigaben am Gateway sowie verwaiste DNS-Verweise sind eine verwandte Angriffsfläche; der Abschnitt Echospoofing und SubdoMailing ordnet sie ein.

Authentifizierung an der Grenze prüfen

Hinter dem Gateway sieht der Postfachdienst die IP-Adresse des Gateways als Quelle der SMTP-Verbindung; die Absenderfelder der Nachricht sind davon getrennt. Microsoft beschreibt das so: Die Nachricht übernimmt die Quelladresse der letzten Station vor Microsoft 365; das sei keine Einschränkung von Microsoft 365, sondern die Arbeitsweise von SMTP. Eine SPF-Prüfung gegen diese Adresse sagt über den ursprünglichen Absender nichts aus. RFC 7208 sieht die Prüfung deshalb an den Grenz-MTAs vor, einschließlich aller sekundären MX; an anderer Stelle liefert sie laut RFC wahrscheinlich unzuverlässige Ergebnisse. Microsoft Learn: Enhanced Filtering for Connectors, RFC 7208, Anhang F

Verändert das Gateway Nachrichten – Banner, Link-Umschreibung, entfernte Anhänge –, scheitert danach zusätzlich die ursprüngliche DKIM-Signatur. Ohne Gegenmaßnahme kann der Postfachdienst legitime Nachrichten deshalb als DMARC-Fehlschlag oder Fälschung einstufen. Dafür gibt es zwei dokumentierte Wege:

• Ergebnis des Gateways weitergeben: Das Gateway prüft SPF, DKIM und DMARC, bevor es etwas verändert, und versiegelt die Nachricht mit ARC. Der Postfachdienst vertraut diesem Siegel, bei Microsoft 365 über den Eintrag als vertrauenswürdiger ARC-Sealer. Genau diesen Einsatz beschreibt RFC 8617 für Prüfdienste, die MX-Records auf sich umleiten lassen. RFC 8617, Abschnitt 7.1.1
• Die Gateway-Adresse überspringen: Microsoft 365 bietet dafür „Enhanced Filtering for Connectors“ (auch Skip Listing). Die Funktion bewahrt nach Microsoft-Angaben die ursprüngliche Quelladresse und gleicht DKIM-Fehler durch Veränderungen aus. Microsoft empfiehlt sie ausdrücklich für Gateways, die kein ARC unterstützen, und rät davon ab, die Spamfilterung für Gateway-Adressen pauschal abzuschalten: Viele Filteranbieter teilen Adressen mit vielen Kunden, sodass eine Ausnahme auch gefälschte Nachrichten von dort durchlassen könnte. Microsoft Learn: Mail flow with a third-party cloud service

Mit dem Gateway verschiebt sich auch die Vertrauensgrenze für Authentication-Results. Ein vom Anbieter betriebenes Gateway kann innerhalb Ihrer Vertrauensgrenze liegen, wenn Sie es so einrichten; RFC 8601 nennt ausdrücklich Systeme, die ein Dienstleister in seinem Rechenzentrum betreibt. Legen Sie fest, welches System welche Ergebnisse schreibt und welches Feld Ihre Administration auswertet. Felder mit Ihrer Kennung, die von außen kommen, muss das annehmende System entfernen. RFC 8601, Abschnitte 1.2 und 5

Der ausgehende Weg

Ob ausgehende Nachrichten über das Gateway laufen, ist eine eigene Entscheidung. Nur wenn sie es tun, gehört das Gateway in den SPF-Record; Microsoft formuliert das für Microsoft 365 ausdrücklich so. Verändert das Gateway ausgehende Nachrichten, etwa durch eine Signatur oder einen Hinweistext, muss die DKIM-Signatur danach entstehen: durch das Gateway selbst mit einer ausgerichteten Domain oder durch einen Aufbau, in dem nach der Signatur nichts mehr verändert wird. RFC 6376 verlangt von verändernden Stationen wie Mailinglisten ausdrücklich, Änderungen vor dem erneuten Signieren vorzunehmen. Microsoft Learn: Mail flow with a third-party cloud service, RFC 6376, Abschnitt 5.4, SPF, DKIM

Die folgende DNS-Abfrage zeigt, welche MX-Ziele Ihre Domain veröffentlicht. Sie wurde für dieses Kapitel nicht ausgeführt; Namen und Ausgabe sind Beispiele.

dig +short MX example.com
# Beispielausgabe (erfunden):
# 10 mx1.gateway.example.net.
# 20 mx2.gateway.example.net.

Die Ausgabe beantwortet nur, welche Ziele Sender verwenden sollen. Ob der Postfachdienst zusätzlich direkt annimmt, ob gefiltert wird und ob Ihre Nachrichten korrekt authentifiziert ankommen, zeigen Konfiguration und eigene Testnachrichten. Sofern der E-Mail Security Check eine private Testmail anbietet, zeigt sie SPF-, DKIM- und DMARC-Befunde dieser einen Nachricht; eine ARC-Auswertung gehört nicht dazu.

Ein Gateway auswählen: Prüffragen statt Markenlisten

Dieses Kapitel nennt keine Anbieterlisten, Marktanteile oder Eigentümerverhältnisse. Solche Angaben ändern sich schnell und belegen nichts über die Schutzwirkung einer konkreten Installation. Anbieterklassifikationen in Marktstudien und Marktanteile sind verschiedene Größen; eine Studie ist nur mit Datum, betrachteten Produkten und Methodik einzuordnen. Abwehrquoten sind nur zusammen mit Testaufbau, Angriffsauswahl, Produktversion, Konfiguration und Fehlalarmrate aussagekräftig. Unternehmenssitz und Eigentümer sind Informationen für den Vertrag, aber weder ein Schutznachweis noch ein Konformitätsbeleg.

Eigene Weiterleitung oder Mailingliste: ARC nur mit klarem Zweck

Betreiben Sie selbst eine Weiterleitung, eine Mailingliste oder ein Gateway, prüfen Sie zuerst die Maßnahmen aus dem Abschnitt Weiterleitungen und Mailinglisten. Eine ARC-Signierung ergänzt sie; sie ersetzt keine davon. Bevor Sie erstmals versiegelte Nachrichten versenden, veröffentlichen und prüfen Sie den zugehörigen öffentlichen Schlüssel. Im laufenden Nachrichtenfluss gilt diese Reihenfolge:

1. Beim Eingang prüfen. SPF, DKIM und DMARC der eingehenden Nachricht auswerten und in einem Authentication-Results mit Ihrer eigenen Kennung festhalten. Daraus entsteht das AAR.
2. Verändern und signieren. Alle Änderungen einschließlich einer eigenen DKIM-Signatur müssen vor dem Versiegeln abgeschlossen sein.
3. Zuletzt versiegeln. Das ARC-Set mit der nächsten Instanznummer hinzufügen. Enthält die Nachricht bereits eine Kette, deren jüngstes Siegel cv=fail trägt, wird nicht weiter versiegelt.
4. Schlüsselbetrieb erhalten. ARC verwendet dieselbe Schlüsselveröffentlichung wie DKIM unter <Selektor>._domainkey.<Signierdomain>. Der Selektorname ist frei wählbar; ein Name arc ist nicht vorgeschrieben. Die Spezifikation stellt keine Anforderungen an Selektoren und Domains der Siegel.
5. Testen und dokumentieren. Prüfen Sie Ergebnisse an Empfangssystemen, die Sie selbst kontrollieren, und nennen Sie Empfängern, die Ihnen vertrauen wollen, die Signierdomain.

Quellen: RFC 8617, Abschnitte 4.1.2, 4.1.3 und 5.1.

Zum Stand verbreiteter Implementierungen, wie er am 27. September 2026 in deren Dokumentation nachzulesen war:

• OpenARC: Die Weiterentwicklung findet im Projekt flowerysong/OpenARC statt. Dessen Änderungsprotokoll nennt Version 1.3.0 vom 29. Oktober 2025 und beschreibt ab Version 1.0.0 vom Oktober 2024 die Änderungen gegenüber dem letzten Release des Trusted Domain Project. Die README bezeichnet ARC als weiterhin experimentell und das Paket als Angebot für Betreiber, die am Experiment teilnehmen wollen. Welche Version Ihre Distribution ausliefert, prüfen Sie dort selbst. OpenARC: CHANGELOG, OpenARC: README
• Exim: Seit Version 4.91 gibt es eine experimentelle ARC-Unterstützung, die beim Bauen aktiviert werden muss (EXPERIMENTAL_ARC). Die Exim-Dokumentation verweist dafür noch auf den ARC-Entwurf 11 und vermerkt, dass ein Abgleich mit RFC 8617 aussteht. Exim: NewStuff, Exim: experimental-spec.txt
• Rspamd: Das ARC-Modul prüft und signiert laut Dokumentation seit Version 1.6. Mailcow bringt Rspamd als Filterkomponente mit. Rspamd: ARC module, Mailcow-Dokumentation

Was der E-Mail Security Check zu ARC und Gateways erhebt

Der E-Mail Security Check liest öffentliche DNS-Daten Ihrer Domain. Zu ARC und Gateways liefert er ausschließlich Hinweise ohne Punktgewicht; sie verändern die Note nicht, und ein fehlender Hinweis ist kein Mangel.

Ältere gespeicherte Ergebnisse können ARC noch mit damaligen Punkten zeigen; sie behalten ihren gespeicherten Maßstab und sind ebenfalls kein Nachweis einer geprüften Nachrichtenkette.

Im kostenlosen E-Mail Security Check können Sie eine eigene beziehungsweise autorisierte Domain ohne Registrierung untersuchen; den genauen Prüfumfang beschreibt die Checkseite. Für die Fragen dieses Kapitels – Vertrauen in einen Sealer, Beschränkung der Annahme, Wirkung eines Filters – brauchen Sie zusätzlich die Konfiguration Ihrer Systeme und eigene Testnachrichten.

Typische Fehlerbilder und nächste Schritte

Nachweise und Dokumentation richtig begrenzen

Halten Sie für ein Gateway fest: MX-Satz mit Zeitpunkt, Weiterleitungsziel, Annahmebeschränkung am Postfachdienst, eingetragene ARC-Sealer mit ihrer Signierdomain oder die Einstellung zum Überspringen der Gateway-Adresse, die Veränderungen an Nachrichten, den ausgehenden Weg samt SPF und DKIM sowie die Kopfzeilen datierter Testnachrichten. Für eine Weiterleitung oder Liste gehören Umschreibungen und ein etwaiges ARC-Siegel dazu.

Weder ein ARC-Kopfzeilenset noch ein MX-Muster oder ein Ergebnis des E-Mail Security Check belegt eine wirksame Filterung oder die Erfüllung organisatorischer oder rechtlicher Anforderungen. Welche Anforderungen für Ihre Organisation gelten, behandelt das Kapitel Compliance und Dokumentation; dieses Kapitel trifft dazu keine Aussage.

Passende nächste Themen

• DMARC: Alignment, Policy und Berichte – warum ein ausgerichteter Pass nötig ist und wie Sie Aggregatberichte lesen.
• DKIM: Signatur und Selektor – welche Änderungen eine Signatur ungültig machen.
• SPF: Versandberechtigung – wann ein Gateway in den SPF-Record gehört.
• DMARC-Enforcement – eine strengere Policy mit Blick auf Weiterleitungen einführen.
• MTA-STS und TLS-RPT und MX-Infrastruktur – MX-Satz und Transportpolicy bei einer Gateway-Umstellung.
• Bedrohungen, bei denen ein passend betriebener Filter ergänzend helfen kann: Phishing, Business Email Compromise, gefährliche Anhänge und Echospoofing und SubdoMailing.

Vorheriges Kapitel: DNS-Sicherheit: DNSSEC, DANE und CAA. Nächstes Kapitel: E-Mail-Alias-Strategie.