de-DEen-GB
 
rss

Granikos Technology Blog

Dies ist die deutschsprachige Version meines Blog Posts The Right Exchange Architecture im ESE Blog von ENow


 

Warum gibt es die Preferred Architecture?

Exchange Server ist ein sehr tolerantes Produkt und lässt sich in unterschiedlichste IT-Infrastruktur-Varianten installieren. Einige der möglichen Infrastruktur-Varianten sind gut geeignet für den Betrieb von Exchange Server, andere leider weniger gut. Daher ist es immens wichtig, bei der Planung einer Exchange Server Umgebung die notwendige Sorgfalt walten zu lassen.

Basis für die Planung einer Exchange Server Implementierung ist der Hauptgrundsatz für moderne Exchange Server Versionen:

Die Hochverfügbarkeit von Exchange Server wird auf der Applikationsebene umgesetzt.


Dieser Hauptgrundsatz wird, wie die Erfahunrg zeigt, leider allzu häufig ignoriert. Dieser Ignoranz wird in vielen Fällen dadurch Vorschub geleistet, dass Hard- und Software-Hersteller ihre ganz eigenen Hochverfügbarkeitslösung (HA) verkaufen möchten. Zu diesen Lösungen gehören sowohl HA-Funktionen von Hypervisor-Plattformen, aber auch, und dies viel häufiger, HA-Lösungsansätze von Storageanbietern.

Die Standardisierung einer Plattform wird nicht dadurch erreicht, indem eine unnötig komplexe Infrastruktur zum Standard erklärt wird, sondern das eine möglichst einfache Implementierung der Exchange Server Plattform zum Standard gemacht wird.

Unzählige Supportanfragen bei der Exchange Produktgruppe (PG) haben die Preferred Architecture Empfehlung über die Jahre reifen lassen. Sie ist daher keine spontan entstandene Empfehlung. Sie ist entstanden aus den Anforderungen und Kenntnisgewinnen im täglichen Betrieb der hochverfügbaren Cloudinfrastruktur von Exchange Online.

Sicherlich werden Sie nun einwenden, dass Sie keine Cloud-Plattform betreiben möchten. Sie dürfen nicht vergessen, dass eine moderne Exchange Server Version hochverfügbar betrieben werden möchte. Vergessen Sie daher nicht den Hauptgrundsatz für moderne Exchange Server Versionen ab Version 2013.

Die Hochverfügbarkeit von Exchange Server wird auf der Applikationsebene umgesetzt.


Auf der Microsoft Ignite Konferenz 2017 wurde in zahlreichen Vorträgen auf die Preferred Architecture Bezug genommen. Man konnte dem Eindruck erliegen, dass hier missioniert werden sollte. Am letzten Tag der Konferenz haben Boris Lokhvitsky und Robert Gillies eine sehr interessante Session zur richtigen Implementierung von Exchange Server gehalten. Hierbei wurde auch betrachtet, welche technischen Mindestanforderungen für eine Exchange Server Implementierung gelten und wie eine optimale Betriebsumgebung aussieht. Ein optimaler Betrieb einer On-Premises Implementierung folgt der Preferred Architecture. Ist dies nicht möglich sollte man sich für einen Wechsel zu Exchange Online entscheiden.

Das nachfolgende Diagramm verdeutlicht die unterschiedlichen Design-Optionen für eine Messaging-Plattform auf Basis von Exchange Server 2016.

Do Exchange Right

