I run a mailserver off Postfix on an Ubuntu 16.04 Droplet on DigitalOcean. The mailserver is a (closed) SMTP relay that uses mail client interfaces like Gmail and Hotmail to send emails from my domain (let's call it example.com). It has SPF, DKIM and DMARC set up, so emails from my domain are not marked as spam by Hotmail and Gmail.
I've recently been receiving messages from my Postfix Mail Daemon that have smtp.mailfrom=double-bounce@mail.example.com headers. These emails have been failing SPF and DMARC tests.
A possible reason why these emails are failing tests might be because my SPF records only list SPF records for example.com. But why is it that Postfix Mailer Daemon sends emails as @mail.example.com instead of @example.com? In Postfix, my myorigin attribute is set as example.com, and the documentation says that the double-bounce address is set as double-bounce@$myorigin.
Is it possible that these emails from Mailer Daemon that I am receiving are spoofed? I would like some insight on why my SPF and DMARC headers failed. Included are the important parts of my mail header below.
P.S. 1.2.3.4 is my mailserver IP and the IP that has been whitelisted on my domain SPF record.
Received: from mail.example.com ([1.2.3.4])
by mx.google.com with ESMTPS id r25-v6si17553370pfk.83.2018.10.27.22.06.59
for <example@gmail.com>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sat, 27 Oct 2018 22:06:59 -0700 (PDT)
Received-SPF: neutral (google.com: 1.2.3.4 is neither permitted nor denied by best guess record for domain of double-bounce@mail.example.com) client-ip=1.2.3.4;
Authentication-Results: mx.google.com;
spf=neutral (google.com: 1.2.3.4 is neither permitted nor denied by best guess record for domain of double-bounce@mail.example.com) smtp.mailfrom=double-bounce@mail.example.com;
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=example.com
Received: by mail.example.com (Postfix) id 7CDB5120787; Sun, 28 Oct 2018 13:06:58 +0800 (+08)
Date: Sun, 28 Oct 2018 13:06:58 +0800 (+08)
From: Mail Delivery System <MAILER-DAEMON@example.com>
Bounces commonly have an empty return-path (<>) and so the SPF result falls back to the check for the HELO name, as is described in sections 2.3 and 2.4 of RFC 7208. Adding an SPF record for your hosts, used in the HELO identity should change the result from "best guess" (usually in case of absence of a record) to an actual result.
Section 2.3:
It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM"
identity but also separately check the "HELO" identity[...]
and Section 2.4:
SPF verifiers MUST check the "MAIL FROM" identity if a "HELO" check
either has not been performed or has not reached a definitive policy
result by applying the check_host() function to the "MAIL FROM"
identity as the .[RFC5321] allows the reverse-path to be null (see Section 4.5.5 in [RFC5321]). In this case, there is no explicit sender mailbox, and
such a message can be assumed to be a notification message from the
mail system itself. When the reverse-path is null, this document
defines the "MAIL FROM" identity to be the mailbox composed of the
local-part "postmaster" and the "HELO" identity (which might or might not have been checked separately before).