Volgens mij is dat niet de juiste weergave van de tekst. In de link staat dat ze hun dmarc policy strenger zullen zetten. De inkomende E-mails die niet aan de DMARC eisen voldoen, worden nu al geweigerd. (Mag ik toch hopen)

Toevallig keek ik vorige week nog met het 'host' command naar hun dmarc record en zag dat hun policy op 'none' stond, zoals veel bedrijven met een DMARC record. Ik keek net even en er stond nu 'reject'. Op zich vreemd omdat bovenstaande link vertelt dat ze hem pas volgens jaar op 'reject' zullen zetten.

(NB 'host' is een mac terminal command. Ik weet zo geen vergelijkbaar windows alternatief)

Echter betekend 'reject' niet dat Google de mail reject, maar juist dat andere mailservers deze mail moeten weigeren als de mail claimt van google.com af te komen.

het is een *nix command en mac is daar op gebaseerd dus op elke unix/linux systeem werkt dat commando ook.

op mijn domainen what op google apps draaien. draai ik die p=reject al jaren.

de opties zijn daarvoor.

none - Take no action. Log affected messages on the daily report only.
quarantine - Mark affected messages as spam.
reject - Cancel the message at the SMTP layer.

v=DMARC1; p=reject; rua=mailto:mail@domain.

maar voordat je dat opzet moet je wel DKIM authentication. goed hebben staan


een windows alternatief is nslookup

https://support.microsoft.com/en-us/kb/200525

https://dmarcian.com/dmarc-inspector/google.com lijkt dezelfde info als het 'host' command te geven, maar dan met uitleg wat de gebruikte velden betekenen, maar ook wat de default waarden zijn van niet gespecificeerde velden.

Handig, want ik weet nog weinig van DMARC terwijl dat, in combinatie met DKIM en SPF, eindelijk een protocol lijkt te zijn dat phishing effectief te lijf gaat.

@Briolet: in https://dmarcian.com/dmarc-inspector/gmail.com wordt de policy voor GMail getoond, nu nog "p=none", ik vermoed dat bedoeld wordt dat GMail i.p.v. Google per juni 2016 naar reject gaat.

"Niet om te bashen, maar het is onderdeeld van bash" *grinnikt een beetje*

Resolve-DnsName is een Powershell cmdlet wat een beter alternatief biedt dan nslookup. En dankzij tab-completion hoef je ook niet alle commando's binnen nslookup uit je hoofd te leren.

Niet om te bashen, maar het is onderdeel van de dnsutils/dns-utils/bind-utils package op veel linux systemen.
Heeft dus niks met welke shell dan ook te maken.

*shame* Mijn blunder, ik had bij gmail.com moeten kijken en natuurlijk niet bij google.com.

Sinds mijn mailserver een half jaar geleden dmarc is gaan ondersteunen, ben ik er diep ingedoken. Het lijkt een krachtig protocol tegen spam, maar eist een heel goed beleid van de domein eigenaar om te voorkomen dat ook legitieme mail geblokt wordt.

Ik ontvang nu dagelijks rapporten en merk dat bijna de helft van mijn zakelijke klanten hun mail forward naar een 2e account. Dan klopt het SPF al niet meer. Gelukkig is alleen een correcte DKIM voldoende voor een pass. Een enkele keer krijg je toch nog een reject omdat bij het forwarden de mail iets aangepast wordt. Dat betekent dat mensen die mail forwarden, dit via een server moeten doen die van de content afblijft. (volgens mij is het aanpassen van de titel al voldoende voor een reject).
Omdat ik nu allerlei problemen met forwarden van beveiligde mail zie, ben ik zelf ook gestopt met het forwarden van mijn eigen mail. Ik haal het nu liever via pop op van die servers.

Als je op dmarc.org kijkt zie je dat er ook grote problemen bij mailinglists zijn om deze mail niet te laten bouncen. Daar zijn allemaal oplossingen voor, maar dat heeft zijn tijd nodig. Dat zal ook de reden zijn dat veel bedrijven met een complexe mailstructuur wel al een DMARC record aangemaakt hebben, maar de policy nog op 'none' hebben staan.

@MeowSec nslookup lijkt een windows alternatief te zijn. De commando's die nodig zijn om het TXT record uit te lezen zijn echter niet in de mac versie van nslookup geïmplementeerd, vandaar mijn twijfel om deze te noemen.

Ter info: Ik heb deze week een mailing de deur uitgedaan en heb net het bijbehorende dmarc-rapport van GMail bekeken.

Circa een kwart van de mail is afkomstig van mijn IP en driekwart komt vanaf andere IP adressen. Die driekwart vanaf het verkeerde IP heeft allemaal een SPF-fail, maar omdat de DKIM checksum nog steeds correct is, geeft hij nog steeds een overall pass. Blijkbaar is er 3x zoveel van mijn mailing bij GMail terechtgekomen via een forward dan dat ik zelf naar GMail adressen gestuurd heb.

De mailing ging naar allemaal kleine bedrijfjes die meestal een website hebben met een e-mail adres van de webhoster waarop ze naar buiten toe bereikbaar willen zijn. Blijkbaar vindt men dat e-mail adres lastig om rechtstreeks te gebruiken en forward men de mail ook nog naar een eigen GMail account.