Was bedeutet das nun im Detail für eine erfolgreiche Exchange Server Implementierung?

  • Standardisiert
    Exchange Online bietet eine standardisierte Nutzung von Exchange Server Funktionen im Rahmen des Software-as-a-Service Angebotes von Office 365. Hierbei nutzen Sie nur die Funktionen von Exchange und haben keinerlei direkten Zugriff auf die Server Systeme. Die gesamte Verwaltung des Betriebssystems und das Patchen von Exchange Server führt Microsoft für Sie durch. Sie können sich so ganz auf die Konfiguration Ihrer Exchange Online Organisation oder aber den Hybrid-Verbund mit Ihrer lokalen Exchange Organisation konzentrieren.
     
  • Strukturiert
    Die strukturierte Implementierung einer Exchange Server Plattform folgt der Preferred Architecture der Exchange Produktgruppe oder der Product Line Architecture, basierend auf den Empfehlungen und Erkenntnissen von Microsoft Architekten. Eine solche Implementierung ist, ebenso wie die Nutzung von Exchange Online, als Lösung für einen optimalen Betrieb anzusehen. Wie sich die Preferred Architecture im Detail darstellt wird weiter unten beschrieben.
     
  • Empfohlen
    Eine On-Premises Exchange Server Implementierung, die den Best Practices folgt, weicht in signifikanten Punkten von der Preferred Architecture ab und bietet trotzdem einen sicheren und stabilen Betrieb. Eine solche Abweichung ist z.B. der Betrieb auf einem Hypervisor, jedoch unter Anwendung der Betriebsparameter für den Betrieb von Exchange Server auf physikalischen Systemen (Stichwort: feste Ressourcenzuweisung). Der Exchange Server Best Practices Analyzer ist eine Click-To-Run Applikation, die direkt aus dem Exchange Admin Center einer On-Premises Implementierung heraus aufgerufen werden kann. Alternativ kann hierzu auch das Exchange Analyzer Script von Paul Cunningham aus der TechNet Gallery verwendet werden.
     
  • Unterstützt
    Eine unterstützte Implementierung von Exchange Server weicht in zahlreichen Punkten von der Preferred Architecture ab, bewegt sich aber immer noch im durch Microsoft unterstützten Betrieb. Solch ein unterstützter Betrieb folgt den Exchange Server Systemanforderungen und den Exchange Server Speicherkonfigurationsoptionen. Diese Art der Implementierung ist als absolutes Mindestmaß anzusehen.
     
  • Funktioniert (irgendwie)
    Natürlich kann man Exchange Server auch irgendwie zum Laufen bringen. Dies ist die letzte Kategorie. In diese Kategorie fallen Einzelserver Implementierungen unter Verwendung von redundanten Speichersystemen oder der grundsätzlich Betrieb von Exchange Server mit nicht unterstützten Speichersystemen (siehe Exchange Server Speicherkonfigurationsoptionen). In diesem Bereich fallen aber auch Exchange Server Implementierung auf AWS oder Microsoft Azure ohne Premium Storage. Ihre produktive Exchange Server Plattform sollte nicht zu dieser letzten Kategorie gehören, da Sie ansonsten ein unnötig hohes Betriebsrisiko eingehen.

 

Was ist die Preferred Architecture?

Was ist nun die viel zitierte Preferred Architecture und was bedeutet sie für eine erfolgreiche On-Premises Implementierung und den sicheren Betrieb von Exchange Server.

Die Preferred Architecture ist kein starres Gebilde. Vielmehr passt sie sich regelmäßig den technischen Gegebenheiten an. Zuletzt wurde z.B. die Empfehlung für den maximalen Arbeitsspeicher je Server von 96GB auf 192GB angehoben.

Nachfolgend werden die vier Bereiche der Preferred Architecture beschrieben. Ich empfehle aber dringend, immer auf den aktualisierten EHLO Blog Artikel Bezug zu nehmen und sich noch einmal mit der Exchange Server 2016 Architektur vertraut zu machen.

Die Preferred Architecture gliedert sich in die folgenden vier Bereiche:

  • Namensraum-Design
  • Rechenzentrumsdesign
  • Server-Design
  • DAG-Design

Namensraum-Design

