Granikos Technology Blog

Thomas Stensitzki | MVP
Thomas Stensitzki | MVP

MVP LogoThomas Stensitzki is a leading technology consultant focusing on the Microsoft messaging and collaboration technologies and the owner of Granikos GmbH & Co. KG.

He is an MVP for Office Apps & Services since 2018.

Thomas is an MCT Regional Lead for Germany and delivers Microsoft Learning training courses for Office 365, Microsoft Teams, and Exchange Server.

He holds Master certifications as Microsoft Certified Solutions Master Messaging and as Microsoft Certified Master for Exchange Server 2010. His experience makes him a subject matter expert for any messaging topic related to Microsoft Exchange, Exchange Online, Office 365, and Hybrid configurations.

Buch Cover Microsoft Exchange Server 2019 - Das Handbuch für AdministratorenBuch Cover Microsoft 365 Business Premium - Migration und Konfiguration

Podcast #MVPbuzzChat with Thomas Stensitzki

Follow Thomas on LinkedIn or Twitter

His sessions:

MVP Blog:
Personal blog:
Personal website: 
Thomas' Tech Talk:

Contact Thomas at


On September 14, 2016
This is a translated blog post of the original post in German, which can be read here.

Different technologies are used to verify the validity of email senders. Each technology by itself represents only one component of a holistic solution. It is currently recommended to implement all three technologies.

The technologies are:

  • SPF - Sender Policy Framework
    The SPF resource record of a DNS zone defines which servers (hostnames or IP addresses) are allowed to send emails on behalf of the domain. Each sender domain must have it's own SPF resource record.
  • DKIM - Domain Keys Identified Mail
    DKIM pursues the same objective as SPF. With DKIM parts of an email, messages are encrypted using a private key. The public key is published as a DNS resource record. In most cases, the key pair is generated by the mail servers, as these encrypt the message anyway.
  • DMARC - Domain-based Message Authentication, Reporting & Conformance
    DMARC is placed on top of SPF and DKIM. DMARC executes a so-called alignment for SPF and DKIM. An alignment defines a policy that describes how strict a receiving server (MTA) should validate and assess the sender address with SPF and DKIM. Stefan Cink of Net at Work has published a detailed post (DE) on this.


The following figure illustrates the protocol relations.

DMARC, SPC and DKIM relations

The use of SPF, DKIM, and DMARC are no substitute for email message encryption itself or transport encryption. These technologies are used to identify and asses valid senders and to protect against spam messages.

Keep in mind that SPF, DKIM, and DMARC are offerings for other emails servers. As a sending party, you do not control if and how SPF, DKIM, and DMARC are evaluated by the receiving server. But if evaluated, the configuration must be correct to avoid messages being rejected by receiving email servers.

The following sections focus on the DNS configuration for SPF, DKIM, and DMARC. This post is not intended to rate the technologies, but to describe the implementation.



Each domain is used for sending emails requires an SPF resource record (RR) in its DNS zone. An SPF record is always of the type TXT and does not use any hostname (or resource record name, if you will). An SPF RR is always valid for the entire DNS zone.

Example          3600     IN      TXT     "v=spf1 mx ?all"

The following screenshot illustrates adding a new SPF TXT record in a common DNS management interface (DE) of an internet provider. The hostname textbox remains empty.

Anlegen eines SPF TXT DNS Eintrages

Example explained:

SPF Version

MX server records defined within the DNS zone are valid senders
The additional DNS hostname defined as A resource record is a valid sender as well

Neutral validation of non listed servers that send emails for this domain

SPF records can be created by using one of the various online resources.



DKIM resource records are configured as TXT resource records as well. In contrast to an SPF record, a hostname is mandatory. In this case its called selector.

A DKIM TXT record is always created as a record in the subdomain _domainkey.

Example 3600 IN     TXT     "v=DKIM1\; k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQChZM8yjegaKfd0ssKyezTW/7xbDSNc0uPd50xa5/ecerv1v3mHKM+T7mClzRmIEx+Ji6AisVeo2uvjTYPemHFMBlQpuS/4zc2QxWHqp62FSQ7lASBOzDfUrIwayPVqwSPD6NrnfVSWoUNrFGGSVeU5uLASecBzTfxPukqTHgYKhQIDAQAB"

The following screenshot illustrates adding a new DKIM TXT record in a common DNS management interface (DE) of an internet provider. The hostname textbox contains the selector nsp followed by the subdomain _domainkey.

