1

My domain has a strict DMARC policy (p=reject) and a standard SPF policy with ~all catchall.

My email provider is Google Workspace.

I received an email spoofing my sender address. It came from 41.174.75.34 - a Zambian IP address which is blacklisted in a few spam databases. Gmail did flag the email as spam. Running the headers through Google's Messageheader analyzer I get the following verdict:

  • SPF: softfail
  • DMARC: fail

My understanding from some online documentation and this question or this question is that this email should have been completely rejected because it failed DKIM and the source IP was not in the allowed SPF range. I did not expect it to make it to my mailbox at all, even if it did get flagged as spam.

What is the correct DMARC and SPF configuration to reject spoofed emails, considering the example I witnessed? Ideally, please provide references for your answer.

Update 1

Here are the values of the relevant DNS records for reference:

DMARC record

v=DMARC1; p=reject; rua=mailto:<redacted>; ruf=mailto:<redacted>; fo=1

SPF record

v=spf1 include:_spf.google.com include:_spf.salesforce.com include:<redacted> ~all

Update 2

Here are the full mail headers with minor redactions:

Delivered-To: <user-redacted>@<domain-redacted>
Received: by 2002:a05:6214:aaa:0:0:0:0 with SMTP id ew10csp427451qvb;
        Thu, 25 Feb 2021 07:46:07 -0800 (PST)
X-Google-Smtp-Source: ABdhPJxFPuLVmXBoRU+vQaU0r38lcka6Mby1RlA787SCOD8Rb7QkX5EOXGpiMC/Tenm4pXpACNBR
X-Received: by 2002:a62:68c5:0:b029:1ee:863:8c55 with SMTP id d188-20020a6268c50000b02901ee08638c55mr3732841pfc.37.1614267967132;
        Thu, 25 Feb 2021 07:46:07 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1614267967; cv=none;
        d=google.com; s=arc-20160816;
        b=wFGGZzBJaDIOxatWEKE7LE2TBMVhqNpktIexiXikL9SJWCMTxvXV7EAooox3TKoWI2
         JpquJ/v+fsFHvHGp/AaFghBTQcvEv9MDRPtdDKDX1zulGa2vGF5P4pE8EVcPrCZ7OEZ6
         hjky81yTDLBMnowYRefHs9/UhjkrrS944a/HnLJeYN2E/UEQW7a0YjXjmFRo87g9l35g
         fBml7hP9NFmW9ZECvOU6K/cXYr/W/Fl/53X6t+kfFbschLf3/NoB0KvIi8cBA+9NiXtF
         p12/7MjR2M4gd9gqYqGzpYyfZ2FK2T/3fgJFNa07CQldfLW8qkGNBJJIFAG0boPQlEs1
         enJQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=importance:mime-version:date:subject:to:from:message-id;
        bh=1beLMfc/QIXWzdWj0auhMhJreQONuvV9O2Srp9s2OQY=;
        b=u/KHc8DIEQxX0NzfQWqE8d/wu3hGQR0UHANF4dZZjSpAKgrVeAki+WYNaXdk3s5owS
         82yew5mZcS6PJ9b3k8LnjXX1gALocBFqZcn23FbnxFoIT/9WQdYWya/dqYI42nDLByB7
         5O/c4f9tKwZjF3VDHLAVg97P6hSPhCWrIhElqIjev60huc6jm/+FjPgBq1Umpbjv1720
         hZbi95+vetbIkPZMmhXw6iOwiB/YG3RDhhUyLwCnJhr8ixf3dg3MwgCMgqHb+ky/wn5b
         x0F4D4PHZ+3MCuIFPMkMR1kvhUFPidY6RRzjL72nWGVGJ1NbQs+aVgviVTqBJKWCGxI9
         fhBQ==
ARC-Authentication-Results: i=1; mx.google.com;
       spf=softfail (google.com: domain of transitioning <user-redacted>@<domain-redacted> does not designate 41.174.75.34 as permitted sender) smtp.mailfrom=<user-redacted>@<domain-redacted>;
       dmarc=fail (p=REJECT sp=REJECT dis=REJECT) header.from=<domain-redacted>
Return-Path: <<user-redacted>@<domain-redacted>>
Received: from [41.174.75.34] ([41.174.75.34])
        by mx.google.com with ESMTP id p11si6119467plo.125.2021.02.25.07.46.00
        for <<user-redacted>@<domain-redacted>>;
        Thu, 25 Feb 2021 07:46:07 -0800 (PST)
Received-SPF: softfail (google.com: domain of transitioning <user-redacted>@<domain-redacted> does not designate 41.174.75.34 as permitted sender) client-ip=41.174.75.34;
Authentication-Results: mx.google.com;
       spf=softfail (google.com: domain of transitioning <user-redacted>@<domain-redacted> does not designate 41.174.75.34 as permitted sender) smtp.mailfrom=<user-redacted>@<domain-redacted>;
       dmarc=fail (p=REJECT sp=REJECT dis=REJECT) header.from=<domain-redacted>
Message-ID: <20644A25380E0B57133D524F797C2064@8AIF179>
From: <<user-redacted>@<domain-redacted>>
To: <<user-redacted>@<domain-redacted>>
Subject: 情報リクエストに関する個人的な
Date: 26 Feb 2021 04:37:43 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_003F_01D70BF1.06CD2753"
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3505.912
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912

Update 3

Here is the rua report - this is the only report which mentions the offending 41.174.75.34 IP address. I cut out the irrelevant <record> entries. The softfail is right there, but the question is why?

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
  <report_metadata>
    <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>...redacted...</report_id>
    <date_range>
      <begin>1614211200</begin>
      <end>1614297599</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>...redacted...</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>reject</p>
    <sp>reject</sp>
    <pct>100</pct>
  </policy_published>
... redacted multiple <record> entries ...
  <record>
    <row>
      <source_ip>41.174.75.34</source_ip>
      <count>7</count>
      <policy_evaluated>
        <disposition>reject</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>...redacted...</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>...redacted...</domain>
        <result>softfail</result>
      </spf>
    </auth_results>
  </record>
... redacted multiple <record> entries ...
</feedback>
chutz
  • 7,569
  • 1
  • 28
  • 57
  • Please paste the complete SPF and DMARC records (redact domain names if you like). ~all isn't hard fail for SPF, -all is. DMARC has other options like aspf, adkim, pct, as well which contribute to what policy action to take upon failure. – Zach Mar 16 '21 at 03:28
  • Updated the question. I am aware `~all` is not a hard fail, but according to the questions I linked, in the context of DMARC `~all` is supposed to mean "apply the DMARC policy if DKIM also failed." – chutz Mar 16 '21 at 03:55
  • Added the mail headers in case it helps. I am willing to accept an answer that points to a document which confirms that what I am doing is correct, and Google is not doing the correct action here. – chutz Mar 16 '21 at 06:23

1 Answers1

-1

So, aspf=s means it should be strict on SPF matching, which means you need -all and not ~all

adkim=s means it should be strict on DKIM matching, which means it provided a DKIM signing key going out, and the public component of that DKIM keypair matched a public DNS record for which it was meant to pair up with.

The above two settings are part of the DMARC record.

Your current aspf and adkim settings are r (relaxed).

Looking at the headers it seems the sender delivered the email to mx.google.com which I would imagine is within _spf.google.com coverage, so I think ultimately you will need to set strict dkim alignment, since the idea is that ultimately that user will need to send emails with a signing key for your domain, instead of just easily sending from Google's IP ranges.

Feel free to sign up with an email provider that offer authenticated smtp for sending emails remotely via Gmail over SMTP/SMTPS to test this out, maybe use it to email a testing email from www.mail-tester.com and analyze the results.

Some links for you:

https://mxtoolbox.com/dmarc/details/dmarc-tags/aspf

https://mxtoolbox.com/dmarc/details/dmarc-tags/adkim

https://www.dmarcanalyzer.com/dmarc/dmarc-record-setup-guides/google-g-suite-dmarc-setup-guide/

https://support.google.com/a/answer/2466563?hl=en

https://mha.azurewebsites.net/

Zach
  • 109
  • 1
  • Only the first sentence (the advice to use `aspf=s`) seems relevant to my question, but there is no reference to confirm the statement. All reference I found imply that these make no difference. – chutz Mar 16 '21 at 23:04