Wenn Du eine eigene Internetdomain (wie z. B. kux.de) hast und darüber Mails verschickst, kann es passieren, dass irgendjemand in Deinem Namen Mails mit Absender voelligegal@kux.de verschickt. Das ist für den Empfänger sehr unschön, da er einen akzeptablen Absender vermutet, aber eine Fälschung bekommt.
Wenn man nichts tut, ist das so: Jeder kann mit einfachsten Mitteln Mails mit gefälschten Absendern verschicken und den Empfänger aufs Kreuz legen.

Ein Lösungsansatz (der leider auch so seine Lücken hat) ist, dass der Empfänger  beim Absender nachfragt, ob die Mail ok ist. Nachfragen bedeutet hier, dass man zu der Absender-Domain (z. b. kux.de) im Domain-Name-System Infos hinterlegt, mit denen der Empfänger prüfen kann, ob die Mail ok ist. Und sich dann entscheiden kann, ob er die Mail akzeptiert.

Die im Domain-Name-System hinterlegten Infos sind drei Einträge mit den kryptischen Namen

• DKIM (=DomainKeys Identified Mail): Kommt die Mail unverändert von einer bestimmten Domain?
• SPF (=Sender Policy Framework): Wer darf eine Mail für diese Domain verschicken?
  
• DMARC (=Domain-based Message Authentication, Reporting and Conformance): Was soll der Empfänger tun?
  

Wie es um die eigene Domain steht, kann man leicht prüfen mit https://mxtoolbox.com oder https://dnschecker.org

Beispiel: https://mxtoolbox.com/emailhealth/kux.de

D. h. es gilt die Empfehlung: Wenn über eine Domain Mails verschickt werden, sollte der Domaininhaber DKMI, SPF und DMARC setzen!
Und als Mail-Empfänger sollten die Mails geprüft werden und ggf. aus dem Verkehr gezogen werden.

Im Detail: Es gibt eine Reihe von Einstellungen für Deine Domain, die dem Empfänger sagen sollen, was erlaubt ist und was nicht.
Wenn Du eine Mail von voelligegal@kux.de an egal@irgendeinedomain.de schickst, passiert(e) folgendes:

• MX Record:
  Du als Absender stellst im Mailprogramm für voelligegal@kux.de eine Mail zusammen und  gibst egal@irgendeinedomain998.de als Empfänger an. „Absenden“ bedeutet, dass Dein Absende-Mailserver zunächst den Ziel-Mailserver (irgendeinedomain998.de) nach dessen MX-Record fragt. Dieser MX-Record ist ein Eintrag in den DNS-Einstellungen einer Domain.
  Als Ergebnis bekommt der Absende-Mailserver eine IP-Nummer, zu der eine SMTP-Verbindung aufgebaut wird.
  SMTP steht für „Simple Mail Transfer Protocol“ und sorgt für den Trasport der Mail zum Ziel-Mailserver. Dort kann man die Mails per POP oder IMAP abrufen.
  Das Problem hier: Der Absende-Mailserver muss mit kux.de nichts zu tun haben. Man kann den Absende-Mailserver einfach so einstellen, dass er behauptet von voelligegal@kux.de bzw. kux.de kommt. D. h. irgendein Hacker kann Mails verschicken, die so aussehen als ob sie von voelligegal@kux.de kommen, aber in Wirklichkeit von irgendeinem anderen Mailserver abgeschickt wurden. 

Um so eine Situation in den Griff zu bekommen wurde DKIM, DMARC und SPF eingeführt: Das sind drei weitere Einträge in den DNS-Einstellungen einer Mail-Absender-Domain. Damit kann der Mail-Ziel-Mailserver nachfragen, ob der Absender erlaubt ist.

