DMARC-Pass nicht erfolgreich (SPF fehlgeschlagen)

[Avenger84]

Hallo,
ich habe bei Cloudflare die E-Mail Sicherheit aktiviert "DMARC-Management", darauf hin habe ich eine E-Mail gesendet und gewartet was der Bericht sagt:

Unten finden Sie die 10 wichtigsten Quellen, die E-Mails in Ihrem Namen senden. Eine Quelle muss entweder mit SPF oder DKIM kompatibel sein, um einen DMARC-Pass zu erhalten:

DKIM habe ich nicht, das ist klar dass das fehlschlägt.

Aber für google habe ich extra den SPF Eintrag hinzugefügt:

"v=spf1 include:_spf.mx.cloudflare.net include:_spf.google.com ~all"

Weiß jemand warum "SPF-ausgerichtet" fehlschlägt ?

Ich sende über Googlemail meine Domain E-Mails (kostenlos, siehe anderes Thema von mir).

Die o.g. IP gehört zu "mail-wr1-f54.google.com".
Daher sollte meines Verständnisses nach "include:_spf.google.com" passen und entsprechend erfolgreich sein.

DKIM kriege ich nur über google workspace (kostenpflichtig), soweit ich gelesen habe.

MfG

Ergänzung (28. Dezember 2024)

Edit: habe noch was gefunden:
https://jay.gooby.org/2022/05/06/us...h-a-domain-that-uses-cloudflare-email-routing was ich ausprobieren werde

 

[bin/bash]

Vielleicht einfach mal ein paar Stunden warten, bis der DNS-TXT-Eintrag aktualisiert wurde. Das kann zwischen wenigen Minuten und bis zu 48 Stunden dauern.

 

[Frightener]

Teste das Ganze doch mal über https://mxtoolbox.com/SuperTool.aspx#

 

[GTrash81]

Ich vermute weil hinten "~all" steht, dadurch hat die Regel den Zustand "vielleicht ist die Regel richtig".
Stattdessen muss "-all" stehen, dadurch wechselt die Regel in den Zustand "alle anderen Server sind ungültig" und der Server vom Empfänger fängt an falsche Mails aktiv zu blockieren.

 

[michi_z1981]

Ich meine , ich hatte damals include smtp.google.com drin stehen.

Der Eintrag im DNS sagt ja, welcher SMTP Server Mails im Auftrag deiner Domain versenden darf.
Und der spf* versendet ja normal nix.

Das ist der Eintrag im DNS der das seitens dem Empfänger Server verifiziert, wer Mails verschicken darf.

Und das ~ und - muss beachtet werden.



Wenn du über Google (Workspace) arbeitest

https://support.google.com/a/answer/2466580?hl=de

 

[aluis]

Du sagst die Domäne _spf.google.com sendet Emails. Das ist falsch. Hier muss statt einem Include ein Redirect gemacht werden. Der SPF von _spf.google.com soll doch aufgelöst werden. _spf.google.com sendet aber selber keine Emails.

Hier die Synax: https://www.spf-record.de/syntax

 

[jebeo]

Das passiert wohl, wenn Mails (automatisch) weitergeleitet werden. Ich kenne das auch von Arbeit. Da sind 1-2 Mails von vllt. 100 dort bei Cloudflare aufgeführt. Die (eigene) Absenderdomain passt dann nicht mehr zur IP des Weiterleiters.

 

[Avenger84]

Danke, ich verstehe es auch nicht, in jeder Anleitung zum Thema steht:

v=spf1 a mx include:_spf.google.com ~all

bzw.

v=spf1 include:_spf.google.com ~all

wenn man von google aus E-Mails senden will.

wenn ich die IP von der Google aus sendet abfrage kommt:
mail-wr1-f54.google.com
bzw.
mail-wm1-f43.google.com

Was hat es mit _spf auf sich ? _spf passt ja überhaupt nicht zu dem Teil der vor .google.com steht.

