#243 Legacy E-Mail trifft Sicherheit: SPF, DKIM, DMARC, ARC

E-Mails wirken simpel – sind aber technisch ein ziemliches Minenfeld. In dieser Adventkalender-Folge tauchen wir in die Welt von SPF, DKIM, DMARC, SRS und ARC ein.

Im Engineering-Kiosk-Adventskalender 2025 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb weniger Minuten über ein interessantes Tech-Thema.

Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Anregungen, Gedanken, Themen und Wünsche

Dein Feedback zählt! Erreiche uns über einen der folgenden Kanäle …

EngKiosk Community: https://engineeringkiosk.dev/join-discord
LinkedIn: https://www.linkedin.com/company/engineering-kiosk/
Email: stehtisch@engineeringkiosk.dev
Mastodon: https://podcasts.social/@engkiosk
Bluesky: https://bsky.app/profile/engineeringkiosk.bsky.social
Instagram: https://www.instagram.com/engineeringkiosk/

Unterstütze den Engineering Kiosk

Wenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer

Buy us a coffee: https://engineeringkiosk.dev/kaffee

Sprungmarken

(00:00:00) SPF, DKIM, DMARC, SRS, ARC

Hosts

Wolfgang Gassler (https://gassler.dev)
Andy Grunwald (https://andygrunwald.com/)

Community

Diskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Andy Grunwald (00:00:06 - 00:00:32)

Du bist hier im Engineering Kiosk gelandet und zwar im Engineering Kiosk Adventskalender. Leider hat dieser Kalender nichts mit Schokolade zu tun. Doof finde ich auch. Na gut, machst du nix. Als Alternative bieten wir ein wenig Wissen an. Ein Thema kurz und knapp in ein paar Minuten und das Ganze bis Heiligabend. Präsentiert von Knecht, Ruprecht und Krampus. Ach scheiße, falsche Zeile. Präsentiert von Wolfi. Los geht's, viel Spaß.

Wolfi Gassler (00:00:34 - 00:20:44)

Ich habe gestern wieder mal eine sehr interessante E Mail bekommen und zwar war der behördliche Zustellung erforderliche Prüfung amtlicher Unterlagen und zwar Absender war verwaltungolizeigv AT von der Polizei Österreich Verwaltung. Im ersten Moment habe ich mir gedacht, OK, Organstrafmandat, bin irgendwo zu schnell gefahren, habe schon die E Mail geöffnet, hat auch recht sauber ausgesehen. Der Anhang war dann jedoch eine HTML Datei und da habe ich dann schon gemerkt, OK, HTML Dateien als Anhang, das muss irgendwie Spam sein oder da muss irgendwie ein Problem sein. Und ich habe mich dann gewundert, eigentlich ist es nicht sehr üblich, dass da wirklich die richtige Domain verwendet wird als Absender, also Polizei GV AT, was ja wirklich eine korrekte Domain bei uns in Österreich ist. Und ich habe mir dann mal den Quelltext von der E Mail angesehen und habe dann auch gesehen, dass zum Beispiel der SPF Check durchgeführt wurde und der OK gewesen ist. Also die Absender Domain war in Ordnung. Der Mail Server von dieser Absender Domain hat wirklich diese E Mail gesendet bzw. War legitimiert, E Mails zu versenden für diese Domain. Jetzt muss man aber wissen, dass das Sender Policy Framework eigentlich nur die Absender Domain von dem Envelope einer E Mail überprüft. Was ist jetzt dieses Envelop? Es ist so, dass E Mails eigentlich zwei Layer haben, also wie so ein Zwiebelmodell. Es gibt den äußeren Layer und den inneren Layer. Der innere ist die eigentliche E Mail mit dem Inhalt mit der Absenderadresse und dann gibt es außen noch mal so ein Paket, was dann wirklich versendet wird oder ein Kuvert, ein Umschlag. Und dieser Umschlag Envelope hat nochmal eine eigene E Mail Adresse, eine Absender E Mail Adresse. Das ist üblicherweise dann der Mail Server, wenn es irgendwelche Bounce E Mails gibt, also wenn es irgendwie ein Problem gibt bei der Auslieferung, dann kann man diese E Mail Adresse etwas zurücksenden. Das ist der Mail Server, das heißt, es ist eine andere Kommunikationsebene von E Mails und hat nichts mit der inneren E Mail Adresse zu tun. Der Absender E Mail Adresse, die bei uns im E Mail Programm üblicherweise angezeigt wird. Und es war genauso auch bei dieser Polizei GV at Spam E Mail. Der Return Path war nämlich noreplyzeit Store und genau diese Kaffeezeit Store Domain wurde über SPF überprüft und der SPF Eintrag am DNS Server zu Kaffeezeit Store hat eine IP Adresse beinhaltet von einem Mail Server, der diese Spam Nachricht gesendet hat. Also es war in dem Fall wirklich in Ordnung. Kaffeezeit Store klingt jetzt nach irgendeiner echten Domain, habt ihr es aber überprüft, da liegt jetzt keine Webseite oder was ähnliches dahinter. Also das ist wirklich eine Domain, die wahrscheinlich verwendet wird, um Spam zu versenden. Jetzt habe ich schon erwähnt, im DNS Eintrag ist da was hinterlegt worden. Also wie funktioniert dieses Sender Policy Framework eigentlich? Das sind nichts anderes als Texteinträge in DNS Servern. Und zwar von dieser Domain, in dem Fall Kaffeezeit Store, gibt es einen TXT Eintrag und und der definiert dieses SBF. Und da kann man dann eine Liste angeben von IP Adressen oder auch Domain Names, welche Mail Server erlaubt sind, dass die E Mails im Namen von dieser Domain versenden. Da gibt es dann verschiedene Settings. Man kann da ein Hard Fail definieren, also mit so einem Minus All oder einem Soft Fail mit einer Tilde All ist der Unterschied, ob es abgelähmt wird oder härter behandelt wird oder eben schwächer behandelt wird. Schwächer wäre jetzt vielleicht nur in den Spam Ordner verschieben oder überhaupt nur als verdächtig markieren. Es gibt dann auch so eine neutrale Einstellung eigentlich das meiste ist Soft Fail, weil so ein richtiges Hard Fail will man eigentlich selten haben, Dass die wirklich abgelehnt sind, warum, da kommen wir später noch drauf zu sprechen. Aber wichtig ist, dass das SPF eigentlich nur die Envelope Absender E Mail Adresse überprüft oder die Domain überprüft und nicht die, die wir in dem E Mail Programm angezeigt bekommen. Das ist natürlich ein großes Problem, wenn wir da zwei Ebenen haben. Ich habe mir, wie ich das zum ersten Mal gehört habe, gefragt, warum hat man überhaupt diese zwei Ebenen? Warum hat man nicht nur eine Absenderadresse? Aber das kommt natürlich aus dem historischen E Mail Protokoll wo man eben diese zwei Layer hat, wo die Mailserver auch miteinander kommunizieren für Bounces, wenn etwas schief geht, dass man wieder was zurücksendet an den Mail Server, dass der dann wieder reagieren kann drauf und im Inneren ist die eigentliche E Mail mit dem Inhalt und dem Absender dann abgelegt. Das war einfach früher anders aufgebaut, da hat man auch kein Problem mit Spam gehabt. Und dann hat man natürlich später angefangen, irgendwelche Mechanismen darüber zu bauen, in dem Fall mit DNS, um dann in die Richtung Spam Bekämpfung zu gehen, ganz klar. Aber das SPF ist keine richtige Spam Bekämpfung, weil eben nur der Envelope Absender überprüft wird, der From in dem Envelope und und nicht im eigentlichen E Mail. Wenn wir jetzt in die Richtung gehen, dass wir das eigentliche E Mail überprüfen wollen, dann gibt es da natürlich auch etwas und das nennt sich TKIM Domain Keys Identified Mail. Und das ist ein Verschlüsselungsverfahren bzw. Ein Signierungsverfahren, das asymmetrische Verschlüsselung verwendet, um eine E Mail digital zu signieren. Und da geht es jetzt nicht darum, dass man digital signiert. Diese E Mail wurde wirklich von einem speziellen User versendet, was ja oft mit digitaler Signatur gemeint ist, sondern in dem Fall signiert der Mail Server die E Mail und man kann dann nachprüfen, wurde die E Mail wirklich von einem Mail Server erstellt, der auch E Mails senden darf für diese angegebene Domain zum Beispiel. Es funktioniert dann auch wieder über DNS Einträge. In einem DNS Eintrag ist der öffentliche Schlüssel hinterlegt von dem asymmetrischen Verschlüsselungsverfahren. Also üblicherweise wird der RSA oder ED fünf tausend fünf hundert neunzehn zum Beispiel verwendet. Da liegt ein öffentlicher Schlüssel, den kann jeder abrufen, weil es ja im DNS öffentlich zur Verfügung steht. Und wenn ich jetzt ein E Mail empfange und es hat so eine Signatur in einem Header, dann kann ich natürlich nachprü Ist die Signatur gültig? Wurde diese Signatur wirklich mit dem privaten Schlüssel auch erstellt und kam diese E Mail wirklich von diesem Mailserver, der von dieser Domain auch wirklich senden darf? Das ist natürlich immer noch keine Spam Erkennung. An sich ist der Spam drinnen, weil man kann ja auch eine Spam grundsätzlich signieren, aber ich habe schon mal eine Authentifizierung und kann überprü Ist die Domain in Ordnung Und wurde auch nichts verändert an der E Mail, weil sobald an der E Mail natürlich etwas verändert wird, also auch eine Absenderadresse zum Beispiel, wenn die im Hash mit einbezogen wurde, da wird noch zusätzlich angegeben, also wirklich welche Felder wurden im Hash mit einbezogen in der Signatur, dann würde man natürlich jede Änderung sofort sehen und dann würde die Prüfung nicht mehr standhalten. Wenn wir jetzt aber wieder an Spam denken, dann haben wir da immer noch ein Problem, dass wir natürlich nicht wissen, wenn wir jetzt eine E Mail bekommen ohne DKIM Signatur, verwendet der Absender keine Signaturen, keine DKIM oder ist es vielleicht ein Spam von irgendeinem anderen Mail Server, der eigentlich gar nichts versenden darf oder und da gibt es einen anderen Standard, der da jetzt noch übergreifend über DKIM und SBF darüber gesetzt wird, der nennt sich DMARC, Domain Based Message Authentication Reporting and Conformance, entstand so um die zwei hundert elf zwei tausend zwölf von einer Alliance von den ganzen großen Google, Yahoo, Microsoft, paypal und so weiter, ist auch ein RFC sieben tausend vier hundert neun und achtzig und D Mark prüft jetzt eigentlich einerseits die Authentifizierung, das heiß ist der SPF Check OK, also ist die Domain des Envelopes OK, und prüft zusätzlich noch, ob DKIM in Ordnung ist, ob die Signatur in Ordnung ist, ob diese E Mail nicht verändert worden ist und wirklich signiert wurde von einem Mail Server, der das auch wirklich darf für die Domain. Und als zweiten Schritt, der bei DMARC ganz wichtig ist nach dieser Authentifizierung, ist das sogenannte Alignment. Dieses Alignment prüft dann, stimmen die Domains von SPF oder DKIM überein mit dem From Header, mit dem Absender Header in der eigentlichen E Mail und wenn das nicht der Fall ist, dann kann man in DMARC definieren, was der Empfänger machen soll. Das heißt auch da wieder sind DNS Einträge, die definieren, wenn das Alignment nicht stimmt, wie sollst du als Empfänger reagieren und üblicherweise ist da einfach gar nicht reagieren, mach einfach gar nichts. Quarantäne ist der Klassiker, also wenn da etwas nicht stimmt, steckt das Ding in Quarantäne, was üblicherweise heißt in den Spam Ordner. Oder man kann auch ganz hart definieren reject, das heißt, wenn das Alignment nicht stattfindet, wenn das nicht okay ist, dass SPF DKIM übereinstimmt mit der Absender Domain, dann rejecte und stelle gar nicht zu gibt dann auch noch so Feineinstellungen, wie streng so das ganze SPF oder DKIM gehandhabt werden soll in D Mark. Aber nur mal so als Grobkonzept, da kann man noch mal definieren, was passiert, wenn es nicht stimmt. Jetzt klingt das Ganze natürlich super perfekt. Ich habe da ein asymmetrisches Verschlüsselungsverfahren, ich habe da Signaturen, ich kann da alles überprüfen und das funktioniert alles perfekt. So leicht ist es natürlich nicht. Also es gab einen bekannten Fall in zwei tausend vierzehn wo zum Beispiel Yahoo plötzlich auf D Mark Reject gesetzt hat, ihren Eintrag und das hat zur Folge gehabt, dass plötzlich extrem viele E Mails, die über Mailinglisten gesendet worden sind oder weitergeleitet worden sind, dass die nicht mehr angenommen worden sind. Das heißt, es sind ganz viele E Mails nicht angekommen, was natürlich ein super riesen Problem ist. Das heißt, man kann da mit einem Eintrag ganz viel erreichen, vor allem wenn man so eine Domain wie Yahoo zum Beispiel ist, wo ganz viele E Mails auch darüber laufen, dann kann man natürlich da in der Auslieferung ziemlich viel kaputt machen. Die Leute beschweren sich dann natürlich auch, weil die haben das nicht so im AUG, was da eigentlich im Hintergrund passiert Und gerade bei Mailinglisten oder Weiterleitungen, wo eben E Mails dann weitergeleitet werden und vielleicht irgendwas verändert wird, kann das ganz leicht passieren, dass da natürlich irgendwelche Absenderadressen geändert werden oder irgendwelche Checks nicht mehr funktionieren, weil eben die Domains geändert werden, auch vom Envelope vielleicht oder eben der Envelope nicht geändert wird und dann stimmt erst recht die Domain nicht mehr überein, weil da falsche Envelope Domain drinsteht, weil man nicht mehr dafür verantwortlich ist, vielleicht auch nicht sauber gewartet ist für einen Mailing Listen Server. Also da kann man natürlich super viel kaputt machen und da sind dann wirklich von heute auf morgen Millionen von E Mails plötzlich nicht mehr zugestellt worden. Es gab so einen ähnlichen Fall in Deutschland, also da hat zwei tausend sechzehn GMX und webde plötzlich angefangen, die SPF Einträge sehr streng auszuwerten, ohne eine vorherige Ankündigung. Und das hatte zur Folge, dass einfach plötzlich ganz viele E Mails auch da wieder abgelehnt wurden. Die Leute haben sich natürlich beschwert, meine E Mails kommen nicht mehr an, haben sich natürlich dann bei ihrem Provider beschwert, obwohl der gar nichts dafür kann, weil der leitet dann natürlich nur weiter oder sendet das an irgendeine Domain, aber kann ja nicht darauf einwirken wie GMX oder webde, wie streng die dann auch die Auswertung machen. Also also man sieht schon, Weiterleitungen sehen ein großes Problem, wenn es darum geht, irgendwelche DKIM, SPF oder dann mit D Mark diese Auswertungen zu machen, weil dort eben Mail Server fremde E Mails weiterleiten. Das ist die Idee einer Mailingliste oder auch einer Weiterleitung. Wenn man selber eine Weiterleitung definiert, ich bekomme auf irgendeiner Domain A irgendwelche E Mails und sende die dann weiter an meine Gmail Adresse zum Beispiel, dann ist da natürlich ein Problem, wenn dann irgendwelche Domains nicht mehr übereinstimmen oder die Absender E Mail Adressen nicht mehr stimmen. Diesem Weiterleitungsproblem hat man sich aber auch mal angenommen und hat das Sender Rewriting Scheme erfunden. Da ist es also darum gegangen, dass man eigentlich die Envelope E Mail Adressen abändert und die Original E Mail Adressen dort hinein kodiert und das Ganze dann kaskadierend zurücksendet. Das ist aber super kompliziert gewesen und wurde eigentlich nie richtig so verwendet. Google hatte das eine Zeit, aber ich glaube, was es ganz gut darstellt, ist der Postfix Erfinder, der das einfach gemeint hat. Das ist Bullshit by Design und er wird es auf keinen Fall implementieren. Und dann ist es eigentlich auch ganz klar, weil Postfix ist wahrscheinlich der meistverbreitetste Mail Server auf der Welt. Wenn der das nicht implementiert, dann haben das die wenigsten in der Praxis dann zur Verfügung. Und so hat sich das auch gar nicht durchgesetzt. Und grundsätzlich gibt es ja mit DKIM und D Mark eine sehr gute Lösung, die eigentlich auch sicher ist, weil wenn man Envelop grundsätzlich abändert, aber das eigentliche E Mail, das ja noch signiert ist mit der Fromadresse und wo alles übereinstimmt, wenn man das einfach in einen neuen Umschlag steckt und weiterleitet, passiert hier eigentlich nichts. Also ich kann ja eine legitimierte E Mail eigentlich beliebig oft weiterleiten oder neu verpacken in Envelopes, solange das innen verifiziert werden kann. Und es ist ja wirklich eine asynchrone Verschlüsselung und mit der Signatur stelle ich eigentlich sicher, dass alles gut funktioniert. Es gibt mittlerweile auch zusätzlich noch das sogenannte ARC Authenticated Received Chain Protokoll oder Standard. Das ermöglicht zusätzlich nochmal Mail Servern so gewisse Informationen, was bei ihren Checks rausgekommen ist, mit weiterzusenden. Wenn man das E Mail weiterleitet zum Beispiel, also wenn bei mir SPF oder DKIM in Ordnung war und das alles gestimmt hat, dann kann ich das zusätzlich nochmal in den Header schreiben, das Ganze wird natürlich auch wieder signiert, Dann weiß der nächste Mail Server, ah OK, da war schon mal was, das hat bei dem letzten Mail Server alles gut funktioniert, das ist bestätigt worden, Das heißt, ich kann das auch dementsprechend in meinem Spam Score mit einbeziehen in die Berechnung, ob das eine legitime E Mail ist, die ich auch gerne dann dem User weiterleite oder eben in den Spam Ordner verschiebe. Was man auf jeden Fall da recht schön merkt, ist, dass wir da einerseits mit einem extremen Legacy System zu tun haben, wie dem E Mail Protokoll an sich, das super alt ist, aber trotzdem noch eines der wichtigsten Kommunikationsprodukte Protokolle ist, das wir heute haben und dass man da probiert hat, über diese zusätzlichen Mechanismen wie DKIM, SPF, D Mark, über diesen Weg, dass man im DNS eigentlich ganz intelligent Sachen öffentlich hinterlegen kann und die dann bei der Auswertung verwenden kann, dass man das eigentlich sehr schlau gelöst hat, um dieses Legacy System aufzuwerten oder aufzupeppen und die Probleme von heute mit Spam zu lösen. Das Problem natürlich ist, dass da alle Mail Server mitspielen müssen. Es gibt natürlich auch die bösen Player, die Spam versenden, es gibt viel Streit zwischen den ganzen Anbietern, die Standards müssen immer erst implementiert werden, man kann da auch ganz viel kaputt machen. Ich würde übrigens jedem empfehlen, das habe ich noch nicht erwähnt bei dmark, das heißt Domain Based Message Authentication Reporting and Conformance, dass man da auch dieses Reporting aktiviert. Das Reporting heißt nämlich, dass man im DNS Eintrag auch bestimmen kann, wenn irgendwo etwas schief läuft, wenn dann SPF oder dkimcheck nicht okay geht, wenn das Alignment nicht stimmt, sende mir doch eine Info als Domain Owner, dass bei dir etwas schiefgegangen ist und schick mir auch welche IP Adresse zum Beispiel, damit ich weiß, okay, wie viel Spam wird denn da versendet in meinem Namen, wo gibt es denn da Probleme, dass man das auch mitbekommt. Jetzt bekommt man da natürlich dann womöglich ganz viele E Mail Adressen gesendet. Man kann das auch aggregieren lassen teilweise, aber dann bekommt man immer noch von Gmail E Mails gesendet von Sachen, die nicht funktioniert haben, bei denen von Yahoo, von Gmx und so weiter. Also man bekommt trotzdem noch viele E Mails. Das heißt, üblicherweise verwendet man dann ein Tool, das diese E Mail Adresse abruft, wo wirklich diese Statistiken hingesendet werden, diese Problemfälle, und bildet sich dann nochmal aggregierte Views auf diese ganzen Daten, damit man weiß, okay, habe ich da irgendwo ein Problem. Da gibt es auch ganz viele Tools natürlich, für die man zahlen muss. Es gibt auch ganz einfache Tools, die sind kostenlos. Es gibt natürlich auch ganz viele Open Source Tools dafür. Ich werde in den Shownotes ein Tool verlinken, das ich ganz gerne verwende. Das ist von Postmark, die sind so Marketing Mailing Tool, also die haben sehr viel Erfahrung in E Mails versenden und die haben halt auch so ein ganz einfaches Statistik Tool. Da bekommt man einmal die Woche dann eine Zusammenfassung und da sieht man dann auch ganz schön, wo sind denn die Weiterleitungsprobleme, wo hat es Probleme gegeben. Ich bekomme da dann auch ganz oft, dass eben bei Outlook Com ganz viele E Mails abgelehnt worden sind, sind die üblichen internen Weiterleitungen, die da oft passieren, aber dann hat man wenigstens so einen Einblick und vor allem, wenn man irgendwas falsch konfiguriert hat, bekommt man das sehr schnell mit. Das ist mir selber auch schon passiert, wenn man da irgendwo etwas zu hart setzt, irgendwie ein Flag von All auf Tilde All oder umgekehrt oder irgendwo ein hartes Reject von einem Soft Reject, dann kann es sein, dass da plötzlich sehr viel mehr E Mails abgelehnt werden. Und wenn man da so ein Reporting hat, so eine Info bekommt, dann kann man da auch dementsprechend sehr schnell reagieren und sieht, wo die Probleme auftreten. Also bei D Mark dieses Reporting zu aktivieren, dass man eine E Mail Adresse, so Reports gesendet bekommt, kann ich nur schwer empfehlen, weil man kann da wirklich viel kaputt machen, wie man ja auch bei der Umstellung von Yahoo oder von GMX gesehen hat. Trotzdem finde ich es immer super spannend, wie man aus so einem alten Protokoll doch noch irgendwas machen kann, indem man einfach was dazu baut und wenn da intelligente Köpfe dran sitzen, dass man da doch gemeinsam dann irgendwie Protokolle schafft, die die Welt verbessern, obwohl man noch abwärtskompatibel bleibt. Und wenn man den Verbreitungsgrad heutzutage ansieht von D. Kim, dann sind wir dann schon sehr, sehr breit. Google hat es kürzlich verpflichtend sogar gemacht, dass sie also wirklich E Mails ohne diese Signatur ablehnen können oder ablehnen wollen. Wie Hardsys durchziehen in der Realität ist dann noch mal eine andere Sache. Aber auch da sieht man, dass wirklich Spam möglichst hart bekämpft wird und ich kann eigentlich nur jedem empfehlen, weil Spam wird einfach immer besser dank LLMs und Co. Dass man auch wirklich überprü Hat so eine E Mail wirklich einen DKIM Header, eine Signatur drin ist der OK. Jetzt macht man das natürlich nicht immer manuell und schaut in den Quelltext rein. Ich persönlich verwende zum Beispiel für meinen Thunderbird ein Plugin, der zeigt mir das einfach nochmal zusätzlich an. Was ist denn die DKIM Domain? Absender Domain, Ist es verifiziert? Ist es OK, Wurde da was verändert? Das heißt, ich verlasse mich nicht nur auf den Spam Score oder ob das in einem Spam Ordner landet, sondern habe zusätzlich auch noch diese Ebene, dass es überprüfen kann. Und wenn ich mal so eine behördliche Zustellung wieder bekomme, dann kann ich relativ schnell Ist es DKIM, ist es in Ordnung? Ist es legitimiert? Oder ist es einfach nur ein Spam, der sehr, sehr, sehr gut aussieht? Und so probiere ich mich auch selber zu schützen. Alle Links findet ihr natürlich in den Shownotes zu diesen Tools und Plugins, die ich verwende, aber es gibt ganz viele andere Tools da draußen. Natürlich, wenn man nach den richtigen Begriffen sucht, ist man da eigentlich relativ schnell. Also als reine User von E Mails versucht vielleicht auf DKIM und SPF so ein bisschen ein Auge zu werfen für alle, die selber Domains verwalten. Ich glaube, SBF DKIM Einträge und D Mark Einträge sind mehr oder weniger verpflichtend heutzutage. Man muss aber einfach aufpassen, ob die alle wirklich in Ordnung sind und auch stimmen und nicht zu stark eingestellt sind. Und da hilft das Reporting natürlich auch dementsprechend dabei. Und damit wünsche ich euch noch schöne Weihnachten. Jetzt ist es ja wirklich Bald soweit. Ich hoffe mit möglichst wenig Spam und vielleicht mit ein bisschen Heim wenigstens.

Andy Grunwald (00:20:46 - 00:21:12)

Danke Wolfi, für diese Episode. Das war's für heute von uns. Wenn dir das, was du gehört hast, gefallen hat, würden wir uns natürlich immer über Feedback freuen. Entweder über ein positives Review auf der Podcast Plattform deiner Wahl, einen Daumen hoch auf Social Media oder eine Anekdote in unserer Discord Community. Ich bin mir sicher, du findest schon einen Weg. Wir freuen uns auch, wenn du diesen Podcast abonnierst und einfach bei der nächsten Episode wieder einschaltest. Wir hören uns bald. Schöne Weihnachtszeit und tschüss.