Die 6 häufigsten DKIM- und DMARC-Fehler und wie man sie behebt

SPF (Sender Policy Framework) ist nur ein Teil der E-Mail-Authentifizierung. Sie können einen perfekten SPF-Eintrag haben und trotzdem erleben, dass Ihre E-Mails im Spam landen, abgelehnt werden oder bei DMARC durchfallen. Der Grund? DKIM (DomainKeys Identified Mail) und DMARC (Domain-based Message Authentication, Reporting, and Conformance) bringen ihre eigenen Fehlerquellen mit, die selbst erfahrene E-Mail-Admins ins Straucheln bringen.

Wir sehen das immer wieder bei Organisationen, die Red Sift OnDMARC nutzen. Ein Marketing-Team richtet SPF korrekt ein, aktiviert aber nie DKIM-Signierung. Ein IT-Team veröffentlicht einen DMARC-Eintrag mit p=none und lässt ihn ein Jahr so stehen. Ein Drittanbieter signiert E-Mails mit seiner eigenen Domain statt mit Ihrer – und bricht damit das Alignment. Das sind keine Randfälle, sondern Alltag bei der E-Mail-Authentifizierung im Jahr 2026.

Mit den neuen Anforderungen an die E-Mail-Authentifizierung im Jahr 2026 wird SPF allein nicht mehr ausreichen, um Probleme bei der Zustellbarkeit zu vermeiden. Wo immer möglich, sorgt die gleichzeitige Konfiguration von DKIM UND SPF für die besten Zustellraten.

Der Zeitplan zur Durchsetzung erhöht den Druck: Google und Yahoo verlangen seit Februar 2024 SPF, DKIM und DMARC für Massenversender [1]. Microsoft folgte im Mai 2025 und weist nicht-konforme Mails mit dem Fehlercode 550 5.7.515 ab [2]. Das sind keine weichen Empfehlungen: Gmail hat im November 2025 von Hinweisen zur konkreten Ablehnung gewechselt und Microsoft blockiert E-Mails nun strikt, statt sie als Spam zuzustellen.

Die Zahlen zur Einführung zeigen, wie viel Aufholbedarf noch herrscht: Eine Analyse von 5,5 Millionen Domains ergab, dass nur 22,7 % einen erkennbaren DKIM-Eintrag besaßen – damit ist DKIM das am wenigsten genutzte E-Mail-Authentifizierungsprotokoll [3]. Und auch wenn DMARC-Verbreitung wächst, haben noch 69,6 % der Domains überhaupt keinen DMARC-Eintrag und nur 6 % erzwingen p=reject [3]. Red Sift analysierte 73,3 Millionen Domains und fand, dass nur 2,5 % p=reject verwenden [4].

Währenddessen steigen die Schäden durch Cybercrime weiter: Im 2025er Bericht zum Internetbetrug des FBI wurden Verluste von über 20,8 Milliarden US-Dollar verzeichnet (26 % mehr als 2024), erneut ist Phishing und Spoofing mit 191.561 Beschwerden die häufigste Straftatkategorie [5]. Business Email Compromise machte über 3 Milliarden Dollar Schaden aus 24.768 Vorfällen aus [5]. Richtig eingerichtetes SPF und DKIM zusammen mit konsequenter DMARC-Durchsetzung schützen davor, dass Angreifer Ihre Domain für Angriffe missbrauchen. Sind alle legitimen Versender mit DKIM konfiguriert, brechen auch Weiterleitungen die Authentifizierung nicht mehr und verursachen keine Zustellprobleme.

Auch der Compliance-Druck ist groß: PCI DSS v4.0.1 schreibt DMARC mit Quarantäne oder Reject für Organisationen mit Zahlungsabwicklung vor [6]. Behörden weltweit – CISA, NCSC UK, ASD Australien, CCCS Kanada – verlangen DMARC für Regierungsdomains. Einen vollständigen Überblick finden Sie in unserer Übersicht zu globalen DMARC-Vorgaben. Auch Cyber-Versicherer fordern DMARC-Durchsetzung zunehmend als Versicherungsbedingung.

Das sind die sechs DKIM- und DMARC-Fehler, die wir am häufigsten sehen – und wie man sie konkret behebt.