Wenn man in Cloudflare E-Mail Adressen anlegt, womit man nur empfängt (als Weiterleitung), dann legt Cloudflare automtisch:

an. Wozu ?

Mit der Syntax versteh ich immer noch nicht.
Folgendes Beispiel habe ich noch gefunden:

Kombinierter SPF-Record​

Der standardmässig hinterlegte SPF-Record v=spf1 redirect=spf.mail.hostpoint.ch lässt sich auch mit anderen SPF-Records kombinieren. Dies ist beispielsweise erforderlich, wenn Sie Ihren Webshop bei Hostpoint betreiben, aber für Ihre E-Mails einen anderen Anbieter nutzen.

Ein kombinierter SPF-Record sieht folgendermassen aus:
v=spf1 include:spf.protection.outlook.com redirect=spf.mail.hostpoint.ch

In diesem Beispiel sind für den E-Mail-Versand sowohl die Mailserver von Hostpoint als auch die Mailserver von Outlook zugelassen.

Bei einem kombinierten SPF-Record müssen folgende Bedingungen erfüllt sein:

• Der «Redirect» steht am Ende des Eintrags.
• Im Eintrag ist kein zweiter «Redirect» vorhanden.
• Im Eintrag ist kein «all» vorhanden (z. B. -all, ~all, ?all).

Quelle: https://support.hostpoint.ch/de/tec...-setze-ich-einen-spf-record-fuer-meine-domain


Hier ist statt _spf nur spf.

kein -all oder ~all erlaubt

versteh ich überhaupt nicht..

 

[Bob.Dig]

Mach doch mal, wie schon gesagt wurde, das daraus, warte ein paar Minuten und teste erneut.
"v=spf1 include:_spf.mx.cloudflare.net include:_spf.google.com -all"

 

[jebeo]

Und da fehlt dann noch MS/Outlook, Maildienst X und Maildienst Y. Ich renne denen doch nicht hinterher. Wie gesagt, das betrifft nur automatische Weiterleitungen. Und wenn User bzw. Maildienstleister das nicht hinbekommen: Pech gehabt.

 

[Bob.Dig]

Du sagst die Domäne _spf.google.com sendet Emails. Das ist falsch.

Das sagt es nicht, sondern lediglich, dass es woanders eine weitere SPF-Abfrage machen soll.

Ergänzung (29. Dezember 2024)

Pech gehabt.

Und direkt Listen-Platz gesichert.

 

[Avenger84]

Ich bin der Sache näher gekommen dank der Seite https://easydmarc.com/tools/spf-lookup

include: _spf.google.com 3 NESTED LOOKUPS
v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all

4
include: _netblocks.google.com
v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all
35.190.247.0/24
(35.190.247.0 - 35.190.247.255)
64.233.160.0/19
(64.233.160.0 - 64.233.191.255)
66.102.0.0/20
(66.102.0.0 - 66.102.15.255)
66.249.80.0/20
(66.249.80.0 - 66.249.95.255)
72.14.192.0/18
(72.14.192.0 - 72.14.255.255)
74.125.0.0/16
(74.125.0.0 - 74.125.255.255)
108.177.8.0/21
(108.177.8.0 - 108.177.15.255)
173.194.0.0/16
(173.194.0.0 - 173.194.255.255)
209.85.128.0/17
(209.85.128.0 - 209.85.255.255)
216.58.192.0/19
(216.58.192.0 - 216.58.223.255)
216.239.32.0/19
(216.239.32.0 - 216.239.63.255)

5
include: _netblocks2.google.com => nur IPv6 Adressen