Anlegen eines DKIM TXT DNS Eintrages

Example explained:

DKIM version

Public key encryption method

The DKIM public key



DMARC is configured as a TXT resource record as well. The DMARC resource record uses the fixed hostname _dmarc.

Example     3600    IN      TXT     "v=DMARC1\; p=none\;\;\; fo=1\; adkim=s\; aspf=s\; rf=afrf\"

The following screenshot illustrates adding a new DMARC TXT record in a common DNS management interface (DE) of an internet provider. The hostname textbox contains always the value _dmarc.

Anlegen eines DMARC TXT DNS Eintrages

Example explained:

DMARC version

No DMARC policy defined (You should always start with None, before switching to Quarantine or Reject)
Email address for status reports
Email address for error reports

Error report type

DKIM alignment, s = strict

SPF alignment, s = strict

Error report message format, afrf = Abuse Report Format following RFC 5965

The DMARC policy (p) should be raised step-by-step. The results for each policy type are:

  • none - No action, affected messages are part of the daily message report
  • quarantine - Affected messages are marked as spam
  • reject - An affected message is rejected on the SMTP layer

Recommended reading on this topic: Google Support Post.

DMARC DNS zone entries can easily be checked by using the Net at Works PowerShell tool. The PowerShell script can only be used with NoSpamProxy11+. But there are some online tools available as well.



Do you need assistance with your Exchange Server setup? You have questions about your Exchange Server infrastructure and going hybrid with Office 365?

Contact us at or visit our website


Weiterlesen »
On September 13, 2016
Letzte Aktualisierung: 1. März 2020


Grafik E-MailProblem

Es gibt zahlreiche Gründe, warum externe Dienstanbieter E-Mails unter Verwendung einer E-Mail-Dömane eines Kunden senden. Beispielhafte Anwendungsfälle sind z.B.:

  • Marketingdienste zum Versand von Newslettern und anderen Nachrichten
  • Reisedienstleister, die das gesamte Reisemanagement für Kunden abwickeln
  • In der Cloud gehostete Geschäftslösungen für CRM, ERP o.ä.

Die Nutzung einer E-Mail Domäne, die ein Unternehmen bereits in Verwendung hat, birgt Risiken. Bei der Nutzung durch einen Marketing-Dienstleister, der hauptsächlich E-Mail-Nachrichten an externe Empfänger sendet, treten die Probleme noch nicht so deutlich hervor. Werden jedoch Dienste in Anspruch genommen, die eine Zustellung von E-Mail-Nachrichten an interne Mitarbeiter notwendig machen, kommt es zu Problemen.

Eine der einfachsten Funktionen im Rahmen des E-Mail-Grundschutzes ist die Abweisung von E-Mails, die eine eigene Domäne (Accepted oder Owned Domain) als Absender verwenden.

Das nachfolgende Schaubild verdeutlicht die Situation.

Blockierte E-Mail eines Dienstanbieters

Das Unternehmen in diesem Beispiel nutzt die E-Mail Domäne als primäre E-Mail-Domäne. Der Dienstanbieter nutzt die Adresse als Absenderadresse. E-Mail-Nachrichten an externe Empfänger können meist problemlos zugestellt werden, insofern der SPF-Eintrag des Dienstanbieters in der externen DNS-Zone eingetragen ist. Die E-Mail-Sicherheitslösung am Gateway verweigert jedoch die Annahme von E-Mail-Nachrichten an interne Empfänger, da nur interne Systeme unter der Domäne senden dürfen.

Am E-Mail-Gateway können natürlich Ausnahmen konfiguriert werden. Diese sind aber von Natur aus aufwändig in der Wartung und und sehr fehleranfällig.



Das Problem kann durch Nutzung von Subdomänen einfach und elegant gelöst werden.

Externe Dienstleister nutzen für den Versand von E-Mail-Nachrichten anstatt der Domäne die neu konfigurierte Subdomäne In der zur DNS-Zone der Subdomäne werden der zugehörige SPF-Eintrag des Dienstleisters und alle erforderlichen DKIM-Einträge verwaltet.

Das nachfolgende Schaubild verdeutlicht den Unterschied zum ersten Schaubild.

Erfolgreicher Empfang von E-Mails des Dienstanbieters


