DMARC (Domain-based Message Authentication, Reporting & Conformance) DMARC wertet die SPF- und DKIM-Prüfergebnisse aus, um die E-Mail (genauer: den Absender im From Header) zu authentisieren. Der Domain-Inhaber legt DMARC-Richtlinien fest, die bestimmen, wie der empfangende Server mit nicht authentifizierten E-Mails umgehen soll. DMARC ermöglicht Berichte über E-Mail-Authentifizierung und hilft, Missbrauch zu erkennen und zu verhindern. Das DMARC-Berichtswesen bietet 2 Optionen:   DMARC-Aggregatberichte (RUA): Tägliche Berichte im XML-Format. Zeigen den Zustellstatus aller von Ihrer Domain empfangenen E-Mails. Enthalten Informationen über Sendequellen, IP-Adressen, Geolokationen und Authentifizierungsergebnisse (SPF und DKIM) DMARC-Failureberichte (RUF): Detaillierte Berichte über einzelne E-Mails, die DMARC, SPF oder DKIM nicht bestanden haben. Enthalten Header und E-Mail-Austausche. Hilfreich bei der Untersuchung von Phishing- oder Spoofing-Angriffen DMARC: Beispiel: example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com" Starten Sie mit einer DMARC-Richtlinie von p=none und analysieren Sie die Berichte, bevor Sie auf p=quarantine oder p=reject umstellen. DATEV empfiehlt die Option p=quarantine Achtung: Aus Datenschutzgründen raten wir von der Option "RUF" ab, da die dabei versendeten Berichte personenbezogene Daten enthalten! https://www.eco.de/news/eco-verband-und-csa-gutachten-zur-vereinbarkeit-von-dmarc-mit-der-dsgvo-veroeffentlicht/ Soll als Reportingadresse eine andere Domain verwendet werden, sind 2 zusätzliche DNS-Einträge nötig. der eigentliche DMARC-Record: example.NET. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.COM" und ein Authorisierungsrecord in example.COM example.NET._report._dmarc.example.COM. TXT "v=DMARC1;" ... Mehr anzeigen

Hatten nun das Thema mittels SK zur Lösung angestoßen.   Der Fehler hängt offensichtlich zusammen mit der Umstellung von Baulohn (schon einen Monat abgerechnet) auf normalen Lohn. Hierzu existiert zwar ein Dokument  DATEV Hilfe-Center, Dok.-Nr. 1024301 , welches aber wegen dem etwas ungeeigneten Titel "Baulohn bei einem Mandanten in Lohn und Gehalt löschen" nicht gefunden und demnach nicht beachtet wurde. Somit erfolgte die Umstellung (dies sollte rückwirkend geschehen) durch Entfernung der baulohnspezifischen Einstellungen - soweit möglich - und der folgenden Abrechnung mit "normalen" Lohneinstellungen. Speziell das Löschen der Mitarbeitervariante ohne den Datensatz zuvor auf einen neuen Gültigkeitszeitraum zu kopieren, scheint hier zugeschlagen zu haben. Allerdings können in unserer Konstellation gemäß o.g. Dokument (Baulohn bereits abgerechnet) grundsätzlich nicht alle baulohnspezifischen Angaben gelöscht werden und ein Brutto/Netto Formular für Baulohn wird weiterhin erstellt.   Die kompetenten SK-Bearbeiter der Datev wiesen im Grunde aber darauf hin, dass im Falle einer solchen Umstellung nach Möglichkeit ein vollständig neuer Lohndatensatz angelegt werden sollte, weil eben gewisse Reste des Baulohns bestehen bleiben und durchaus zu unerwarteten Fehlern führen können. Ansonsten sollte oben genanntes Dokument unbedingt berücksichtigt werden. Der Titel sollte ggf. besser "Umstellung Baulohn auf normalen Lohn" enthalten. Das Dokument für den umgekehrten Vorgang existiert, wobei auch rückwirkende Wechsel beschrieben sind.   Unsere Lösung: Weil der gegenständliche Mandant im Juli 24 sowieso einen neuen Lohn-Datensatz bekam, werden wir nun erneut einen neuen Datensatz anlegen (ohne Baulohn) und alles nachberechnen und den alten Bestand löschen ...   PS: Habe Titel im Lichte der Lösung angepasst...   Falls jemand mit der Umstellung von klassischem Lohn auf Baulohn bessere Lösungen hat, die ggf. im gleichen Datensatz stabil laufen, dann gerne posten....   Viele Grüße ... Mehr anzeigen

Falls SmartIT oder ASP:   siehe auch Thread https://www.datev-community.de/t5/Wartungen-und-St%C3%B6rungen/Probleme-bei-Programmaufrufen-f%C3%BCr-DATEVasp-DATEV-SmartIT-und/m-p/452851#M216    Viele Grüße ... Mehr anzeigen