6
include: _netblocks3.google.com
v=spf1 ip4:172.217.0.0/19 ip4:172.217.32.0/20 ip4:172.217.128.0/19 ip4:172.217.160.0/20 ip4:172.217.192.0/19 ip4:172.253.56.0/21 ip4:172.253.112.0/20 ip4:108.177.96.0/19 ip4:35.191.0.0/16 ip4:130.211.0.0/22 ~all
172.217.0.0/19
(172.217.0.0 - 172.217.31.255)
172.217.32.0/20
(172.217.32.0 - 172.217.47.255)
172.217.128.0/19
(172.217.128.0 - 172.217.159.255)
172.217.160.0/20
(172.217.160.0 - 172.217.175.255)
172.217.192.0/19
(172.217.192.0 - 172.217.223.255)
172.253.56.0/21
(172.253.56.0 - 172.253.63.255)
172.253.112.0/20
(172.253.112.0 - 172.253.127.255)
108.177.96.0/19
(108.177.96.0 - 108.177.127.255)
35.191.0.0/16
(35.191.0.0 - 35.191.255.255)
130.211.0.0/22
(130.211.0.0 - 130.211.3.255)

demnach ist das Netz 209.85.128.1 - 209.85.255.254 enthalten, wovon ich gesendet habe.

 

[Avenger84]

P.S. Wenn ich statt ~all ein -all mache, kommt keine E-Mail mehr an.
Genauso wenn ich "v=DMARC1; p=none; ein "reject" mache.
bei "quarantine" landet es im spam.

 

[Avenger84]

Update, habe mich nun bei SMTP2Go angemeldet, das ging problemlos über meine vorhandene (Weiterleitungs-) Domain E-Mail Adresse.

Anschließend musste ich 3x CNAME hinzufügen (kein spf Eintrag notwendig, das läuft über einen der CNAME Einträge).

Nun sende ich über den SMTP2Go Server und alles ist ok:

Mit

"v=DMARC1; p=reject; ...

klappt es nun auch.

natürlich auch kostenlos:

free accounts come with a monthly allowance of 1000 emails and a limit of 200 emails per day.
there is an hourly limit of 25 emails (the hourly limit is removed when you verify your sender domain).

👍

 

[Bob.Dig]

Anschließend musste ich 3x CNAME hinzufügen (kein spf Eintrag notwendig, das läuft über einen der CNAME Einträge).

Klingt merkwürdig für mich. Woher ist dieser Screenshot?

Die können nun auf jeden Fall all deine gesendeten E-Mails lesen. Ich würde mir als dauerhafte Lösung etwas anderes suchen, z.B. einen günstigen VPS.

 

[jebeo]

Woher ist dieser Screenshot?

Das ist wohl nur ein 0815 Test wie mxtoolbox. Da ist es zwar grün, wenn es passt. Löst aber das Weiterleitungsproblem nicht wirklich.

dauerhafte Lösung etwas anderes suchen, z.B. einen günstigen VPS.

Löst nicht das Problem der Weiterleitungen von Google, MS und Co. Das ist auf deren Seite broken. Wenn die im eigenen Namen weiter leiten (und damit nicht zur Senderdomain/IP passt), ist es halt nicht valid. Einfach ignorieren.

Dieses Verhalten von Google und MS bricht halt einfach nur DMARC/SPF auf. Fügt man die zum Record hinzu, kann jeder von deren Server mit (deiner) gefälschten Domain Spam verschicken.

 

[Avenger84]

also von Googlemail kann man nicht einfach so gefälschte Domain E-Mails senden, die muss man schon vorher empfangen können um sich zu legitimieren.

Jeder der nicht seinen eignen Server Zuhause betreibt und das sind vermutlich 99,999% der Menschen, hat das Problem, dass sein Anbieter die Emails lesen könnte.
Ob SMTP2G0 oder Microsoft oder Google oder GMX die lesen kann, wo ist der Unterschied?

Ich habe mich aber wirklich schon mit dem Gedanken beschäftigt, meinen eigenen E-Mail Server Zuhause zu betreiben, es wird aber in Foren immer davon abgeraten. Weiß nicht ob ich mich da irgendwann mal aus Spaß ran traue. Habe nur diesen Docker gefunden: https://github.com/docker-mailserver/docker-mailserver (bin nicht so der Docker Pro)