So macht sich das bemerkbar: Ihre DMARC-Berichte oder Mail-Header zeigen dkim=fail (body hash did not verify). Die DKIM-Signatur ist vorhanden, der öffentliche Schlüssel steht im DNS, aber die Verifikation schlägt trotzdem fehl.

Warum passiert das? DKIM berechnet beim Signieren einen Hash über den E-Mail-Body (das bh=-Tag im DKIM-Signature-Header). Der empfangende Server ruft dann den öffentlichen Schlüssel zum ursprünglichen Selector ab und berechnet den Hash erneut. Ändert sich zwischen Signatur und Zustellung irgendetwas am Inhalt, stimmen die Hashes nicht mehr überein und DKIM schlägt fehl.

Typische Ursachen sind Zwischenstationen, die die E-Mail nach dem Signieren verändern:

• E-Mail-Security-Gateways, die URLs zum Scannen umschreiben (z. B. Microsoft Defender, Barracuda)
• Anti-Spam-Filter, die Header hinzufügen oder verändern
• Mailinglisten-Software, die Fußzeilen, Listenheader oder Abmeldelinks anhängt oder das SMTP MailFrom überschreibt und/oder die ursprüngliche DKIM-Signatur ersetzt
• DLP-Tools (Data Loss Prevention), die ausgehende Mails prüfen und ggf. verändern
• Automatisches Weiterleiten, wobei der weiterleitende Server den Body verändert

Dies ist einer der schwierigsten DKIM-Fehler, weil die Signatur selbst gültig ist: Schlüssel und Selector stimmen, der Eintrag ist im DNS. Das Problem: Der Nachrichtentext wurde nach dem Signieren verändert.

So lösen Sie das Problem:

Der wichtigste Grundsatz: Die DKIM-Signierung sollte als letzter Schritt erfolgen, bevor die Mail Ihre Infrastruktur verlässt. Jedes System, das nach der Signatur noch etwas verändert, macht die Signatur ungültig.

• Ordnen Sie den Mailflow neu. Falls Ihr Gateway Links umschreibt, muss DKIM danach signieren. Häufig müssen Sie also das Gateway (und nicht den eigentlichen Mailserver) so konfigurieren, dass es im Namen Ihrer Domain signiert.
• Verwenden Sie c=relaxed/relaxed-Kanonsisierung. DKIM unterstützt die Modi simple und relaxed – letztere verzeiht kleine Formatunterschiede. Stellen Sie beide Modi (Header und Body) auf relaxed (c=relaxed/relaxed), um Fehlalarme zu vermeiden.
• Finden Sie das verändernde System. Vergleichen Sie den ursprünglichen DKIM-Body-Hash (bh=) mit dem Wert beim Empfänger. Gibt es Unterschiede, wurde der Body verändert. Verfolgen Sie den Mailsweg über jede Gateways und Filter, um den Schuldigen zu finden.
• Bei Mailinglisten/Weiterleitungen auf DKIM \+ ARC setzen. Mailinglisten verändern Mails zwangsläufig – Sie können das nicht verhindern. ARC (Authenticated Received Chain) bewahrt die Authentifizierungsergebnisse auch bei Weiterleitung, und große Provider wie Gmail & Microsoft berücksichtigen ARC bei der Zustellung. Sorgen Sie auf Ihrer Seite dafür, dass DKIM immer eingerichtet ist. Prüfen Sie mit Red Sift Investigate, dass Ihre Mails schon vor Weiterleitungsfällen den Hash-Check bestehen. Mehr zu Weiterleitungen und Authentifizierung in unserem Konfigurationsleitfaden für SPF, DKIM und DMARC.

So macht sich das bemerkbar: Die Mail-Header zeigen dkim=fail (no key for signature) oder dkim=permerror. Der empfangende Server findet den öffentlichen DKIM-Schlüssel im DNS nicht oder kann ihn nicht lesen.

Warum passiert das? DKIM verlangt, dass der öffentliche Schlüssel im DNS unter selector._domainkey.ihredomain.com veröffentlicht wird. Kann der Empfänger diesen Record nicht finden oder lesen, schlägt die DKIM-Prüfung fehl. Das ist der häufigste DKIM-Fehler – Gründe gibt es mehrere:

• Der DNS-Record wurde nie erstellt. Jemand aktiviert DKIM im Mailservice, aber hinterlegt den öffentlichen Schlüssel nie im DNS. Bei Google Workspace etwa muss der Admin die DKIM-Schlüssel generieren und dann den TXT- oder CNAME-Eintrag ins DNS kopieren. Überspringt man das, wird zwar signiert – aber die Verifikation schlägt immer fehl.
• Der Record liegt in der falschen DNS-Zone. Wer DNS an mehreren Stellen verwaltet (Registrar, Cloudflare, Hoster), trägt die DKIM-Daten womöglich in eine nicht aktive Zone ein. Der Empfänger fragt das autoritative DNS ab – und findet nichts.
• Abgeschnittene 2048-bit-Schlüssel. DKIM-Keys mit 2048 bit sind oft länger als die 255-Zeichen-Grenze für einen TXT-String. Schneidet Ihr Provider den Schlüssel einfach ab, statt mehrere Strings zu verwenden, fehlt ein Teil – die Verifikation schlägt fehl.
• Selector stimmt nicht überein. Das s=-Tag im DKIM-Signature-Header legt fest, welcher Selector beim Lookup verwendet wird. Stimmt der Name in der Signatur nicht mit dem DNS-Record überein, findet der Lookup nichts. Passiert häufig bei Selector-Rotation, wenn alte Selector noch im DNS stehen und die neuen fehlen.

So lösen Sie das Problem:

Finden Sie zunächst den Selector. Schauen Sie in den DKIM-Signatur-Header einer gesendeten Mail (z. B. in Gmail: „Original anzeigen“), suchen Sie das s=-Tag: Das ist Ihr Selector. Sie können dann DNS manuell prüfen oder den Domain Analyzer in Red Sift OnDMARC ausführen.

Geben Sie Ihre Domain und den Selector ein – das Tool zeigt den kompletten DKIM-Record und Konfigurationsprobleme an.

dig TXT selector._domainkey.yourdomain.com +short

Liefert die Abfrage nichts zurück, fehlt der Eintrag. Liefert sie einen unvollständigen Schlüssel, ist dieser abgeschnitten.

• Bei fehlenden Records: Gehen Sie ins Admin-Panel Ihres Mailservices, suchen die DKIM-Einstellungen und kopieren Sie den öffentlichen Key als TXT-Record nach selector._domainkey.ihredomain.com in die aktive Zone.
• Bei abgeschnittenen Schlüsseln: Teilen Sie den Key in mehrere 255-Zeichen lange Strings auf – moderne DNS-Provider machen das beim CNAME-Setup automatisch.
• Bei Selector-Fehlern: Prüfen Sie, ob der Selector-Name in Ihrem Mailservice und im DNS übereinstimmen. Hat der Provider Selector gewechselt, passen Sie Ihren DNS an.
• CNAME-basiertes DKIM nutzen, wo möglich. Viele ESPs bieten DKIM per CNAME-Delegation an: Sie zeigen mit Ihrem Selector auf deren DNS – bei Schlüsselrotation übernimmt der Anbieter alles, ohne dass Sie Ihr DNS ändern müssen.

So macht sich das bemerkbar: DKIM lief monate- oder jahrelang problemlos, dann tritt plötzlich ein Fehler auf. Die Header zeigen dkim=fail, obwohl Sie nichts geändert haben.

Warum passiert das? DKIM-Schlüssel sind nicht dauerhaft gültig. Sie müssen regelmäßig gewechselt werden – läuft hier etwas schief, schlägt die Authentifizierung plötzlich fehl.

Drei typische Fälle:

• ESP hat ohne Ihr Wissen Schlüssel rotiert. Wenn Sie TXT-basiertes DKIM (gesamter öffentlicher Schlüssel liegt bei Ihnen im DNS) nutzen, kann der ESP den privaten Schlüssel jederzeit rotieren. Haben Sie den neuen öffentlichen Key nicht ins DNS übernommen, schlägt die Prüfung fehl – besonders ärgerlich, weil auf Ihrer Seite scheinbar nichts passiert ist.
• 1024-bit-Keys werden abgelehnt oder markiert. NIST empfiehlt mindestens 2048 bit für RSA, und die Branche folgt: Viele Empfänger markieren oder blockieren mittlerweile 1024-bit-Schlüssel. Wer DKIM vor Jahren eingerichtet hat und nie aktualisiert hat, läuft hier ins Problem.
• Das x=-Ablauf-Tag wurde ausgelöst. DKIM-Signaturen können ein Ablaufdatum via x=-Tag enthalten. Wird die Mail z. B. in einem Relay verzögert und nach Ablauf zugestellt, schlägt die Prüfung fehl.

