DMARC: Wie man seinen E-Mail-Ruf schützt
Vogel
13.04.2016
1 min read
Wichtige Erkenntnisse
DMARC hilft, Ihre Domain vor Phishing, Spoofing und unbefugter E-Mail-Nutzung zu schützen, indem Sie Ihre Authentifizierungsmethoden veröffentlichen und eine spezifische Behandlung für fehlgeschlagene Nachrichten anfordern.
Es funktioniert zusammen mit SPF und DKIM, um die Domain-Ausrichtung sicherzustellen und zu verhindern, dass betrügerische Mails Ihren Absender-Ruf schädigen.
Starke DMARC-Richtlinien unterstützen höheres Vertrauen, höhere Engagement-Raten und zukunftssichern Ihre Domain, da das Ökosystem auf domänenbasierte Reputationsmodelle umstellt.
DMARC-Validierungsprüfungen basieren auf der Domain-Ausrichtung zwischen der From-Domain, Return-Path-Domain (SPF) und der DKIM-Signaturdomain.
Das Einrichten von DMARC erfordert den Empfang von Berichten, das Verständnis von Aggregat- vs. forensischen Daten und das Konfigurieren von Tools zu deren Analyse.
Sie beginnen mit einer sicheren p=none Richtlinie, um den Verkehr zu überwachen, bevor Sie zu quarantine oder reject übergehen.
Das Veröffentlichen eines DMARC-Eintrags erfordert die Erstellung eines DNS TXT-Eintrags unter _dmarc.ihredomain.com mit Richtlinien, Berichtsadressen und optionalen Parametern wie Rollout-Prozentsätzen.
Richtige Berichts-Mailboxen (aggregiert + forensisch) und Analysetools sind entscheidend, um die Compliance zu überwachen, Spoofing zu erkennen und sicherzustellen, dass die Ausrichtung korrekt ist.
DMARC erfordert eine der folgenden Bestätigungen, um zu bestehen: ausgerichtetes SPF oder ausgerichtetes DKIM.
Die Implementierung von DMARC stärkt die E-Mail-Sicherheit und spielt eine Schlüsselrolle in der Markenintegrität, im Vertrauen und in der langfristigen Zustellbarkeit.
Q&A Highlights
Was ist DMARC und warum ist es wichtig?
DMARC (Domain-based Message Authentication, Reporting, and Conformance) ist eine im DNS veröffentlichte Richtlinie, die Ihre Domain vor Spoofing und Phishing schützt, indem sie die Domain-Ausrichtung erzwingt und durch Berichterstattung Transparenz ermöglicht.
Ist DMARC ein Authentifizierungsprotokoll?
Nein. DMARC ist nicht selbst die Authentifizierung—es stützt sich auf SPF und DKIM, um E-Mails zu authentifizieren und verwendet Richtlinien + Berichterstattung, um zu steuern, wie empfangende Server bei Ausfällen damit umgehen.
Worauf prüft DMARC?
Es überprüft:
SPF-Authentifizierung + Ausrichtung
DKIM-Authentifizierung + Ausrichtung
Ein Absender benötigt nur eine dieser Methoden, um DMARC erfolgreich zu bestehen.
Was ist „domain alignment“?
Es ist die Anforderung, dass die sichtbare From-Domäne entweder strikt übereinstimmt oder dieselbe organisatorische Domäne teilt (entspannt) mit entweder der SPF Return-Path-Domäne oder der DKIM-Signaturdomäne.
Warum verbessert DMARC die Zustellbarkeit?
Weil Postfachanbieter authentifizierten, ausgerichteten Domains mehr vertrauen. DMARC verhindert, dass gefälschte Nachrichten Ihren Ruf schädigen, und verbessert die Zustellung in den Posteingang für legitime E-Mails.
Was ist der Unterschied zwischen aggregierten und forensischen DMARC-Berichten?
Aggregierte Berichte (RUA): XML-Zusammenfassungen der Authentifizierungsergebnisse über den gesamten Datenverkehr.
Forensische Berichte (RUF): Einzelne Beispiele für fehlgeschlagene Nachrichten zur tieferen Analyse.
Welche Mailboxen benötige ich, bevor ich DMARC veröffentliche?
Sie sollten zwei Adressen erstellen, wie zum Beispiel:
agg_reports@yourdomain.com (RUA)
afrf_reports@yourdomain.com (RUF)
Dadurch bleiben Berichtsströme getrennt und leichter zu analysieren.
Mit welcher DMARC-Richtlinie sollte ich beginnen?
Beginnen Sie immer mit p=none. Es überwacht die Authentifizierungsaktivität, ohne die Zustellung zu beeinträchtigen, sodass Sie Abstimmungsprobleme und Spoofing-Versuche sicher erkennen können.
Welche DMARC-Richtlinien sind verfügbar?
keine: nur überwachen
Quarantäne: fehlgeschlagene Nachrichten als Spam senden
ablehnen: fehlgeschlagene Nachrichten vollständig blockieren
Wo veröffentliche ich einen DMARC record?
In Ihrem DNS bei:
_dmarc.yourdomain.com
Es muss ein TXT-Eintrag sein, der Ihre Richtlinie, Version und Meldeendpunkte angibt.
Wie sieht ein grundlegender DMARC-Eintrag aus?
Beispiel:
v=DMARC1; p=none; rua=mailto:agg_reports@yourdomain.com; ruf=mailto:afrf_reports@yourdomain.com; pct=100
Was passiert, wenn DMARC fehlschlägt?
Der empfangende Server wendet Ihre angeforderte Richtlinie (none, quarantine, reject) an, obwohl die endgültige Handhabung letztendlich beim Anbieter liegt. Eine strikte Richtlinie kann Phishing-Versuche, die Ihre Domain verwenden, erheblich reduzieren.
In diesem Beitrag erklären wir Ihnen alles, was Sie wissen müssen, um DMARC zu nutzen, um Ihre E-Mail-Reputation zu schützen, und geben Ihnen Hinweise, wie Sie es für Ihre Domains einrichten können.
Ein effektives Werkzeug zur Bekämpfung von Fraudulent Mail
Oft werden die E-Mail-Authentifizierungsprotokolle SPF und DKIM im gleichen Atemzug erwähnt, DMARC, oder Domain-based Message Authentication, Reporting, and Conformance, ist jedoch kein Authentifizierungsprotokoll an sich. Stattdessen besteht der Zweck von DMARC darin, uns als Domainbesitzer zu erlauben, unseren E-Mail-Ruf zu schützen, indem:
E-Mail-Authentifizierungspraktiken angekündigt werden,
eine Behandlung für E-Mails angefordert wird, die die Authentifizierungsprüfungen nicht bestehen, und
Berichte über E-Mails eingeholt werden, die vorgeben, von der Domäne zu stammen.
DMARC kann ein effektives Werkzeug für uns sein, um betrügerische E-Mails zu bekämpfen, die unsere Domainverwendung ins Visier nehmen (z.B. Phishing und Spoofing), und kann bei unseren Empfängern ein höheres Vertrauen in unsere E-Mails fördern. Für Organisationen, die eine Ende-zu-Ende-Verschlüsselung über die Authentifizierung hinaus benötigen, bietet die Implementierung von S/MIME mit effizienten Methoden zur Sammlung von Empfänger-Public-Keys zusätzliche Sicherheitsschichten. Dieses höhere Vertrauen sollte wiederum zu einer höheren Interaktion mit unseren E-Mails führen, und E-Mails, die geöffnet und Klicks generieren, treiben den Umsatz und führen zu einer höheren ROI für unsere E-Mail-Kampagnen.
Zusätzlich zum Schutz unserer Domain erwarten wir, dass die Implementierung von DMARC jetzt eine hervorragende Möglichkeit zur „Zukunftssicherung“ unserer Domain sein wird. Hier bei Bird sind wir der Meinung, dass mit dem Übergang der Branche zu IPv6 fast sicher von einem IP-basierten Reputationsmodell auf ein Domain-basiertes Reputationsmodell umgestellt wird. Ein Domain-basiertes Reputationsmodell erfordert eine Domain-basierte Authentifizierung, und DMARC, in Verbindung mit DKIM und SPF, wird Domains helfen, einen Domain-basierten Ruf zu etablieren, lange bevor dies unbedingt notwendig sein könnte.
In diesem Beitrag werden wir Ihnen alles erklären, was Sie über die Nutzung von DMARC wissen müssen, um Ihren E-Mail-Ruf zu schützen, und Ihnen Hinweise geben, wie Sie es für Ihre Domains einrichten können.
Oft werden die E-Mail-Authentifizierungsprotokolle SPF und DKIM im gleichen Atemzug erwähnt, DMARC, oder Domain-based Message Authentication, Reporting, and Conformance, ist jedoch kein Authentifizierungsprotokoll an sich. Stattdessen besteht der Zweck von DMARC darin, uns als Domainbesitzer zu erlauben, unseren E-Mail-Ruf zu schützen, indem:
E-Mail-Authentifizierungspraktiken angekündigt werden,
eine Behandlung für E-Mails angefordert wird, die die Authentifizierungsprüfungen nicht bestehen, und
Berichte über E-Mails eingeholt werden, die vorgeben, von der Domäne zu stammen.
DMARC kann ein effektives Werkzeug für uns sein, um betrügerische E-Mails zu bekämpfen, die unsere Domainverwendung ins Visier nehmen (z.B. Phishing und Spoofing), und kann bei unseren Empfängern ein höheres Vertrauen in unsere E-Mails fördern. Für Organisationen, die eine Ende-zu-Ende-Verschlüsselung über die Authentifizierung hinaus benötigen, bietet die Implementierung von S/MIME mit effizienten Methoden zur Sammlung von Empfänger-Public-Keys zusätzliche Sicherheitsschichten. Dieses höhere Vertrauen sollte wiederum zu einer höheren Interaktion mit unseren E-Mails führen, und E-Mails, die geöffnet und Klicks generieren, treiben den Umsatz und führen zu einer höheren ROI für unsere E-Mail-Kampagnen.
Zusätzlich zum Schutz unserer Domain erwarten wir, dass die Implementierung von DMARC jetzt eine hervorragende Möglichkeit zur „Zukunftssicherung“ unserer Domain sein wird. Hier bei Bird sind wir der Meinung, dass mit dem Übergang der Branche zu IPv6 fast sicher von einem IP-basierten Reputationsmodell auf ein Domain-basiertes Reputationsmodell umgestellt wird. Ein Domain-basiertes Reputationsmodell erfordert eine Domain-basierte Authentifizierung, und DMARC, in Verbindung mit DKIM und SPF, wird Domains helfen, einen Domain-basierten Ruf zu etablieren, lange bevor dies unbedingt notwendig sein könnte.
In diesem Beitrag werden wir Ihnen alles erklären, was Sie über die Nutzung von DMARC wissen müssen, um Ihren E-Mail-Ruf zu schützen, und Ihnen Hinweise geben, wie Sie es für Ihre Domains einrichten können.
Oft werden die E-Mail-Authentifizierungsprotokolle SPF und DKIM im gleichen Atemzug erwähnt, DMARC, oder Domain-based Message Authentication, Reporting, and Conformance, ist jedoch kein Authentifizierungsprotokoll an sich. Stattdessen besteht der Zweck von DMARC darin, uns als Domainbesitzer zu erlauben, unseren E-Mail-Ruf zu schützen, indem:
E-Mail-Authentifizierungspraktiken angekündigt werden,
eine Behandlung für E-Mails angefordert wird, die die Authentifizierungsprüfungen nicht bestehen, und
Berichte über E-Mails eingeholt werden, die vorgeben, von der Domäne zu stammen.
DMARC kann ein effektives Werkzeug für uns sein, um betrügerische E-Mails zu bekämpfen, die unsere Domainverwendung ins Visier nehmen (z.B. Phishing und Spoofing), und kann bei unseren Empfängern ein höheres Vertrauen in unsere E-Mails fördern. Für Organisationen, die eine Ende-zu-Ende-Verschlüsselung über die Authentifizierung hinaus benötigen, bietet die Implementierung von S/MIME mit effizienten Methoden zur Sammlung von Empfänger-Public-Keys zusätzliche Sicherheitsschichten. Dieses höhere Vertrauen sollte wiederum zu einer höheren Interaktion mit unseren E-Mails führen, und E-Mails, die geöffnet und Klicks generieren, treiben den Umsatz und führen zu einer höheren ROI für unsere E-Mail-Kampagnen.
Zusätzlich zum Schutz unserer Domain erwarten wir, dass die Implementierung von DMARC jetzt eine hervorragende Möglichkeit zur „Zukunftssicherung“ unserer Domain sein wird. Hier bei Bird sind wir der Meinung, dass mit dem Übergang der Branche zu IPv6 fast sicher von einem IP-basierten Reputationsmodell auf ein Domain-basiertes Reputationsmodell umgestellt wird. Ein Domain-basiertes Reputationsmodell erfordert eine Domain-basierte Authentifizierung, und DMARC, in Verbindung mit DKIM und SPF, wird Domains helfen, einen Domain-basierten Ruf zu etablieren, lange bevor dies unbedingt notwendig sein könnte.
In diesem Beitrag werden wir Ihnen alles erklären, was Sie über die Nutzung von DMARC wissen müssen, um Ihren E-Mail-Ruf zu schützen, und Ihnen Hinweise geben, wie Sie es für Ihre Domains einrichten können.
Begriffe zum Kennenlernen
Bevor wir mit dem Einrichten von DMARC für Ihre Domain beginnen, möchten wir sicherstellen, dass wir die gleiche Sprache sprechen. Lassen Sie uns einige Begriffe definieren, die wir im weiteren Verlauf dieses Dokuments verwenden werden.
RFC5322.From Domain
Die RFC5322.FromDomain ist der Domain-Teil der E-Mail-Adresse, der normalerweise vom Empfänger unserer E-Mail beim Lesen gesehen wird. Im folgenden Beispiel ist die RFC5322.From-Domain „joesbaitshop.com“
From: Joe’s Bait and Tackle <sales@joesbaitshop.com>
DKIM d= Domain
DKIM ist ein Authentifizierungsprotokoll, das es einer Domain ermöglicht, die Verantwortung für eine Nachricht auf eine Weise zu übernehmen, die vom Empfänger der Nachricht validiert werden kann; dies geschieht durch die Verwendung kryptographischer Signaturen, die in die Kopfzeilen der Nachricht eingefügt werden, wenn sie ihren Ursprungsort verlässt. Diese Signaturen sind im Wesentlichen Momentaufnahmen dessen, wie die Nachricht zu diesem Zeitpunkt aussah, und der Empfänger kann diese Momentaufnahmen verwenden, um zu sehen, ob die Nachricht unverändert an ihrem Ziel angekommen ist. Der Prozess der Erstellung und Einfügung dieser Momentaufnahmen wird als DKIM-Signierung bezeichnet, und die Domain, die Verantwortung für die Nachricht übernimmt, indem sie sie signiert, fügt ihren Namen in einem Schlüssel-Wert-Tag als „d=signingDomain“ in die Kopfzeile ein und wird daher als DKIM d= Domain bezeichnet.
Return-Path Domain
Die Return-Path-Domain, manchmal auch als RFC5321. From Domain oder Mail From Domain bezeichnet, ist die Domain, an die Rückläufer weitergeleitet werden; es ist auch die Domain, auf der SPF-Überprüfungen während der E-Mail-Transaktion durchgeführt werden. Diese Domain wird normalerweise nicht vom Empfänger gesehen, es sei denn, der Empfänger ist clever genug, um alle Kopfzeilen einer bestimmten Nachricht zu betrachten.
Standardmäßig wird bei allen E-Mails, die über bird.com gesendet werden, birdmail.com als Return-Path-Domain verwendet, wie im folgenden Beispiel:
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
Um DMARC für Ihre Domain zum Laufen zu bringen, sollten Sie jedoch eine benutzerdefinierte Rückläuferdomain verwenden, die mit derselben Domain wie Ihre Absenderdomain endet, z.B. bounces.yourdomain.com, wenn Sie yourdomain.com als Ihre Absenderdomain verwenden.
Organizational Domain
Der Begriff „Organizational Domain“ bezieht sich auf die Domain, die bei einem Registrar eingereicht wurde, um die Anwesenheit der Domain im Internet zu schaffen. Für Bird sind unsere Organizational Domains bird.com und birdmail.com.
Domain Alignment
Der letzte Begriff in Bezug auf DMARC, den es zu verstehen gilt, ist „Domain Alignment“, und es gibt ihn in zwei Varianten: „relaxt“ und „streng“.
Relaxed Domain Alignment
Es wird gesagt, dass zwei Domains ein relaxtes Domain-Alignment haben, wenn ihre Organizational Domains gleich sind. Zum Beispiel haben a.mail.bird.com und b.foo.bird.com ein relaxtes Domain-Alignment aufgrund ihrer gemeinsamen Organizational Domain bird.com.
Strict Domain Alignment
Zwei Domains befinden sich in einem strengen Domain-Alignment, wenn und nur wenn sie identisch sind. So befinden sich foo.bird.com und foo.bird.com in einem strengen Alignment, da die beiden Domains identisch sind. Dagegen befinden sich foo.bird.com und bar.foo.bird.com nur in einem relaxten Alignment.
DMARC Domain Alignment Anforderungen
Damit DMARC-Validierungsprüfungen bestehen, erfordert DMARC, dass eine Domain-Alignment wie folgt erfolgt:
Für SPF müssen die RFC5322.From-Domain und die Return-Path-Domain im Alignment sein
Für DKIM müssen die RFC5322.From-Domain und die DKIM d= Domain im Alignment sein
Das Alignment kann entspannt oder streng sein, basierend auf der veröffentlichten Richtlinie der sendenden Domain.
Bevor wir mit dem Einrichten von DMARC für Ihre Domain beginnen, möchten wir sicherstellen, dass wir die gleiche Sprache sprechen. Lassen Sie uns einige Begriffe definieren, die wir im weiteren Verlauf dieses Dokuments verwenden werden.
RFC5322.From Domain
Die RFC5322.FromDomain ist der Domain-Teil der E-Mail-Adresse, der normalerweise vom Empfänger unserer E-Mail beim Lesen gesehen wird. Im folgenden Beispiel ist die RFC5322.From-Domain „joesbaitshop.com“
From: Joe’s Bait and Tackle <sales@joesbaitshop.com>
DKIM d= Domain
DKIM ist ein Authentifizierungsprotokoll, das es einer Domain ermöglicht, die Verantwortung für eine Nachricht auf eine Weise zu übernehmen, die vom Empfänger der Nachricht validiert werden kann; dies geschieht durch die Verwendung kryptographischer Signaturen, die in die Kopfzeilen der Nachricht eingefügt werden, wenn sie ihren Ursprungsort verlässt. Diese Signaturen sind im Wesentlichen Momentaufnahmen dessen, wie die Nachricht zu diesem Zeitpunkt aussah, und der Empfänger kann diese Momentaufnahmen verwenden, um zu sehen, ob die Nachricht unverändert an ihrem Ziel angekommen ist. Der Prozess der Erstellung und Einfügung dieser Momentaufnahmen wird als DKIM-Signierung bezeichnet, und die Domain, die Verantwortung für die Nachricht übernimmt, indem sie sie signiert, fügt ihren Namen in einem Schlüssel-Wert-Tag als „d=signingDomain“ in die Kopfzeile ein und wird daher als DKIM d= Domain bezeichnet.
Return-Path Domain
Die Return-Path-Domain, manchmal auch als RFC5321. From Domain oder Mail From Domain bezeichnet, ist die Domain, an die Rückläufer weitergeleitet werden; es ist auch die Domain, auf der SPF-Überprüfungen während der E-Mail-Transaktion durchgeführt werden. Diese Domain wird normalerweise nicht vom Empfänger gesehen, es sei denn, der Empfänger ist clever genug, um alle Kopfzeilen einer bestimmten Nachricht zu betrachten.
Standardmäßig wird bei allen E-Mails, die über bird.com gesendet werden, birdmail.com als Return-Path-Domain verwendet, wie im folgenden Beispiel:
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
Um DMARC für Ihre Domain zum Laufen zu bringen, sollten Sie jedoch eine benutzerdefinierte Rückläuferdomain verwenden, die mit derselben Domain wie Ihre Absenderdomain endet, z.B. bounces.yourdomain.com, wenn Sie yourdomain.com als Ihre Absenderdomain verwenden.
Organizational Domain
Der Begriff „Organizational Domain“ bezieht sich auf die Domain, die bei einem Registrar eingereicht wurde, um die Anwesenheit der Domain im Internet zu schaffen. Für Bird sind unsere Organizational Domains bird.com und birdmail.com.
Domain Alignment
Der letzte Begriff in Bezug auf DMARC, den es zu verstehen gilt, ist „Domain Alignment“, und es gibt ihn in zwei Varianten: „relaxt“ und „streng“.
Relaxed Domain Alignment
Es wird gesagt, dass zwei Domains ein relaxtes Domain-Alignment haben, wenn ihre Organizational Domains gleich sind. Zum Beispiel haben a.mail.bird.com und b.foo.bird.com ein relaxtes Domain-Alignment aufgrund ihrer gemeinsamen Organizational Domain bird.com.
Strict Domain Alignment
Zwei Domains befinden sich in einem strengen Domain-Alignment, wenn und nur wenn sie identisch sind. So befinden sich foo.bird.com und foo.bird.com in einem strengen Alignment, da die beiden Domains identisch sind. Dagegen befinden sich foo.bird.com und bar.foo.bird.com nur in einem relaxten Alignment.
DMARC Domain Alignment Anforderungen
Damit DMARC-Validierungsprüfungen bestehen, erfordert DMARC, dass eine Domain-Alignment wie folgt erfolgt:
Für SPF müssen die RFC5322.From-Domain und die Return-Path-Domain im Alignment sein
Für DKIM müssen die RFC5322.From-Domain und die DKIM d= Domain im Alignment sein
Das Alignment kann entspannt oder streng sein, basierend auf der veröffentlichten Richtlinie der sendenden Domain.
Bevor wir mit dem Einrichten von DMARC für Ihre Domain beginnen, möchten wir sicherstellen, dass wir die gleiche Sprache sprechen. Lassen Sie uns einige Begriffe definieren, die wir im weiteren Verlauf dieses Dokuments verwenden werden.
RFC5322.From Domain
Die RFC5322.FromDomain ist der Domain-Teil der E-Mail-Adresse, der normalerweise vom Empfänger unserer E-Mail beim Lesen gesehen wird. Im folgenden Beispiel ist die RFC5322.From-Domain „joesbaitshop.com“
From: Joe’s Bait and Tackle <sales@joesbaitshop.com>
DKIM d= Domain
DKIM ist ein Authentifizierungsprotokoll, das es einer Domain ermöglicht, die Verantwortung für eine Nachricht auf eine Weise zu übernehmen, die vom Empfänger der Nachricht validiert werden kann; dies geschieht durch die Verwendung kryptographischer Signaturen, die in die Kopfzeilen der Nachricht eingefügt werden, wenn sie ihren Ursprungsort verlässt. Diese Signaturen sind im Wesentlichen Momentaufnahmen dessen, wie die Nachricht zu diesem Zeitpunkt aussah, und der Empfänger kann diese Momentaufnahmen verwenden, um zu sehen, ob die Nachricht unverändert an ihrem Ziel angekommen ist. Der Prozess der Erstellung und Einfügung dieser Momentaufnahmen wird als DKIM-Signierung bezeichnet, und die Domain, die Verantwortung für die Nachricht übernimmt, indem sie sie signiert, fügt ihren Namen in einem Schlüssel-Wert-Tag als „d=signingDomain“ in die Kopfzeile ein und wird daher als DKIM d= Domain bezeichnet.
Return-Path Domain
Die Return-Path-Domain, manchmal auch als RFC5321. From Domain oder Mail From Domain bezeichnet, ist die Domain, an die Rückläufer weitergeleitet werden; es ist auch die Domain, auf der SPF-Überprüfungen während der E-Mail-Transaktion durchgeführt werden. Diese Domain wird normalerweise nicht vom Empfänger gesehen, es sei denn, der Empfänger ist clever genug, um alle Kopfzeilen einer bestimmten Nachricht zu betrachten.
Standardmäßig wird bei allen E-Mails, die über bird.com gesendet werden, birdmail.com als Return-Path-Domain verwendet, wie im folgenden Beispiel:
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
Um DMARC für Ihre Domain zum Laufen zu bringen, sollten Sie jedoch eine benutzerdefinierte Rückläuferdomain verwenden, die mit derselben Domain wie Ihre Absenderdomain endet, z.B. bounces.yourdomain.com, wenn Sie yourdomain.com als Ihre Absenderdomain verwenden.
Organizational Domain
Der Begriff „Organizational Domain“ bezieht sich auf die Domain, die bei einem Registrar eingereicht wurde, um die Anwesenheit der Domain im Internet zu schaffen. Für Bird sind unsere Organizational Domains bird.com und birdmail.com.
Domain Alignment
Der letzte Begriff in Bezug auf DMARC, den es zu verstehen gilt, ist „Domain Alignment“, und es gibt ihn in zwei Varianten: „relaxt“ und „streng“.
Relaxed Domain Alignment
Es wird gesagt, dass zwei Domains ein relaxtes Domain-Alignment haben, wenn ihre Organizational Domains gleich sind. Zum Beispiel haben a.mail.bird.com und b.foo.bird.com ein relaxtes Domain-Alignment aufgrund ihrer gemeinsamen Organizational Domain bird.com.
Strict Domain Alignment
Zwei Domains befinden sich in einem strengen Domain-Alignment, wenn und nur wenn sie identisch sind. So befinden sich foo.bird.com und foo.bird.com in einem strengen Alignment, da die beiden Domains identisch sind. Dagegen befinden sich foo.bird.com und bar.foo.bird.com nur in einem relaxten Alignment.
DMARC Domain Alignment Anforderungen
Damit DMARC-Validierungsprüfungen bestehen, erfordert DMARC, dass eine Domain-Alignment wie folgt erfolgt:
Für SPF müssen die RFC5322.From-Domain und die Return-Path-Domain im Alignment sein
Für DKIM müssen die RFC5322.From-Domain und die DKIM d= Domain im Alignment sein
Das Alignment kann entspannt oder streng sein, basierend auf der veröffentlichten Richtlinie der sendenden Domain.
Wie DMARC funktioniert, um Ihre E-Mail-Reputation zu schützen
Wenn wir von einem Postfachanbieter oder einer anderen Domain sprechen, die "DMARC überprüft", "DMARC validiert" oder "DMARC-Richtlinie anwendet", meinen wir, dass die Domain, die eine Nachricht empfängt, die folgenden Schritte durchführt:
Ermitteln Sie die RFC5322.From-Domain der Nachricht
Schauen Sie die DMARC-Richtlinie dieser Domain im DNS nach
Führen Sie die DKIM-Signaturvalidierung durch
Führen Sie die SPF-Validierung durch
Überprüfen Sie die Domain-Ausrichtung
Wenden Sie die DMARC-Richtlinie an
Damit eine Nachricht die DMARC-Validierung besteht, muss sie nur eine der beiden Authentifizierungs- und Ausrichtungsüberprüfungen bestehen. Eine Nachricht wird die DMARC-Validierung bestehen, wenn eines der folgenden zutrifft:
Die Nachricht besteht die SPF-Prüfungen und die RFC5322.From-Domain und die Return-Path-Domain sind in Ausrichtung, oder
Die Nachricht besteht die DKIM-Validierung und die RFC5322.From-Domain und die DKIM d= Domain sind in Ausrichtung, oder
Beide der oben genannten sind wahr
Wenn wir von einem Postfachanbieter oder einer anderen Domain sprechen, die "DMARC überprüft", "DMARC validiert" oder "DMARC-Richtlinie anwendet", meinen wir, dass die Domain, die eine Nachricht empfängt, die folgenden Schritte durchführt:
Ermitteln Sie die RFC5322.From-Domain der Nachricht
Schauen Sie die DMARC-Richtlinie dieser Domain im DNS nach
Führen Sie die DKIM-Signaturvalidierung durch
Führen Sie die SPF-Validierung durch
Überprüfen Sie die Domain-Ausrichtung
Wenden Sie die DMARC-Richtlinie an
Damit eine Nachricht die DMARC-Validierung besteht, muss sie nur eine der beiden Authentifizierungs- und Ausrichtungsüberprüfungen bestehen. Eine Nachricht wird die DMARC-Validierung bestehen, wenn eines der folgenden zutrifft:
Die Nachricht besteht die SPF-Prüfungen und die RFC5322.From-Domain und die Return-Path-Domain sind in Ausrichtung, oder
Die Nachricht besteht die DKIM-Validierung und die RFC5322.From-Domain und die DKIM d= Domain sind in Ausrichtung, oder
Beide der oben genannten sind wahr
Wenn wir von einem Postfachanbieter oder einer anderen Domain sprechen, die "DMARC überprüft", "DMARC validiert" oder "DMARC-Richtlinie anwendet", meinen wir, dass die Domain, die eine Nachricht empfängt, die folgenden Schritte durchführt:
Ermitteln Sie die RFC5322.From-Domain der Nachricht
Schauen Sie die DMARC-Richtlinie dieser Domain im DNS nach
Führen Sie die DKIM-Signaturvalidierung durch
Führen Sie die SPF-Validierung durch
Überprüfen Sie die Domain-Ausrichtung
Wenden Sie die DMARC-Richtlinie an
Damit eine Nachricht die DMARC-Validierung besteht, muss sie nur eine der beiden Authentifizierungs- und Ausrichtungsüberprüfungen bestehen. Eine Nachricht wird die DMARC-Validierung bestehen, wenn eines der folgenden zutrifft:
Die Nachricht besteht die SPF-Prüfungen und die RFC5322.From-Domain und die Return-Path-Domain sind in Ausrichtung, oder
Die Nachricht besteht die DKIM-Validierung und die RFC5322.From-Domain und die DKIM d= Domain sind in Ausrichtung, oder
Beide der oben genannten sind wahr
DMARC für Ihre Domain zum Laufen bringen
Nachdem wir die Mechanik von DMARC erklärt haben, sprechen wir darüber, wie wir DMARC für uns arbeiten lassen können. Dies umfasst die folgenden drei Schritte:
Vorbereitungen treffen, um DMARC-Berichte zu empfangen
Entscheiden, welche DMARC-Richtlinie für Ihre Domain verwendet werden soll
Veröffentlichen Ihres DMARC-Datensatzes
Wir werden jeden dieser Punkte im Detail unten abdecken, aber wir sagen Ihnen gleich, dass Schritt 1 oben etwa 95% Ihrer Vorbereitungszeit in Anspruch nehmen wird.
Nachdem wir die Mechanik von DMARC erklärt haben, sprechen wir darüber, wie wir DMARC für uns arbeiten lassen können. Dies umfasst die folgenden drei Schritte:
Vorbereitungen treffen, um DMARC-Berichte zu empfangen
Entscheiden, welche DMARC-Richtlinie für Ihre Domain verwendet werden soll
Veröffentlichen Ihres DMARC-Datensatzes
Wir werden jeden dieser Punkte im Detail unten abdecken, aber wir sagen Ihnen gleich, dass Schritt 1 oben etwa 95% Ihrer Vorbereitungszeit in Anspruch nehmen wird.
Nachdem wir die Mechanik von DMARC erklärt haben, sprechen wir darüber, wie wir DMARC für uns arbeiten lassen können. Dies umfasst die folgenden drei Schritte:
Vorbereitungen treffen, um DMARC-Berichte zu empfangen
Entscheiden, welche DMARC-Richtlinie für Ihre Domain verwendet werden soll
Veröffentlichen Ihres DMARC-Datensatzes
Wir werden jeden dieser Punkte im Detail unten abdecken, aber wir sagen Ihnen gleich, dass Schritt 1 oben etwa 95% Ihrer Vorbereitungszeit in Anspruch nehmen wird.
Vorbereitung zum Empfang von DMARC Reports
Jede Domain, die eine DMARC-Richtlinie veröffentlicht, sollte zunächst darauf vorbereitet sein, Berichte über ihre Domain zu erhalten. Diese Berichte werden von jeder Domain generiert, die DMARC-Validierung durchführt und sieht, dass E-Mails angeblich von unserer Domain stammen, und sie werden uns mindestens täglich zugesandt. Die Berichte werden in zwei Formaten vorliegen:
Aggregierte Berichte, die XML-Dokumente sind, die statistische Daten darüber zeigen, wie viele E-Mails von der berichtenden Quelle gesehen wurden, welche Authentifizierungsergebnisse vorlagen und wie die Nachrichten vom Berichterstatter behandelt wurden. Aggregierte Berichte sind so konzipiert, dass sie maschinell analysiert werden können, wobei ihre Daten irgendwo gespeichert werden, um eine Gesamtverkehrsanalyse, die Prüfung der Nachrichtenströme unserer Domain und möglicherweise die Identifizierung von Trends bei Quellen nicht authentifizierter, potenziell betrügerischer E-Mails zu ermöglichen.
Forensische Berichte, die einzelne Kopien von Nachrichten sind, die die Authentifizierung nicht bestanden haben, jede eingeschlossen in einer vollständigen E-Mail-Nachricht mit einem Format namens AFRF. Die forensischen Berichte sollen vollständige Header und Nachrichtentexte enthalten, aber viele Berichterstatter entfernen oder redigieren einige Informationen aus Datenschutzgründen. Trotzdem kann der forensische Bericht nützlich sein, sowohl zur Problemlösung bei den Authentifizierungsproblemen unserer Domain als auch zur Identifizierung, aus URIs in den Nachrichtentexten, von bösartigen Domains und Websites, die verwendet werden, um die Kunden unseres Domaininhabers zu betrügen.
Die Vorbereitung zum Empfang dieser Berichte besteht zunächst darin, zwei Postfächer in unserer Domain zu erstellen, um diese Berichte zu bearbeiten, wie z.B. agg_reports@ourdomain.com und afrf_reports@ourdomain.com. Beachten Sie, dass diese Postfachnamen völlig beliebig sind und keine Anforderungen für die Benennung des lokalen Teils des Postfachs bestehen; wir können beliebige Namen wählen, sollten die beiden jedoch getrennt halten, um die Verarbeitung zu erleichtern.
Sobald die Postfachnamen ausgewählt und in unserer Domain erstellt wurden, besteht der nächste Schritt darin, Werkzeuge bereitzustellen, um diese Postfächer zu lesen und die Daten zu nutzen, insbesondere die aggregierten Datenberichte, die wiederum so konzipiert sind, dass sie maschinell analysiert werden, anstatt von einer Person gelesen zu werden. Die forensischen Berichte hingegen könnten einfach dadurch verwaltet werden, dass wir sie selbst lesen, aber unsere Fähigkeit dazu wird sowohl von unserer Mail-Client-Kompetenz abhängen, Nachrichten im AFRF-Format anzuzeigen, als auch vom Volumen der Berichte, die wir erhalten.
Obwohl es möglich ist, dass wir unsere eigenen Werkzeuge zur Verarbeitung von DMARC-Berichten schreiben, solange Bird solche Dienstleistungen für bird.com Kunden nicht bereitstellt (etwas, das wir in Betracht ziehen, aber noch nicht versprechen), empfehlen wir, dass wir bereits verfügbare Werkzeuge für diese Aufgabe nutzen.
Jede Domain, die eine DMARC-Richtlinie veröffentlicht, sollte zunächst darauf vorbereitet sein, Berichte über ihre Domain zu erhalten. Diese Berichte werden von jeder Domain generiert, die DMARC-Validierung durchführt und sieht, dass E-Mails angeblich von unserer Domain stammen, und sie werden uns mindestens täglich zugesandt. Die Berichte werden in zwei Formaten vorliegen:
Aggregierte Berichte, die XML-Dokumente sind, die statistische Daten darüber zeigen, wie viele E-Mails von der berichtenden Quelle gesehen wurden, welche Authentifizierungsergebnisse vorlagen und wie die Nachrichten vom Berichterstatter behandelt wurden. Aggregierte Berichte sind so konzipiert, dass sie maschinell analysiert werden können, wobei ihre Daten irgendwo gespeichert werden, um eine Gesamtverkehrsanalyse, die Prüfung der Nachrichtenströme unserer Domain und möglicherweise die Identifizierung von Trends bei Quellen nicht authentifizierter, potenziell betrügerischer E-Mails zu ermöglichen.
Forensische Berichte, die einzelne Kopien von Nachrichten sind, die die Authentifizierung nicht bestanden haben, jede eingeschlossen in einer vollständigen E-Mail-Nachricht mit einem Format namens AFRF. Die forensischen Berichte sollen vollständige Header und Nachrichtentexte enthalten, aber viele Berichterstatter entfernen oder redigieren einige Informationen aus Datenschutzgründen. Trotzdem kann der forensische Bericht nützlich sein, sowohl zur Problemlösung bei den Authentifizierungsproblemen unserer Domain als auch zur Identifizierung, aus URIs in den Nachrichtentexten, von bösartigen Domains und Websites, die verwendet werden, um die Kunden unseres Domaininhabers zu betrügen.
Die Vorbereitung zum Empfang dieser Berichte besteht zunächst darin, zwei Postfächer in unserer Domain zu erstellen, um diese Berichte zu bearbeiten, wie z.B. agg_reports@ourdomain.com und afrf_reports@ourdomain.com. Beachten Sie, dass diese Postfachnamen völlig beliebig sind und keine Anforderungen für die Benennung des lokalen Teils des Postfachs bestehen; wir können beliebige Namen wählen, sollten die beiden jedoch getrennt halten, um die Verarbeitung zu erleichtern.
Sobald die Postfachnamen ausgewählt und in unserer Domain erstellt wurden, besteht der nächste Schritt darin, Werkzeuge bereitzustellen, um diese Postfächer zu lesen und die Daten zu nutzen, insbesondere die aggregierten Datenberichte, die wiederum so konzipiert sind, dass sie maschinell analysiert werden, anstatt von einer Person gelesen zu werden. Die forensischen Berichte hingegen könnten einfach dadurch verwaltet werden, dass wir sie selbst lesen, aber unsere Fähigkeit dazu wird sowohl von unserer Mail-Client-Kompetenz abhängen, Nachrichten im AFRF-Format anzuzeigen, als auch vom Volumen der Berichte, die wir erhalten.
Obwohl es möglich ist, dass wir unsere eigenen Werkzeuge zur Verarbeitung von DMARC-Berichten schreiben, solange Bird solche Dienstleistungen für bird.com Kunden nicht bereitstellt (etwas, das wir in Betracht ziehen, aber noch nicht versprechen), empfehlen wir, dass wir bereits verfügbare Werkzeuge für diese Aufgabe nutzen.
Jede Domain, die eine DMARC-Richtlinie veröffentlicht, sollte zunächst darauf vorbereitet sein, Berichte über ihre Domain zu erhalten. Diese Berichte werden von jeder Domain generiert, die DMARC-Validierung durchführt und sieht, dass E-Mails angeblich von unserer Domain stammen, und sie werden uns mindestens täglich zugesandt. Die Berichte werden in zwei Formaten vorliegen:
Aggregierte Berichte, die XML-Dokumente sind, die statistische Daten darüber zeigen, wie viele E-Mails von der berichtenden Quelle gesehen wurden, welche Authentifizierungsergebnisse vorlagen und wie die Nachrichten vom Berichterstatter behandelt wurden. Aggregierte Berichte sind so konzipiert, dass sie maschinell analysiert werden können, wobei ihre Daten irgendwo gespeichert werden, um eine Gesamtverkehrsanalyse, die Prüfung der Nachrichtenströme unserer Domain und möglicherweise die Identifizierung von Trends bei Quellen nicht authentifizierter, potenziell betrügerischer E-Mails zu ermöglichen.
Forensische Berichte, die einzelne Kopien von Nachrichten sind, die die Authentifizierung nicht bestanden haben, jede eingeschlossen in einer vollständigen E-Mail-Nachricht mit einem Format namens AFRF. Die forensischen Berichte sollen vollständige Header und Nachrichtentexte enthalten, aber viele Berichterstatter entfernen oder redigieren einige Informationen aus Datenschutzgründen. Trotzdem kann der forensische Bericht nützlich sein, sowohl zur Problemlösung bei den Authentifizierungsproblemen unserer Domain als auch zur Identifizierung, aus URIs in den Nachrichtentexten, von bösartigen Domains und Websites, die verwendet werden, um die Kunden unseres Domaininhabers zu betrügen.
Die Vorbereitung zum Empfang dieser Berichte besteht zunächst darin, zwei Postfächer in unserer Domain zu erstellen, um diese Berichte zu bearbeiten, wie z.B. agg_reports@ourdomain.com und afrf_reports@ourdomain.com. Beachten Sie, dass diese Postfachnamen völlig beliebig sind und keine Anforderungen für die Benennung des lokalen Teils des Postfachs bestehen; wir können beliebige Namen wählen, sollten die beiden jedoch getrennt halten, um die Verarbeitung zu erleichtern.
Sobald die Postfachnamen ausgewählt und in unserer Domain erstellt wurden, besteht der nächste Schritt darin, Werkzeuge bereitzustellen, um diese Postfächer zu lesen und die Daten zu nutzen, insbesondere die aggregierten Datenberichte, die wiederum so konzipiert sind, dass sie maschinell analysiert werden, anstatt von einer Person gelesen zu werden. Die forensischen Berichte hingegen könnten einfach dadurch verwaltet werden, dass wir sie selbst lesen, aber unsere Fähigkeit dazu wird sowohl von unserer Mail-Client-Kompetenz abhängen, Nachrichten im AFRF-Format anzuzeigen, als auch vom Volumen der Berichte, die wir erhalten.
Obwohl es möglich ist, dass wir unsere eigenen Werkzeuge zur Verarbeitung von DMARC-Berichten schreiben, solange Bird solche Dienstleistungen für bird.com Kunden nicht bereitstellt (etwas, das wir in Betracht ziehen, aber noch nicht versprechen), empfehlen wir, dass wir bereits verfügbare Werkzeuge für diese Aufgabe nutzen.
Welche DMARC-Policy zu verwenden
Die DMARC-Spezifikation bietet drei Möglichkeiten für Domaininhaber, ihre bevorzugte Behandlung von E-Mails anzugeben, die die DMARC-Validierungsprüfungen nicht bestehen. Diese sind:
none, was bedeutet, die E-Mail gleich zu behandeln, als gäbe es keine DMARC-Validierungsprüfungen
quarantine, was bedeutet, die E-Mail anzunehmen, sie aber an einen anderen Ort als den Posteingang des Empfängers zu platzieren (typischerweise den Spam-Ordner)
reject, was bedeutet, die Nachricht gänzlich abzulehnen
Es ist wichtig zu beachten, dass der Domaininhaber eine solche Behandlung nur in seinem DMARC-Eintrag anfordern kann; es liegt am Empfänger der Nachricht, zu entscheiden, ob er die angeforderte Richtlinie einhält oder nicht. Einige werden dies tun, während andere möglicherweise etwas nachsichtiger sind, etwa indem sie E-Mails nur dann im Spam-Ordner platzieren, wenn die Richtlinie der Domain reject ist.
Wir empfehlen all unseren Kunden, mit einer Richtlinie von none zu beginnen, um sicherzugehen. Obwohl wir von unserer Fähigkeit überzeugt sind, Ihre E-Mails ordnungsgemäß durch DKIM-Signierung zu authentifizieren, ist es dennoch am besten, sich etwas Zeit zu nehmen, um Berichte über Ihre Domain zu prüfen, bevor Sie mit Ihrer DMARC-Richtlinie aggressiver werden.
Die DMARC-Spezifikation bietet drei Möglichkeiten für Domaininhaber, ihre bevorzugte Behandlung von E-Mails anzugeben, die die DMARC-Validierungsprüfungen nicht bestehen. Diese sind:
none, was bedeutet, die E-Mail gleich zu behandeln, als gäbe es keine DMARC-Validierungsprüfungen
quarantine, was bedeutet, die E-Mail anzunehmen, sie aber an einen anderen Ort als den Posteingang des Empfängers zu platzieren (typischerweise den Spam-Ordner)
reject, was bedeutet, die Nachricht gänzlich abzulehnen
Es ist wichtig zu beachten, dass der Domaininhaber eine solche Behandlung nur in seinem DMARC-Eintrag anfordern kann; es liegt am Empfänger der Nachricht, zu entscheiden, ob er die angeforderte Richtlinie einhält oder nicht. Einige werden dies tun, während andere möglicherweise etwas nachsichtiger sind, etwa indem sie E-Mails nur dann im Spam-Ordner platzieren, wenn die Richtlinie der Domain reject ist.
Wir empfehlen all unseren Kunden, mit einer Richtlinie von none zu beginnen, um sicherzugehen. Obwohl wir von unserer Fähigkeit überzeugt sind, Ihre E-Mails ordnungsgemäß durch DKIM-Signierung zu authentifizieren, ist es dennoch am besten, sich etwas Zeit zu nehmen, um Berichte über Ihre Domain zu prüfen, bevor Sie mit Ihrer DMARC-Richtlinie aggressiver werden.
Die DMARC-Spezifikation bietet drei Möglichkeiten für Domaininhaber, ihre bevorzugte Behandlung von E-Mails anzugeben, die die DMARC-Validierungsprüfungen nicht bestehen. Diese sind:
none, was bedeutet, die E-Mail gleich zu behandeln, als gäbe es keine DMARC-Validierungsprüfungen
quarantine, was bedeutet, die E-Mail anzunehmen, sie aber an einen anderen Ort als den Posteingang des Empfängers zu platzieren (typischerweise den Spam-Ordner)
reject, was bedeutet, die Nachricht gänzlich abzulehnen
Es ist wichtig zu beachten, dass der Domaininhaber eine solche Behandlung nur in seinem DMARC-Eintrag anfordern kann; es liegt am Empfänger der Nachricht, zu entscheiden, ob er die angeforderte Richtlinie einhält oder nicht. Einige werden dies tun, während andere möglicherweise etwas nachsichtiger sind, etwa indem sie E-Mails nur dann im Spam-Ordner platzieren, wenn die Richtlinie der Domain reject ist.
Wir empfehlen all unseren Kunden, mit einer Richtlinie von none zu beginnen, um sicherzugehen. Obwohl wir von unserer Fähigkeit überzeugt sind, Ihre E-Mails ordnungsgemäß durch DKIM-Signierung zu authentifizieren, ist es dennoch am besten, sich etwas Zeit zu nehmen, um Berichte über Ihre Domain zu prüfen, bevor Sie mit Ihrer DMARC-Richtlinie aggressiver werden.
Veröffentlichung Ihrer DMARC-Policy
Die DMARC-Richtlinie einer Domain wird durch die Veröffentlichung eines DNS TXT-Datensatzes an einem bestimmten Ort im DNS-Namensraum bekanntgegeben, nämlich „_dmarc.domainname.tld“ (beachten Sie den führenden Unterstrich). Ein grundlegender DMARC-Richtliniendatensatz für unsere Beispieldomain von zuvor, joesbaitshop.com, könnte in etwa so aussehen:
_dmarc.joesbaitship.com. IN TXT "v=DMARC1; p=none; rua=mailto:agg_reports@joesbait.com; ruf=mailto:afrf_reports@joesbait.com; pct=100"
Wenn wir diesen Datensatz aufschlüsseln, haben wir:
v=DMARC1 gibt die DMARC-Version an (1 ist derzeit die einzige Wahl)
p=none gibt die bevorzugte Behandlung oder DMARC-Richtlinie an
rua=mailto:agg_reports@joesbait.com ist das Postfach, an das aggregierte Berichte gesendet werden sollen
ruf=mailto:afrf_reports@joesbait.com ist das Postfach, an das forensische Berichte gesendet werden sollen
pct=100 ist der Prozentsatz der E-Mails, auf die der Domaininhaber seine Richtlinie anwenden möchte. Domains, die gerade erst mit DMARC beginnen, insbesondere solche, die wahrscheinlich ein hohes Berichtvolumen erzeugen, möchten möglicherweise mit einer viel niedrigeren Zahl beginnen, um zu sehen, wie ihre Prozess zur Handhabung von Berichten der Last standhalten.
Es gibt auch andere Konfigurationsoptionen, die ein Domaininhaber in seinem DMARC-Datensatz verwenden kann, aber die von uns bereitgestellten Tipps sollten ein guter Start sein.
Die DMARC-Richtlinie einer Domain wird durch die Veröffentlichung eines DNS TXT-Datensatzes an einem bestimmten Ort im DNS-Namensraum bekanntgegeben, nämlich „_dmarc.domainname.tld“ (beachten Sie den führenden Unterstrich). Ein grundlegender DMARC-Richtliniendatensatz für unsere Beispieldomain von zuvor, joesbaitshop.com, könnte in etwa so aussehen:
_dmarc.joesbaitship.com. IN TXT "v=DMARC1; p=none; rua=mailto:agg_reports@joesbait.com; ruf=mailto:afrf_reports@joesbait.com; pct=100"
Wenn wir diesen Datensatz aufschlüsseln, haben wir:
v=DMARC1 gibt die DMARC-Version an (1 ist derzeit die einzige Wahl)
p=none gibt die bevorzugte Behandlung oder DMARC-Richtlinie an
rua=mailto:agg_reports@joesbait.com ist das Postfach, an das aggregierte Berichte gesendet werden sollen
ruf=mailto:afrf_reports@joesbait.com ist das Postfach, an das forensische Berichte gesendet werden sollen
pct=100 ist der Prozentsatz der E-Mails, auf die der Domaininhaber seine Richtlinie anwenden möchte. Domains, die gerade erst mit DMARC beginnen, insbesondere solche, die wahrscheinlich ein hohes Berichtvolumen erzeugen, möchten möglicherweise mit einer viel niedrigeren Zahl beginnen, um zu sehen, wie ihre Prozess zur Handhabung von Berichten der Last standhalten.
Es gibt auch andere Konfigurationsoptionen, die ein Domaininhaber in seinem DMARC-Datensatz verwenden kann, aber die von uns bereitgestellten Tipps sollten ein guter Start sein.
Die DMARC-Richtlinie einer Domain wird durch die Veröffentlichung eines DNS TXT-Datensatzes an einem bestimmten Ort im DNS-Namensraum bekanntgegeben, nämlich „_dmarc.domainname.tld“ (beachten Sie den führenden Unterstrich). Ein grundlegender DMARC-Richtliniendatensatz für unsere Beispieldomain von zuvor, joesbaitshop.com, könnte in etwa so aussehen:
_dmarc.joesbaitship.com. IN TXT "v=DMARC1; p=none; rua=mailto:agg_reports@joesbait.com; ruf=mailto:afrf_reports@joesbait.com; pct=100"
Wenn wir diesen Datensatz aufschlüsseln, haben wir:
v=DMARC1 gibt die DMARC-Version an (1 ist derzeit die einzige Wahl)
p=none gibt die bevorzugte Behandlung oder DMARC-Richtlinie an
rua=mailto:agg_reports@joesbait.com ist das Postfach, an das aggregierte Berichte gesendet werden sollen
ruf=mailto:afrf_reports@joesbait.com ist das Postfach, an das forensische Berichte gesendet werden sollen
pct=100 ist der Prozentsatz der E-Mails, auf die der Domaininhaber seine Richtlinie anwenden möchte. Domains, die gerade erst mit DMARC beginnen, insbesondere solche, die wahrscheinlich ein hohes Berichtvolumen erzeugen, möchten möglicherweise mit einer viel niedrigeren Zahl beginnen, um zu sehen, wie ihre Prozess zur Handhabung von Berichten der Last standhalten.
Es gibt auch andere Konfigurationsoptionen, die ein Domaininhaber in seinem DMARC-Datensatz verwenden kann, aber die von uns bereitgestellten Tipps sollten ein guter Start sein.
Zusammenfassung
Es gibt viel in den obigen Informationen zu entpacken! Wir hoffen, dass Sie die Anleitung zur Erstellung eines DMARC-Policy-Datensatzes als hilfreich empfinden. Wir hoffen auch, dass unsere Erklärung, warum DMARC wichtig ist, dazu beiträgt, deutlich zu machen, warum Sie dieses wichtige Werkzeug zum Schutz Ihres E-Mail-Rufes verwenden sollten.
Natürlich ist dies kein vollständiges oder autoritatives Dokument zu diesem Thema. Wenn Sie tiefer eintauchen möchten oder mehr Hilfe benötigen, ist ein großartiger Ausgangspunkt das offizielle DMARC-FAQ. Und es versteht sich von selbst, dass das Bird support team bereit ist, Ihnen bei der Konfiguration Ihres Bird-Kontos für DMARC zu helfen.
Danke fürs Lesen – und beginnen Sie noch heute, Ihre Domains mit DMARC zu schützen!
Es gibt viel in den obigen Informationen zu entpacken! Wir hoffen, dass Sie die Anleitung zur Erstellung eines DMARC-Policy-Datensatzes als hilfreich empfinden. Wir hoffen auch, dass unsere Erklärung, warum DMARC wichtig ist, dazu beiträgt, deutlich zu machen, warum Sie dieses wichtige Werkzeug zum Schutz Ihres E-Mail-Rufes verwenden sollten.
Natürlich ist dies kein vollständiges oder autoritatives Dokument zu diesem Thema. Wenn Sie tiefer eintauchen möchten oder mehr Hilfe benötigen, ist ein großartiger Ausgangspunkt das offizielle DMARC-FAQ. Und es versteht sich von selbst, dass das Bird support team bereit ist, Ihnen bei der Konfiguration Ihres Bird-Kontos für DMARC zu helfen.
Danke fürs Lesen – und beginnen Sie noch heute, Ihre Domains mit DMARC zu schützen!
Es gibt viel in den obigen Informationen zu entpacken! Wir hoffen, dass Sie die Anleitung zur Erstellung eines DMARC-Policy-Datensatzes als hilfreich empfinden. Wir hoffen auch, dass unsere Erklärung, warum DMARC wichtig ist, dazu beiträgt, deutlich zu machen, warum Sie dieses wichtige Werkzeug zum Schutz Ihres E-Mail-Rufes verwenden sollten.
Natürlich ist dies kein vollständiges oder autoritatives Dokument zu diesem Thema. Wenn Sie tiefer eintauchen möchten oder mehr Hilfe benötigen, ist ein großartiger Ausgangspunkt das offizielle DMARC-FAQ. Und es versteht sich von selbst, dass das Bird support team bereit ist, Ihnen bei der Konfiguration Ihres Bird-Kontos für DMARC zu helfen.
Danke fürs Lesen – und beginnen Sie noch heute, Ihre Domains mit DMARC zu schützen!
