Absenderauthentifizierung für Veranstaltungs-E-Mails: SPF-, DKIM- und DMARC-Inventar
Vor Änderungen an SPF, DKIM oder DMARC müssen alle Dienste bekannt sein, die im Namen der Veranstaltungsdomain senden. Ticketplattform, Postfach, Support und Kampagnendienst können verschieden eingerichtet sein.
Boletolibre-Redaktion
Veröffentlicht
Absenderinventar herunterladen
Bearbeitbare Vorlage herunterladen (Markdown, Englisch)
Legen Sie je Postfach, Ticketdienst, Bestätigung, Erinnerung, Sponsorennachricht und Kampagne eine Zeile an. Erfassen Sie Besitzer und Nachrichtenart vor einer DNS-Änderung. Speichern Sie keine Zugangsdaten im Blatt.[1][2][3][4]
Sichtbare Absender und Dienste erfassen
Listen Sie Anmeldebestätigungen, Tickets, Zugangshinweise, Rückzahlungen, Antworten und Werbung. Erfassen Sie sichtbare From-Domain, tatsächlichen Versanddienst und technische MAIL-FROM- oder Return-Path-Domain. Bewahren Sie je Weg eine Beispielnachricht und einen Verantwortlichen auf; eine unvollständige Liste kann legitime Post stören.[1][2][3][4]
SPF, DKIM und DMARC den Besitzern zuordnen
Kopieren Sie nicht ungeprüft alle SPF-includes zusammen. RFC 7208 begrenzt DNS-Abfragen auswertungsrelevanter SPF-Mechanismen und Modifikatoren auf zehn. Verwenden Sie aktuelle Anbieteranleitungen. Für DMARC muss ein bestehender SPF- oder DKIM-Erfolg zur sichtbaren From-Domain ausgerichtet sein; ein Erfolg für eine fremde Anbieterdomain reicht nicht automatisch.[1][2][3][4]
Echte Nachrichtentypen statt nur DNS-Syntax prüfen
Senden Sie kontrollierte Beispiele über jeden Weg an Teamkonten. Prüfen Sie Header mit sichtbarer From-Domain, SPF-Domain, DKIM-d-Domain und DMARC-Ergebnis. Notieren Sie Dienst und Kategorie sowie Antwortweg und Zustellung wichtiger Anmeldehinweise. Ein DNS-Checker allein prüft keine konkrete Vorlage.[1][2][3][4]
DMARC-Berichte und Richtlinienänderungen freigeben
Leiten Sie aggregierte Berichte an eine betreute Stelle. Vergleichen Sie Versender mit dem Inventar und beheben Sie legitime Fehler, bevor Sie eine strengere Richtlinie erwägen. p=none dient der Beobachtung; quarantine und reject verlangen eine eigene Freigabe samt Rückweg. Ein Checklistenpunkt allein rechtfertigt keine Ablehnungspolitik.[1][2][3][4]
Inventar im Veranstaltungszyklus aktuell halten
Prüfen Sie neue Versender beim Anbieter-Onboarding und vor Veranstaltungsstart. Entfernen Sie Einträge eines beendeten Vertrags erst, wenn Bestätigung, Rückzahlung und Support nicht mehr davon abhängen. Bewahren Sie datierten Zonenexport und Belege des geprüften Ersatzwegs auf.[1][2][3][4]
Quellen und weiterführende Informationen
- Email Authentication (SPF, DKIM, DMARC) Setup Checklist TemplateCheckFlow · Abgerufen
- Email sender guidelinesGmail Help · Abgerufen
- Complying with DMARC authentication protocol in Amazon SESAmazon Web Services · Abgerufen
- RFC 7208: Sender Policy FrameworkIETF · Abgerufen