So lösen Sie das Problem:

• Auf 2048-bit-Schlüssel upgraden. Wer noch 1024 bit verwendet, sollte jetzt umstellen. In Microsoft 365 per Rotate-DkimSigningConfig PowerShell, bei Google Workspace im Admin-Panel bei Google Workspace > Gmail > E-Mail authentifizieren. Der Protokoll-Konfigurationsleitfaden erläutert das im Detail.
• CNAME-basiertes DKIM nutzen. Beim CNAME-Delegationsverfahren rotiert der Anbieter die Schlüssel – Sie müssen nichts im DNS tun. Red Sift OnDMARC vereinfacht das komplett und bündelt alle DKIM-Konfigurationen auf einer Plattform.
• Schlüssel regelmäßig rotieren. Branchen-Best-Practice (u. a. M3AAWG): Rotation alle 6–12 Monate bei 2048 bit, mit selbsterklärenden Selector-Namen wie jan2026, um Schlüsseldaten schnell zuzuordnen.
• Großzügige x=-Tags oder ganz weglassen. Wer das Ablauf-Tag nutzt, sollte ausreichend Zeit für Verzögerungen vorsehen – viele lassen x= ganz weg, um Fehler zu vermeiden.

So macht sich das bemerkbar: DKIM-Prüfung besteht (dkim=pass), aber DMARC schlägt trotzdem fehl – weil das Alignment nicht stimmt.

Warum passiert das? Das ist der häufigste DKIM-bezogene DMARC-Fehler und betrifft fast alle, die externe E-Mail-Dienstleister nutzen.

DMARC prüft nicht nur, ob DKIM bestanden wurde, sondern ob die Domain im d=-Tag mit der im From-Header übereinstimmt (oder eine Subdomain ist). Signiert ein Drittanbieter mit seiner eigenen Domain, besteht DKIM, aber DMARC-Alignment schlägt fehl.

So läuft das konkret ab:

• Sie versenden über SendGrid Marketing-Mails von marketing@ihredomain.com.
• SendGrid signiert standardmäßig mit d=sendgrid.net.
• DKIM-Prüfung klappt, da der Empfänger gegen den public Key von SendGrid prüft – dkim=pass.
• DMARC prüft Alignment: Passt sendgrid.net zu ihredomain.com?
• Nein – also Alignment-Fehler. Wenn auch SPF in solchen Drittanbieterfällen das Alignment nicht besteht, scheitert DMARC komplett.

Das passiert bei praktisch jedem ESP, CRM und SaaS-Anbieter: Mailchimp, HubSpot, Salesforce, Zendesk, Freshdesk, Intercom – alle signieren standardmäßig mit ihrer eigenen Domain, außer Sie richten explizit eigene DKIM-Einträge ein.

So beheben Sie das:

Konfigurieren Sie bei jedem Dienst, der für Ihre Domain sendet, „Custom DKIM“ so, dass das d=-Tag Ihre eigene Domain nutzt:

• Die meisten ESPs (Mailchimp, SendGrid, HubSpot): Suchen Sie nach „Domain Authentication“ oder „Custom DKIM“ in den Einstellungen. Der Anbieter liefert Ihnen CNAME- oder TXT-Records für Ihr DNS. Nach Einrichtung wird mit d=ihredomain.com signiert statt mit dessen Domain.
• Google Workspace: Standardmäßig wird Ihre Domain verwendet, Sie müssen DKIM aber explizit im Admin-Panel freischalten und den DNS-Record setzen.
• Microsoft 365: Custom DKIM muss im Defender-Portal aktiviert werden, Microsoft stellt hierfür zwei Selector-CNAME-Records pro Domain bereit.

Prüfen Sie anschließend Ihren DMARC-Alignment-Modus. DMARC unterstützt zwei Einstellungen (adkim=):

• Relaxed (adkim=r): Die DKIM-Signaturdomain kann Unterdomain der From-Domain sein – mail.ihredomain.com entspricht ihredomain.com. Das ist Standard und für die meisten zu empfehlen.
• Strict (adkim=s): Die Signaturdomain muss exakt der From-Domain entsprechen. Nur bei speziellen Sicherheitsanforderungen nötig.