Der Exchange Namensraum (Namespace) beschreibt die DNS Hostnamen, die erforderlich sind, damit sich Clients (z.B. Outlook, Browser oder mobile Endgeräte) mit den Exchange Servern verbinden können. Im Rahmen des Data Center Designs (s.u.) wird davon ausgegangen, dass diese Verbindungen auf zwei Standorte verteilt werden. 

Bei der Planung der Exchange Server Namensräume (Namespaces) unterscheidet man zwischen gebundenen (bound) und ungebundenen (unbound) Namensräumen für Exchange Server in zwei Rechenzentren.

Bei einem gebundenen Namensraum besitzt jedes Rechenzentrum einen eindeutigen Namen für den Zugriff auf Exchange Server Client Access Services. Clientverbindungen erfolgen somit immer zu dem Rechenzentrum, in dem sich auch die aktive Datenbankkopie des angefragten Benutzerpostfaches befindet.

Bei einem ungebunden Namensraum verfügen die Rechenzentren über keine eigenen Namen für den Zugriff auf Exchange Server Client Access Services. Clientverbindungen werden bei jeder Anfrage durch den Load Balancer in eines der beiden Rechenzentren geleitet. Eine Ausnahme bilden hier die Office Online Server (OOS), die immer einen gebundenen Namensraum erfordern.

Das nachfolgende Beispiel für eine Preferred Architecture Namespace Design benötigt vier Namen:

  1. AutoDiscover Endpunkt: autodiscover.varunagroup.de
  2. Client Endpunkt für alle Exchange Dienste: mail.varunagroup.de
  3. Office Online Server Endpunkt Rechenzentrum A: oos-a.varunagroup.de
  4. Office Online Server Endpunkt Rechenzentrum B: oos-b.varunagroup.de

Exchange Server Preferred Architecture Design
 

Rechenzentrumsdesign

Eine hochverfügbare und ausfallsichere Architektur erfordert den Betrieb von mindestens zwei Rechenzentren. Ob es sich nun um vollwertige und eigenständige Rechenzentren oder um lokale Serverräume in getrennten Brandabschnitte im gleichen Gebäude handelt, lasse ich hier bewusst offen. Die Anforderungen zur Verfügbarkeit von IT-Basisdiensten hängen schließlich nicht nur von einer Exchange Server Implementierung ab.

Eine wichtige Anforderung ergibt sich aber für den Betrieb des Active Directory in der Preferred Architecture.

Der über zwei Rechenzentren gestreckte Betrieb einer einzelnen Active Directory Site wird zwar technisch unterstützt, für die Preferred Architecture ist es aber empfohlen, dass jedes Rechenzentrum in einer eigenen Active Directory Site abgebildet wird. Die Gründe dafür sind:

  • Die Funktionen für einen ausfallsicheren Betrieb des E-Mail Transports mit Shadow Redundancy und Saftety Net
  • Der Active Directory Design Empfehlung folgend müssen Netzwerkesegmente mit einer Gesamtlaufzeit von mehr als 10ms in separaten Active Directory Site platziert werden

Server-Design

In der Preferred Architecture werden alle Exchange Server mit Postfachrolle als physikalische Systeme betrieben. Die Hauptgründe hierfür sind:

  • Jeder Server ist für eine 80% Auslastung bei größtmöglichem Ausfallszenario berechnet
  • Virtualisierung stellt eine zusätzliche Komplexität im Falle einer Wiederherstellung dar, die keinerlei Vorteil bringt (siehe auch Hauptgrundsatz von Exchange Server)

Die physikalischen Server, die für eine Preferred Architecture Implementierung verwendet werden, haben keine allzu besonderen Anforderungen. Solch ein Standard-Server besteht aus:

  • 2HE Server, Dual-Sockel mit 20-24 Prozessorkernen
  • Maximal 192GB Arbeitsspeicher
  • Festplattencontroller mit Batterie-abgesichertem Schreib-Cache
  • 12 oder mehr Festplatteneinschübe im Servergehäuse