Das Unternehmen nutzt weiterhin die Domäne als primäre E-Mail-Domäne. Für externe Dienstanbieter wurde aber die Subdomäne eingerichtet. Somit versendet der externe Dienstanbieter in diesem Beispiel E-Mail-Nachrichten mit der Absenderadresse Für externe Empfänger ändert sich hierdurch nichts. Für das E-Mail-Sicherheitsgateway des Unternehmens ändert sich aber alles. Die Absenderdomäne ist ist eine vollwertige externe Domäne, die durch SPF und DKIM abgesichert wurde und entspricht keiner internen Domäne. Alle E-Mail-Nachrichten des Dienstanbieters werden angenommen und an interne Empfänger zugestellt.

Bei Bedarf kann für jeden externen Dienstanbieter eine separate Subdomäne konfiguriert werden. Dieses Vorgehen ist ein wenig aufwendiger, bietet jedoch ein verbesserte Kontrolle der DNS-Konfiguration.

Die nachfolgenden Präsentationen verdeutlichen die Problemstellung und die Lösungsmöglichkeiten.


Deutschsprachige Präsentation


Englischsprachige Präsentation


Richten Sie für externe Dienstanbieter, die unter Ihrer E-Mail-Domäne Nachrichten versenden sollen, immer Subdomänen ein. Für Unternehmen, die Office 365 und Exchange Online nutzen, ist die Empfehlung mit der beschriebenen Subdomänen-Konfiguration zu arbeiten. Ansonsten wird Exchange Online Protection (EOP) E-Mails von externen Dienstanbietern abweisen.





Gerne unterstützen wir Sie bei der Planung und Durchführung Ihrer Exchange Server Implementierung oder Migration.

Sie denken über einen vollständigen Wechsel zu Microsoft 365 oder eine Hybrid-Konfiguration mit Office 365 nach? Wir beraten Sie umfassend und neutral über die Möglichkeiten der Office 365 Plattform und Microsoft 365.

Sie möchten mehr über Exchange Server 2019 erfahren? Gerne erläutern wir Ihnen die technischen Änderungen und Chancen für Ihr Unternehmen in einem individuellen Workshop. Bis dahin, werfen Sie doch einen Blick in das Microsoft Exchange Server 2019: Das Handbuch für Administratoren.