Red Sift OnDMARC zeigt Ihnen, welche Versender DKIM bestehen, aber im Alignment durchfallen, und welche d=-Divergenz Ursache ist. Unsere Vergleichsanleitung erklärt, wie DKIM, SPF und DMARC zusammenwirken.

So macht sich das bemerkbar: Sie haben eine DMARC-Policy, Berichte werden erstellt, aber Policy steht auf p=none. Gefälschte Mails werden an Empfänger zugestellt. Ihre Domain ist zwar „DMARC-aktiviert“, aber nicht geschützt.

Warum passiert das? Das Problem bei p=none ist sehr verbreitet – aber kein technischer Fehler, sondern ein organisatorischer.

Viele stellen DMARC mit p=none ein, um Berichte zu sammeln – das ist der richtige Start. Danach wird aber nie auf Durchsetzung umgestellt. Typischerweise, weil die Berichte schwer zu lesen sind (XML), das Team die legitimen Versender nicht sicher kennt, niemand legitime Mails blockieren will, und das Projekt an Priorität verliert. Monate oder Jahre vergehen – DMARC rollt nur Berichte, aber verhindert keine Attacken.

Zahlen dazu: Von 5,5 Mio. Domains fahren 17,6 % DMARC mit p=none [3]. Laut Red Sift haben von 73 Mio. Domains nur 14,9 % überhaupt DMARC eingerichtet, nur 2,5 % nutzen p=reject [4]. Heißt: Die große Mehrheit ist ausschließlich im Monitoring.

p=none ist kein Sicherheitsmodus, sondern eine reine Berichtsoption: Alle Mails werden zugestellt, Angreifer können nach Belieben Ihre Domain spoofen – jeder Angriff kommt durch.

So stellen Sie um:

Von p=none zu p=reject ist ein gerader Weg, sofern das Vorgehen und Tooling stimmen. Wir empfehlen mit Red Sift OnDMARC:

1. Alle legitimen Versender identifizieren. Ziehen Sie DMARC-Reports heran, um wirklich jeden Dienst, der für Ihre Domain sendet, zu erfassen. OnDMARC erkennt und klassifiziert diese automatisch.
2. Authentifizierung für alle Versender einrichten. Konfigurieren Sie SPF und DKIM sauber für jede Quelle. Mindestens eines (besser beide) muss pro Versender im Alignment bestehen.
3. Zu p=quarantine wechseln. Wenn alle Versender sauber authentifiziert sind: Policy auf quarantine setzen. Damit landen fehlerhafte Mails im Spam statt im Posteingang. Beobachten Sie das Verhalten 1–2 Wochen – sollten Sie legitime Quellen vergessen haben, fällt das auf.
4. Zu p=reject wechseln. Sobald keine legitimen Mails mehr in Quarantäne geraten, gehen Sie auf reject: Alle fehlerhaften Mails werden komplett geblockt.
5. pct=-Tag für schrittweise Einführung nutzen. Wer zögert, sofort zu reject zu wechseln, ergänzt pct=25, sodass anfangs nur 25 % betroffen sind, später (50 %, 75 %, 100 %) schrittweise ausweiten.

Mit den passenden Tools erreichen Organisationen p=reject in 6–8 Wochen. Ohne Plattform kommen viele nie an. Unsere DMARC-Durchsetzungs-Anleitung schrittweise führt Sie durch alle Schritte.

So macht sich das bemerkbar: Sowohl SPF als auch DKIM zeigen pass im Header oder Report, aber DMARC schlägt trotzdem fehl. Einer der irritierendsten Fehler, da scheinbar „alles grün“ ist – aber doch nicht funktioniert.

Warum passiert das? DMARC fordert nicht nur Authentifizierung, sondern Alignment: Sowohl SPF als auch DKIM können für sich bestehen, aber DMARC schlägt fehl, wenn die Domains nicht mit dem From-Header übereinstimmen.

Es gibt zwei Alignment-Prüfungen:

• SPF-Alignment: Die Domain im Return-Path (envelope-from) muss mit der From-Domain übereinstimmen (oder Unterdomain).
• DKIM-Alignment: Die Domain im DKIM-d=-Tag muss mit From-Domain übereinstimmen (oder Unterdomain).

DMARC besteht, wenn mindestens eine dieser Alignments klappt – nur bei doppeltem Missmatch schlägt DMARC fehl.

Ein Beispiel aus der Praxis:

• Ihr Unternehmen sendet Support-Mails über Zendesk mit support@ihredomain.com.
• Zendesk nutzt für den Return-Path seine eigene Domain (@zendesk.com).
• SPF prüft den SPF-Eintrag von Zendesk, findet die sendende IP – SPF besteht, aber als Domain steht zendesk.com statt ihredomain.com.
• Alignment schlägt fehl. Zendesk signiert außerdem mit d=zendesk.com. DKIM besteht gegen den Key von Zendesk, aber das Alignment zu ihredomain.com misslingt.
• Beide Protokolle bestehen Authentifizierung, aber nicht das Alignment – und DMARC schlägt fehl.

So läuft das bei praktisch jedem Drittanbieter, der nicht individuell mit Custom Authentication eingerichtet wurde.

So lösen Sie das:

Mindestens ein Protokoll muss bestehen UND das Alignment erfüllen – am sichersten beide:

• Für DKIM-Alignment: Konfigurieren Sie bei jedem externen Versender Custom DKIM, sodass das d=-Tag Ihre Domain setzt (Hinweise siehe Fehler #4).
• Für SPF-Alignment: Richten Sie beim jeweiligen Anbieter ein, dass als Return-Path Ihre Domain oder Subdomain verwendet wird. Je nach Plattform unterschiedlich: Bei Salesforce muss das Bounce-Management deaktiviert werden, HubSpot und Marketo bieten eigene Envelope-From-Einstellungen.
• Nutzen Sie standardmäßig relaxed Alignment. Mit aspf=r und adkim=r (beides DMARC-Standard) zählen Subdomains als korrekt aligned. Wenn Ihr Marketing-Tool z. B. bounce.ihredomain.com als Return-Path und ihredomain.com als From nutzt, ist das so abgedeckt.

Orientieren Sie sich an Ihren DMARC-Reports: Diese zeigen neben Bestanden/Durchgefallen auch das Alignment für beide Protokolle. Gibt es pass + fail-Verhältnisse, sehen Sie sofort, welches Protokoll/Versender Aufmerksamkeit braucht.

Red Sift OnDMARC listet pro Versender auf, bei welchem Service Authentifizierung besteht, aber das Alignment fehlt. Prüfen Sie ab sofort mit Red Sift Investigate den Alignment-Status Ihrer Domain.

Beim Troubleshooting verrät Ihnen der Authentication-Results-Header, was mit einer Mail passiert ist. Darauf sollten Sie achten:

Für die fortlaufende Überwachung über einzelne E-Mail-Prüfungen hinaus bieten DMARC-Aggregatberichte Ihnen einen vollständigen Überblick über alle sendenden Quellen. Red Sift OnDMARC wandelt rohe XML-Berichte in umsetzbare Dashboards um, und unser Ratgeber für die besten E-Mail-Authentifizierungstools stellt zusätzliche Ressourcen für jede Phase der Implementierung bereit.

DKIM- und DMARC-Fehler folgen vorhersehbaren Mustern. Body-Hash-Abweichungen, fehlende DNS-Einträge, Lücken bei der Schlüsselrotation, Ausrichtungsfehler, ins Stocken geratene Richtlinien und die Lücke zwischen bestandener Authentifizierung und bestandener DMARC-Prüfung. All diese Probleme sind durch E-Mail-Header und DMARC-Berichte diagnostizierbar und alle sind behebbar.

Das größte Risiko ist nicht die Komplexität. Es ist Untätigkeit. Ein DMARC-Eintrag mit p=none verschafft Ihnen zwar Einblick, aber keinen Schutz. Jeder Tag, an dem Ihre Domain auf p=none bleibt, ist ein weiterer Tag, an dem Angreifer Sie ungestraft imitieren können.

[1] Aktualisierung zu Anforderungen an Massenversender \- Google

[2] Stärkung des E-Mail-Ökosystems \- Microsoft Community Hub

[3] DKIM-Fehler: Wie man Ausrichtungs- und Überprüfungsfehler behebt \- DMARCguard

[4] SPF-Flattening: Das versteckte Problem bei der E-Mail-Infrastruktur \- AutoSPF

[5] 2025 IC3 Jahresbericht

[6] PCI DSS v4.0.1 Zusammenfassung der Änderungen

[7] RFC 6376 \- DomainKeys Identified Mail (DKIM) Signaturen