Die weiteren Konfigurationen des Servers sind:

  • Einzelner RAID1 Verbund aus zwei Festplatten für das Betriebssystem, Exchange Server Installation, Protokolldateien und Transportdatenbanken
  • Alle weiteren SAS Festplatten sind als JBOD konfiguriert
  • Dateisystem für Datenlaufwerke ist ReFS
  • Schutz der Daten durch BitLocker Festplattenverschlüsselung
  • Absicherung gegen Festplattenausfall durch DAG AutoReseed

 

DAG-Design

Um eine optimale Nutzung der Systemressourcen im ungebundenen Namensraummodell zu gewährleisten, werden die aktiven Kopien der Datenbanken gleichmäßig (symmetrisch) über alle Mitgliedsserver der Database Availability Group (DAG) verteilt. Die maximal 16 Mitgliedsserver einer DAG werden ebenfalls symmetrisch, mit einer geraden Anzahl an Servern je Rechenzentrum über alle Rechenzentren verteilt.

Durch mehr Mitgliedsservern in einer DAG wird eine bessere Redundanz und Nutzung der Ressourcen sichergestellt. Die Preferred Architecture sieht vor, dass eine DAG aus mindestens acht Mitgliedsservern besteht. Bei einem steigenden Ressourcenbedarf wird die DAG um weitere Mitgliedsserver erweitert. 

DAG Netzwerkdesign

In der Preferred Architecture benötigt Exchange Server für einen sicheren Betrieb nur eine einzelne Netzwerkschnittstelle. Diese Netzwerkschnittstelle wird ohne Teaming betrieben. Diese vereinfachte Netzwerkanforderung erleichtert den Betrieb und auch die Wiederherstellung im absoluten Fehlerfall. Eine separate Heartbeat-Netzwerkschnittstelle für die Cluster-Kommunikation ist nicht erforderlich.

Witness Server

Der Witness Server einer DAG gewährleistet das korrekte Verhalten der DAG bei einem automatischen Failover, sollte es zu einem Ausfall eines Rechenzentrums kommen. Im Idealfall wird der Witness Server an einem dritten Standort in einer anderen Active Directory Site platziert. Sollte kein dritter Standort zur Verfügung stehen, so kann der Witness Server auch in Microsoft Azure betrieben werden.

 

Zusammenfassung

Was ist nun die richtige Exchange Server Architektur?

Wenn Sie der Preferred Architecture (Blauer Kreis) oder aber der Best Practice Empfehlung (Lila Kreis) folgen, können Sie einen sicheren Betrieb der E-Mail Plattform in Ihrem Unternehmen gewährleisten, ohne unnötige technische Risiken einzugehen. Jenseits einer Nutzung von Exchange Online stellen diesen beiden Design-Optionen das Optimum für einen zuverlässigen Betrieb dar. Je weiter Sie sich von der Preferred Architecture für Exchange Server entfernen, um so mehr steigt das Betriebsrisiko.

Wenn Sie den vollmundigen Produktversprechen von Drittherstellern für Speicherlösungen oder anderen faszinierenden Lösungen zur Hochverfügbarkeit von Exchange Server folgen, so verabschieden SIe sich in eine individuelle "funktioniert irgendwie" Implementierung. Tritt bei solch einer Implementierung ein Fehlerfall auf, so liegt das Problem nicht beim Produkt Exchange Server. Die Erfahrung hat leider gezeigt, dass in solchen Fällen immer von Unzulänglichkeiten in der Implementierung abgelenkt wird.

Als absolute Mindestempfehlung gilt eine Exchange Server Implementierung, die den Exchange Server Systemanforderungen und den Exchange Server Speicherkonfigurationsoptionen folgt.


Abkürzungen

  • PA | Preferred Architecture
  • PLA Product Line Architecture

Links

 

Viel Spaß beim Betrieb von Exchange Server.

 

Weiterlesen »

Anfang Juli habe ich einen Workshop zum Thema Planung und Implementierung eines Upgrade zu Exchange Server 2016 gehalten. 

