Mail-sor-f69
Cheryll Witting
It seems like an email originating from myclient.org was sent to a Gmail address and subsequently forwarded by mail-sor-f69.google.com to another Gmail account (hence the reporter remains google.com).
SPF checker uses the extracted domain to query the DNS and find TXT records containing SPF info with the list of authorized senders e.g. v=spf1 include:spf.protection.outlook.com -all
No. SPF disposition results (pass/fail) are predicated on IP addresses, not hostnames. The SPF record at spf.protection.outlook.com is just a TXT SPF record with IP addresses, and more nested include mechanisms that reference yet more allowed IP addresses (which are determined by either direct ip4/ip6 mechanism reference, or resolved DNS lookups of IP addresses by a: mx: include: ptr: exists: etc.)
No. SPF disposition results (pass/fail, etc.) are predicated on IP addresses, not hostnames. The SPF record at spf.protection.outlook.com is just a TXT SPF record with IP addresses, and more nested include mechanisms that reference yet more allowed IP addresses (which are determined by either direct ip4/ip6 mechanism reference, or resolved DNS lookups of IP addresses by a: mx: include: ptr: exists: etc.)
From my understanding, this report indicates that there has been 2 IP addresses sending emails using my domain: 209.85.220.69 (Google's mail-sor-f69.google.com) and 198.51.100.56 (redacted for privacy). Out of these two IPs, they both had passing DKIM checks, while one of them had a failing SPF check. If I'm not misunderstanding how SPF works, this seems normal to me, since the IP address with the failed SPF check is not my server's IP address, and therefore, the email does not pass SPF. On receiving servers, such as Gmail, I get the following in the headers:
This makes me believe that SPF is working correctly, and that DKIM is at least working correctly for my own domain. What I am having trouble understanding then is why would DKIM pass for that other IP address with the failed SPF? Perhaps I am misunderstanding how DKIM is meant to work, but from reading other responses and DMARC reports from other users here, they seem to be getting DKIM failures for senders not directly from their own domain. Is that not how it's meant to work? Some insight would be greatly appreciated!
As a side note, a couple of months ago I was constantly receiving a ton of incoming spam email coming from my own email address(typical email asking for crypto ransom). That made me realize I was being spoofed which led me to realize I had my email server(Postfix) configured incorrectly regarding the SPF checks. However, I changed the settings and all that spam email stopped coming. I have also used several testing services like dmarc-tester, emailspooftest, mxtoolbox, etc., and they have all reported good status for my email, though no explanation as to this part. The trusted hosts for OpenDKIM file only includes the loopback address of the server, and the signing table includes only *@example.com addresses.
The most likely scenario is that your message was automatically forwarded to another address and the receiving server tested the SPF against the forwarding server. This could, e.g., be someone forwarding messages from an old email account to a new one or a mailing list.
For these use cases, DMARC was designed to pass if either SPF or DKIM is passing and aligned. A DKIM signature survives the forwarding as long as the message (body or any of the signed headers) is not modified.
Furthermore, this is not a problem you would like to "solve". Adding the IP address to your SPF record would allow this server to send any messages in your name, not just the forwarded ones. Also, a decent forwarding service would also change the envelope sender a.k.a. Return-Path, in which case the SPF would not align anyway. Leeman continues:
Adding the source IP addresses to your SPF policy will not fix this SPF issue because the Return-Path of the messages will always cause alignment issues. However, if these messages are forwarded by a server you control, you could investigate whether or not the Return-Path can be changed to match the "Header from" domain.
4a15465005