Habe noch keine Dau-Anleitung gefunden, wo ich sagen würde "das probier ich doch mal".
Die DKIM Geschichte schreckt mich ein wenig ab, auch die Let´s Encrypt Zertifikate dort rein zu kriegen.

P.S. was mich auch noch stört ist der PTR Record nach Zuhause, den man zwangsläufig braucht.

 

[Bob.Dig]

Jeder der nicht seinen eignen Server Zuhause betreibt und das sind vermutlich 99,999% der Menschen, hat das Problem, dass sein Anbieter die Emails lesen könnte.

Jein. Die meisten relevanten E-Mails und quasi alle, die ich selbst versende, werden zwischen den Servern verschlüsselt übertragen. Solange die Server also unter deiner Kontrolle sind, kann da keiner einfach mitlesen. Und das gilt eben auch für einen VPS.

Habe noch keine Dau-Anleitung gefunden, wo ich sagen würde "das probier ich doch mal".
Die DKIM Geschichte schreckt mich ein wenig ab, auch die Let´s Encrypt Zertifikate dort rein zu kriegen.

Wobei Du dich schon mit den ganzen Problemen befassen musstest, nicht der schlechteste Start für so eine Aufgabe. Hier sollten ein paar Videos dabei sein.

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

P.S. was mich auch noch stört ist der PTR Record nach Zuhause, den man zwangsläufig braucht.

Von zuhause aus kannst Du keine E-Mails sinnvoll versenden, das muss über den VPS laufen und der muss den PTR unterstützen.

 

[Avenger84]

@Bob.Dig was die Let´s Encrypt Zertifikate betrifft bei mailcow habe ich nur folgende Lösung eines Nutzers gefunden:

The advantage in changing the links to the certificates in a docker-compose override file is you do not have to copy the certificate and key file to /opt/mailcow-dockerized/assets/ssl/ BUT you have to restart mailcow, if a certificate changes, gets renewed, etc from certbot to make it work in mailcow.

If the certbot is running on the same server like mailcow maybe a post-hook in certbot to restart mailcow can be a solution. In my scenario the nginx proxy with certbot runs on another server and I simply mount the directory containing the certificate and key file into the mailcow server and use a shell script that regularly copys the certificate and key to the mailcow directory and restarts mailcow. Works without problems.

If you want to try the shell script:

#!/bin/bash
cd /opt/mailcow-dockerized
cp /etc/letsencrypt/live/<subdomain.domain.com>/fullchain.pem data/assets/ssl/cert.pem
cp /etc/letsencrypt/live/<subdomain.domain.com>/privkey.pem data/assets/ssl/key.pem
docker-compose down && docker-compose up -d

I regularly start this script via cron:

0 4 * * 2 /root/scripts/restart_mailcow_acme.sh >/dev/null 2>&1

This starts the script every Tuesday at 4:00 am - copys the (new) files into mailcow and restarts it.

Mein Nginx Reverse Proxy Manager (Docker auf Unraid) holt sich automatisch per DNS Challenge das *.domain + .domain Zertifikat ab (wildcard) - das sollte doch für alle Dienste von mailcow ausreichen oder?

Nun müsste ich diese aus dem Docker zur Mailcow VM kopieren. Das ist schon eine kleine Herausforderung.

Aber ohne Zertifikat keine E-Mail Annahme so wie ich es gelesen habe.

 

[Bob.Dig]

Nun müsste ich diese aus dem Docker zur Mailcow VM kopieren. Das ist schon eine kleine Herausforderung.

Ich selbst nutze PMG, nicht Mailcow. Aber PMG ist kein Server, Du bräuchtest also noch etwas anderes, das muss nicht besonders fancy sein.
Oder Du gibst Mailcow einfach den Port 80? Rumkopieren würde ich nicht machen.