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 - 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;
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
ARC-Authentication-Results: i=1; mx.google.com;
       spf=softfail (google.com: domain of transitioning <user-redacted>@<domain-redacted> does not designate 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 [] ([])
        by mx.google.com with ESMTP id p11si6119467plo.125.2021.
        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 as permitted sender) client-ip=;
Authentication-Results: mx.google.com;
       spf=softfail (google.com: domain of transitioning <user-redacted>@<domain-redacted> does not designate 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 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" ?>
    <email>[email protected]</email>
... redacted multiple <record> entries ...
... redacted multiple <record> entries ...
  • 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, 2021 at 3: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, 2021 at 3: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, 2021 at 6:23

1 Answer 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:






  • 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, 2021 at 23:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .