1

I do not understand the fail results in the following google DMARC report to our domain.

I understand that the SPF fails because the IP address is not ours but if so, how come DKIM passes?

    <org_name>google.com</org_name>
        <email>noreply-dmarc-support@google.com</email>
        <extra_contact_info>https://support.google.com/a/answer/2466580</extra_contact_info>
        <report_id>8147166519871402641</report_id>
        <date_range>
            <begin>1661040000</begin>
            <end>1661126399</end>
        </date_range>
    </report_metadata>
    <policy_published>
        <domain>mydomain.com</domain>
        <adkim>r</adkim>
        <aspf>r</aspf>
        <p>reject</p>
        <sp>reject</sp>
        <pct>100</pct>
    </policy_published>
    <record>
        <row>
            <source_ip>ip.address.that.is.not.ours</source_ip>
            <count>1</count>
            <policy_evaluated>
                <disposition>none</disposition>
                <dkim>pass</dkim>
                <spf>fail</spf>
            </policy_evaluated>
        </row>
        <identifiers>
            <header_from>mydomain.com</header_from>
        </identifiers>
        <auth_results>
            <dkim>
                <domain>mydomain.com</domain>
                <result>pass</result>
                <selector>default</selector>
            </dkim>
            <spf>
                <domain>mydomain.com</domain>
                <result>fail</result>
            </spf>
        </auth_results>
    </record>
Kevin Roma
  • 11
  • 2
  • Look up the reverse name of the unknown IP, some providers have been nice enough to not only update their address block WHOIS info, but also use something explanatory like `forwarded.mail-provider.example` for the IPs used for such purposes. – anx Aug 22 '22 at 14:31
  • You may have manually setup DKIM records but not the associated SPF records; e.g. SendGrid (DKIM https://docs.sendgrid.com/ui/account-and-settings/dkim-records, SPF https://docs.sendgrid.com/ui/account-and-settings/spf-records) is a popular service for sending mails from your domain from cloud hosted apps, which would have an IP differnt to yours, but mails would pass DKIM checks if you'd put those DNS TXT records in place. – JohnLBevan Aug 22 '22 at 14:42

3 Answers3

1

One possibility is that valid messages that you originally sent are being resent. It does sound unlikely and useless that a spammer would do such a thing but without more information, it is one of the possibilities to consider.

This is called a replay attack. You can find more about this term online.

RFC 6376 has a section on this (https://www.rfc-editor.org/rfc/rfc6376#section-8.6) as well as further security considerations that might be relevant.

glts
  • 681
  • 4
  • 14
1

If someone has setup a mailbox you sent mail to such that it forwards to Google, Google will report your still-valid signature back to you, with the IP in the report designating the last non-Google hop on the forwarding chain.

If you want to limit this to reasonable use cases, make sure you are signing your Date header. If you do that, Google can apply their usual spam mitigation on messages being re-sent at a later time.

anx
  • 6,875
  • 4
  • 22
  • 45
0

Google is telling you that they used DKIM selector default to verify the digital signature on the email, and indeed it did validate. That can only happens if the server at ip.address.that.is.not.ours has the private key corresponding to public key on the DKIM record you published on the DNS.

Notice that the record indicates a DMARC pass too (i.e. message delivered). That's because DKIM has passed, and the domain is in alignment. In other words, the email has been delivered. Nothing has failed in this regard.

Now if are concerned why DKIM passed, then you may want to start investigating the server at ip.address.that.is.not.ours. As I said, in theory that server can only generate a valid signature if it has access to the DKIM selector private key.

fvsdpl
  • 1
  • 2