Die im Workshop verwendte Präsentation steht seit heute bei Slideshare zum Download bereit. Neben dem technischen Teil gab es auch Themenblöcke mit freier Diskussion. Diese sind natürlich nicht Bestandteil der Präsentation.

 

Viel Spaß mit Exchange Server 2016.

 


Sie benötigen Hilfe bei der Planung und Installation Ihrer Exchange Server Plattform? Sie haben Fragen über Ihre bestehende Exchange Server Infrastruktur und möchten Exchange Online implementieren? Kontaktieren Sie uns per E-Mail info@granikos.eu oder besuchen Sie unsere Webseite http://www.granikos.eu

 

 

Weiterlesen »
Dies ist die deutschsprachige Version des Originalartikels Enabling Kerberos Authentication Fails vom 3. Juli 2017

 

Die Aktivierung der Kerberos Authentifizierung für Exchange Server 2013/2016 wird in diversen Artikeln im Internet beschrieben. In diesem Blogartikel geht es heute um ein Phänomen, das mir in einer Exchange Server 2013 Umgebung (8 Server DAG) begegnet ist. 

Alle Outlook 2010 Clients verwenden OutlookAnywhere für den Exchange Server Zugriff aus dem internen Netz. MAPI over Http ist sowohl auf der Organisationsebene als auch auf Postfachebene deaktiviert, da noch ein Problem mit der Kompatibilität einer Drittanbietersoftware existiert.

Problem

Nach der Aktivierung der Kerberos Authentifizierung verwenden alle Outlook Clients weiterhin nur die NTLM Authentifizierung, um sich am OutlookAnywhere Endpunkt anzumelden. Und dies, obwohl die Schritt-für-Schritt Anleitung aus dem TechNet befolgt wurde. Kerberos war für die Outlook Clients kein Thema. 

Ein Blick in die Übersicht des Outlook Verbindungsstatus (Strg + Rechter Mausklick auf des Outllok Symbol im System Tray) zeigt die Verwendung von NTLM.

Outlook nutzt weiterhin NTLM als Authentifizierungsanbieter

Grund

Die Umstellung der Authentifizerung auf Kerberos für OutlookAnywhere erfolgt auf jedem CAS Server über das folgende PowerShell Cmdlet:

Get-OutlookAnywhere -Server CASSERVER | Set-OutlookAnywhere -InternalClientAuthenticationMethod  Negotiate

Alle acht Exchange 2013 Server boten auch nach gebotener Zeit keine Nego Authentifizierung an. Die Überprüfung der OutlookAnywhere Konfiguration mit Hilfe der PowerShell zeigte die korrekten Konfigurationswerte. Aber was nun?

Ein Kontrolle der Authentifizerungseinstellungen für das \Rpc virtuelle Verzeichnis der Front End Website in der IIS Management Console zeigte, dass das virtuelle Verzeichnis nur für NTLM konfiguriert war.

OutlookAnywhere im Front End verwendet nur NTLM

 

Lösung

Mit Hilfe der IIS Management Console wurde der Negotiate Authentifizierungsanbieter hinzugefügt in der Reihenfolge der Anbieter an die erste Stelle gesetzt..

Negotiate zur Anbieterliste hinzufügen

Negotiate als ersten Anbieter konfigurieren

Nach Anpassung der Authentifizierungsanbieter in der Front End Wesbite können sich Outlook Clients mit Kerberos Authentifizerung an den OutlookAnywhere Endpunkt verbinden.

Outlook Verbindungsstatus zeigt Negotiate als Authentifizierungsanbieter

Hinweis

Im Normalfall sollte die IIS Management Console nicht für die Konfiguration der virtuellen Verzeichnisse einer Exchange Server INstallation verwendet werden. Die Anpassung der Konfigurationen mit Hilfe IIS MMC sollte nur im Troubleshooting-Fall verwendet werden, wenn einem unerklärliche Phänomene begegnen.