• Kommt die Mail unverändert von einer bestimmten Domain? –> DKIM (=DomainKeys Identified Mail)
  Damit kann der Mail-Empfänger, der Ziel-Mailserver,  feststellen, ob eine Mail wirklich von der angegebenen Domain verschickt wurde und ob die Mail unterwegs verändert wurde. Dazu schickt der Absender-Mailserver mit der Mail eine digitale Signatur mit. Diese signatur ergibt sich aus der Domain des Absenders und dem Mailinhalt. Der Ziel-Mailserver kann über DNS den öffentlichen Schlüssel der Absender-Domain abrufen und prüfen, ob die mitgeschickte Signatur korrekt ist. Wenn das nicht der Fall ist, wurde die Mail unterwegs verändert oder nicht die behauptete Domin ist der Absender: Ein fremder Absender kennt den privaten Schlüssel der behaupteten Domain nicht und kann daher die Signatur nicht korrekt berechnen.
  Problem bzgl. DKIM: Was der Ziel.Mailserver nun mit Mails tun soll, die den Signaturcheck nicht bestehen ist offen.
  Beispiel: v=DKIM1; k=rsa; p=MIIB…
  Das bedeutet: RSA wird als Verschlüsselung verwendet, „p=“ gibt den öffentlichen Schlüssel preis. Im Hintergrund, eben nicht öffentlich, gibt es noch den privaten Schlüssel zum RSA-Verfahren, mit dem die signatur erstellt wird. Der öffentlichen Schlüssel dient dann zum Check.

• Wer darf eine Mail für diese Domain verschicken? –> SPF (=Sender Policy Framework):
  In diesem Eintrag wird festgelegt, wer, also welche IP-Nummern, für eine Domain Mails verschicken darf. Im Beispiel: Der Ziel-Mailserver bekommt eine Mail, die laut „From“ von voelligegal@kux.de kommt. Dabei kennt der Ziel-Mailserver aber auch die IP-Nummer des Absender-Mailservers. Nun fragt der Ziel-Mailserver die DNS-Einträge zu kux.de ab: Wenn darin ein SPF-Eintrag vorhanden ist, hat kux.de definiert, welche IP-Nummern Mails in seinem Namen verschicken dürfen. D .h. wenn der Ziel-Mailserver feststellt, dass die IP-Nummer des Absender-Mailservers nicht in der SPF-Liste enthalten ist, besteht der Verdacht, dass der Absender-Mailserver „eigentlich“ nicht berechtigt ist, @kux.de Mails zu verschicken.
  Wie in soclhen fällen zu verfahen ist, ist auch im SPF-Eintrag der Absender-Domain definiert: Der SPF-Eintrag im DNS besteht aus einer Liste von „Qualifikatoren“  (IP-Nummer) und einem „Mechanismus“ (was soll passieren, wenn
  Beispiel: v=spf1 a:mailbox.org -all
  Das bedeutet:  Es gibt zwei Einträge, die von links nach rechts abgearbeitet werden. Eintrag 1 ist „a:mailbox.org“m bzw. genauer „+a:mailbox.org“.  D. h. wenn die IP-Nummer des Absenders im A-Record von „mailbox.org“ enthalten ist, wird die Mail („+“) als „PASS“ eingestuft. Der zweite Eintrag ist „-all“, das bedeutet, dass alle („all“) anderen IP-Nummern „-„, d. h. „FAIL“, sind.
  Wichtig ist: Was der Ziel-Mailserver mit dieser SPF-Information macht, ist damit nicht festgelegt.
  Probleme bzgl. SPF: Wenn Mails umgeleitet werden, wird auf die IP-Nummer des umleitenden Mailservers geprüft. Diese ist ggf. nicht in SPF enthalten und eine Mail wird falsch eingestuft.
• Was soll der Empfänger tun? –> DMARC (=Domain-based Message Authentication, Reporting and Conformance)
  Mit DMARC wird in der Absender-Domain festgelegt, wie diese Domain geprüft werden soll und was bei einem Fehler passieren soll. D. h. wenn eine Mail bei SPF und / oder DKIM „durchfällt“,
  Beispiel: v=DMARC1;p=quarantine;
  Das bedeutet:  Die Policy („p“) ist es, „durchgefallene“ Mails in Quarantäne zu schicken, d .h. als Spam zu kennzeichnen.