Weitere Informationen zu unseren Dienstleistungen finden Sie auf unserer Website ( oder Sie kontaktieren direkt unser Vertriebsteam:

Foto von Miguel Á. Padriñán von Pexels.

Weiterlesen »

Die Dokumentation von Microsoft Azure ist einem steten Wandel unterworfen und die Verlinkungen der Informationsquellen ändern sich ähnlich agil.

Mark Grimes von Microsoft hat eine ausführliche Liste (Stichwort: Work in Progress) zusammengestellt, über die man zu (fast) allen Themenbereichen von MIcrosoft Azure den passenden Absprung findet.

Dieser Link gehört ab sofort ins Standardrepertoire, wenn man mit Microsoft Azure arbeitet.

Und sollte es dich mal in eine Sackgasse führen, dann einfach eine E-Mail an: Azure Shortcuts

Viel Spaß mit Microsoft Azure.



Weiterlesen »

Im Microsoft TechNet ist die Erstellung einer Office 365 Entwicklungs- und Testumgebung detailliert beschrieben. Nach der grundsätzlichen Einrichtung der Umgebung kann dort auch die Nutzung der Advanced Threat Protection (ATP) konfiguriert und demonstriert werden.

Advanced Threat Protection

Die E-Mail Sicherheitsfunktionen der Advanced Threat Protection sind im Office 365 E5 Plan enthalten. Für andere Office 365 Pläne kann ATP separat erworben werden.

Übersicht Advanced Threat Protection in Office 365

Mit Hilfe der Advanced Threat Protection können Unternehmensnetzwerke besser vor E-Mail Bedrohungen geschützt werden. Hierzu gehören:

  • Schutz vor unsicheren E-Mail-Anhängen durch Schadsoftware-Analyse in Echtzeit
  • Schutz vor E-Mail Links zu Inhalten, die ein Sicherheitsriskio darstellen

ATP ist als Ergänzung zur regulärem Exchange Online Protection (EOP) zu sehen.

ATP in der Entwicklungs- und Testumgebung

Die Einrichtung von ATP in der Entwicklungs- und Testumgebung erfolgt nach der Basiseinrichtung der Office 365 Entwicklungs- und Testumgebung und besteht aus folgenden Punkten:

  1. Standardmäßig stellt Exchange Online E-Mail Nachrichten mit einem möglicherweise schadhaften Anhang und einem Link zu einer schadhaften Webseite direkt ins Postfach eines Anwenders zu.
  2. Konfiguration einer neuen Richtlinie für "Sichere Anhänge" und einer Richtlinie für "Sichere Links" zur Blockierung des Zugriffes auf gefährliche Webseiten.
  3. Demonstration, das neue Nachrichten mit gefährlichen Anhängen und Links zu möglicherweise schadhaften Webseiten blockiert werden.

Nach der Einrichtung der Advanced Threat Protection können Sie noch weitere Richtlinien konfigurieren und deren Auswirkungen auf die E-Mail Zustellung testen.

Mehr über Advanced Threat Protection für Safe Attachments und Safe Links finden Sie hier:




Quelle Grafik: Microsoft

Weiterlesen »
The English version of this post can be read here.

Für die Prüfung von gültigen E-Mail Absendern stehen unterschiedliche Technologien zur Verfügung. Jede für sich genommen stellt aber nur einen Baustein einer Gesamtlösung dar. Nach aktuellem Standard ist die Empfehlung, alle drei Technologien zu implementieren.

Die Technologien sind:

  • SPF - Sender Policy Framework
    Mit Hilfe des SPF Eintrages in einer DNS Zone wird beschrieben, welche Serversysteme befugt sind, E-Mails im Namen der Domäne zu versenden. Werden E-Mails unter verschiedenen Absendedomänen versendet, so muss für jede Absenderdomäne ein SPF Eintrag konfiguriert werden.
  • DKIM - Domain Keys Identified Mail
    DKIM verfolgt das gleiche Ziel wie SPF. Jedoch wird bei DKIM ein Teil der E-Mail Informationen mit einem privaten Schlüssel verschlüsselt. Der öffentliche Schlüssel wird über die DNS Zone des E-Mail Absenders bereitgestellt. Die Schlüsselerstellung erfolgt heutzutage in den meisten Fällen direkt im E-Mail Server, da dieser auch die Verschlüsselung der Nachrichten durchführt.
  • DMARC - Domain-based Message Authentication, Reporting & Conformance
    DMARC setzt auf SPF und DKIM auf. DMARC führt ein sog. Alignment für SPF und DKIM durch. Dieses Alignment beschreibt eine Richtlinie, die festlegt, wie streng ein empfangender Mail-Server die Absenderinformationen gegen SPF und DKIM prüfen bzw. bewerten soll. Stefan Cink hat hierzu einen ausführlichen Artikel im Net at Work Blog verfasst.

Das nachfolgende Schaubild verdeutlicht die Relation der Protokolle zu einander.

Relationen von DMARC, SPC und DKIM

Die Konfiguration von SPF, DKIM und DMARC ist kein Ersatz für E-Mail Nachrichtenverschlüsselung oder eine Transportverschlüsselung bei der E-Mail Übertragung. Vielmehr mehr dienen die genannten drei Technologien der Erkennung und Bewertung von gültigen Absendern und stellen einen Schutzmechanismus vor Spam dar.

Man darf nicht vergessen, dass die Konfiguration der drei Technoligen nur ein Angebot für andere E-Mail Server darstellt. Als Absender hat man schlicht keine Kontrolle darüber, ob und wie SPF, DKIM oder DMARC von der empfangenden Seite ausgewertet werden. Werden sie aber ausgewertet, so müssen die Konfigurationen korrekt und fehlerfrei sein und keine Testeinträge mehr enthalten.

Die nachfolgenden Abschnitte beschreiben insbesondere die DNS Konfiguration für SPF, DKIM und DMARC. Dieser Blogeintrag stellt keine detaillierte Bewertung der drei Technologien dar, sondern beschreibt deren Implementierung.


Für jede Domäne, die E-Mails versendet, ist ein SPF Eintrag (Resource Record) in der DNS Zone einzutragen. Ein SPF Eintrag ist immer vom Typ TXT und nutzt keinen Hostnamen (oder Resource Record Namen). Er gilt immer für die gesamte zu betrachtende Zone.

Beispiel          3600     IN      TXT     "v=spf1 mx ?all"

Das nachfolgende Beispiel zeigt das Anlegen eines SPF TXT Eintrages in einer DNS Verwaltungsoberfläche eines Internet-Hosters. Das Textfeld für den Hostnamen bleibt leer.

Anlegen eines SPF TXT DNS Eintrages

Die im Beispiel verwendeten Einträge bedeuten:

Die SPF Version des Texteintrage

Die in der DNS Zone konfigurierten MX Servereinträge für eingehende E-Mails sind valide Sender
Der in der DNS Zone existierende A Resource Record ist ebenfalls an valider Sender

Neutrale Bewertung von nicht genannten Systemen, die ebenfalls E-Mails mit dieser Domäne senden

Die Erstellung der SPF Konfiguration erfolgt am einfachsten über einen der zahlreiche Online-Konfiguratoren. Diese werten bereits die aktuelle Konfiguration der DNS Zone aus.


Bei einem DKIM Eintrag erfolgt die Konfiguration ebenfalls über einen TXT Eintrag in der DNS Zone der Absenderdomäne. Im Gegensatz zum SPF Eintrag ist ein Name für den Resource Record verpflichtend. Im Zusammenhang mit DKIM spricht man hier vom einem Selektor.

Ein DKIM DNS Eintrag erfolgt immer unterhalb der DNS Subdomäne _domainkey.

Beispiel 3600 IN     TXT     "v=DKIM1\; k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQChZM8yjegaKfd0ssKyezTW/7xbDSNc0uPd50xa5/ecerv1v3mHKM+T7mClzRmIEx+Ji6AisVeo2uvjTYPemHFMBlQpuS/4zc2QxWHqp62FSQ7lASBOzDfUrIwayPVqwSPD6NrnfVSWoUNrFGGSVeU5uLASecBzTfxPukqTHgYKhQIDAQAB"

Das nachfolgende Beispiel zeigt das Anlegen eines DKIM TXT Eintrages in einer DNS Verwaltungsoberfläche eines Internet-Hosters. Das Textfeld für den Hostnamen enthält den Selektor nsp und die Subdomäne _domainkey.

Anlegen eines DKIM TXT DNS Eintrages

Die im Beispiel verwendeten Einträge bedeuten:

Die DKIM Version des DNS Eintrages

Verschlüsselungsmethode des öffentlichen Schlüssels

Der öffentliche Schlüssel des DKIM Schlüsselpaares


Die Konfiguration von DMARC erfolgt ebenfalls über einen TXT Eintrag in der DNS Zone der absendenden Domäne. Für die Konfiguration wird der definierte Resource Record Name _dmarc verwendet.

Beispiel     3600    IN      TXT     "v=DMARC1\; p=none\;\;\; fo=1\; adkim=s\; aspf=s\; rf=afrf\"

Das nachfolgende Beispiel zeigt das Anlegen eines DMARC TXT Eintrages in einer DNS Verwaltungsoberfläche eines Internet-Hosters. Das Textfeld für den Hostnamen enthält immer den Namen _dmarc.

Anlegen eines DMARC TXT DNS Eintrages

Die im Beispiel verwendeten Einträge bedeuten:

Die DMARC Version des DNS Eintrages

Keine definierte Policy für DMARC (Dies sollte immer das Startszenario sein, bevor man zu Quarantine oder Reject wechselt)
E-Mail Adresse für aggregierte Statusberichte
E-Mail Adresse für Fehlerbericht

Definition der Art des Fehlerberichtes

Definition DKIM Prüfung, s = strict

Definiton der SPF Prüfung, s = strict

Nachrichtenformat des Fehlerberichtes, afrf = Abuse Report Format nach RFC 5965

Die Richtlinie (Policy, p) zur Auswertung und Reaktion sollte langsam gesteigert werden. Je Richtlinie sind die Ergebnisse wie folgt:

  • none - Keine Aktion, Betroffene Nachrichten werden nur im täglichen Bericht protokolliert
  • quarantine - Betroffene Nachrichten werden als Spam gekennzeichnet
  • reject - Die Nachricht wird auf SMTP Ebene zurückgewiesen

Sehr empfehlenswert zu diesem Thema ist ein Supportartikel von Google.

Für die Überprüfung der DNS Zoneneinträge kann das PowerShell Tool von Net at Work verwendet werden. Das PowerShell script kann nur mit NoSpamProxy 11 oder höher verwendet werden. Ebenso stehen zahlreiche Online-Tools zur Verfügung. Unten finden Sie direkt Verlinkungen zu den Tools von MXToolbox.



Sichern Sie Ihre E-Mail Kommunikation mit PGP oder S/MIME und nutzen Sie sichere E-Mail Verschlüsselung am Gateway mit NoSpamProxy Encryption. E-Mail Security Made in Germany.
Wir beraten Sie gerne:

Weiterlesen »