Die bevorzugte Methode zur Konfiguration von Exchange Server Einstellungen für virtuelle Verzeichnisse ist die Exchange Management Shell.

Links

Weiterhin viel Spaß mit Exchange Server

 

 

Weiterlesen »

Exchange Server 2007 Exchange Server 2010 Exchange Server 2013 Exchange Server 2016Microsoft hat die Exchange Updates für das 4. Quartal 2016 veröffentlicht.

Für den Betrieb von Exchange Server 2016 auf Windows Server 2016 wurde ein Knowledge Base Artikel veröffentlicht. Bei einer Installation von Exchenge auf Windows Server 2016 ist die Installation des Fixes zwingend. Das Setup wird ohne die Installation des Fixes nicht fortfahren.

Der Einsatz von .NET Framework 4.6.2 ist für die Q4 2016 Cumulative Updates noch optional, jedoch dringend empfohlen. Für die kommenden Cumulative Updates wird das .NET Framework 4.6.2 allerdings verpflichtend sein.

Die einzelnen Updates für Exchange:

Bei einem Hybrid Betrieb mit Office 365 und Exchange Server 2013/2016 muss entweder das jeweils das aktuelle CU oder nur das vorherige CU installiert sein. Dies entspricht dem N-1 Ansatz.

Für einen reinen On-Premises Betrieb von Exchange Server 2013/2016 gilt N-2. Es wird jeweils das aktuelle CU und die beiden letzten Vorversionen unterstützt.

Links

 

 

Weiterlesen »
On September 14, 2016
1167 Views
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 technolgy by itself represents only one component of an holistic solution. It is currently recommended to implemtent all three technologies.

The technologies are:

  • SPF - Sender Policy Framework
    The SPF resource record of a DNS zone defines which servers (host names 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 message are enrypted using a provivate key. The public key is published as a DNS resource record. In the most cases the key pair ist generated by the mail servers, as these encrpyt 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 desribe the implementation.

 

SPF

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

Example

mcsmemail.de.          3600     IN      TXT     "v=spf1 mx a:mail.mcsmemail.de ?all"

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

Anlegen eines SPF TXT DNS Eintrages

Example explained:

v=spf1
SPF Version

mx
MX server records defined within the DNS zone are valid senders

a:mail.mcsmemail.de
The additional DNS host name defined as a A resource record is a valid sender as well

?all
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

DKIM resource records are configured as TXT resource records as well. In contract to a SPF record a host name is mandatory. In this case its called selector.

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

Example

nsp._domainkey.mcsmemail.eu. 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 host name textbox contains the selector nsp followed by the sub domain _domainkey.

Anlegen eines DKIM TXT DNS Eintrages

Example explained:

v=DKIM1
DKIM version

k=rsa
Public key encryption method

p=MIGfMA....
The DKIM public key

 

DMARC

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

Example

_dmarc.mcsmemail.de.     3600    IN      TXT     "v=DMARC1\; p=none\; rua=mailto:DMARCRUA@mcsmemail.de\; ruf=mailto:DMARCRUF@mcsmemail.de\; 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 host name textbox contains always the value _dmarc.

Anlegen eines DMARC TXT DNS Eintrages

Example explained:

v=DMARC1
DMARC version

p=none
No DMARC policy defined (You should always start with None, before switching to Quarantine or Reject)

rua=mailto:DMARCRUA@mcscmemail.de
Email address for status reports

ruf=mailto:DMARCRUF@mcscmemail.de
Email address for error reports

fo=1
Error report type

adkim=s
DKIM alignment, s = strict

aspf=s
SPF alignment, s = strict

rf=afrf
Error report message format, afrf = Abuse Report Format nach 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 an only be used with NoSpamProxy11+. But there are some online tools available as well.

Links

 


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 office365@granikos.eu or visit our website http://www.granikos.eu.

Weiterlesen »