I have several postfix servers that send mail on behalf of my domain (example.com). When a from address is provided, DKIM and SPF pass properly. However, I noticed in my DMARC notifications there are a number of failing emails being send from my postfix servers.

Each postfix server maps to a subdomain in our DNS (smtp1.example.com, smtp2.example.com). Reverse lookups are configured at AWS for the sending IP.

When an email bounces, postfix sends the non-delivery notification email to the sender, but it comes from the null sender. These messages seem to fail DKIM AND sometimes SPF because they are sent from MA[email protected] and not [email protected].

What is the best way to go about managing this? Should I be creating DKIM AND SPF records for each subdomain? Is there a way to customize the mailer-daemon sender in postfix to have it sent from the domain and not the subdomain?


I figured out that in "/etc/postfix/main.cf" I need to change the $mydomain variable to example.com and set $myorigin to use $mydomain, but DKIM isn't being attached. I use OpenDKIM to apply DKIM to each outgoing mail, but because postfix uses from=<> instead of [email protected] it seems to skip it, though I'm not sure that is the reason.


I was able to get DKIM to be sent for bounced emails by adding "internal_mail_filter_classes = bounce" to "/etc/postfix/main.cf" as per:


I am still wondering if this is the best way to go about accomplishing my goal.


Bounced emails are sent from [email protected], but the recipient sees the email as sent from smtp1.example.com and signed by example.com. This requires I have another spf record configured for smtp1.example.com and I would prefer not to need this. Bounces should appear as sent by the root domain.

How do I accomplish this?


Adding email headers and output of postconf -n. I have obfuscated the IP addresses and domain name only. The email was received by a gmail managed domain.

Email Headers

Delivered-To: [email protected]
Received: by 2002:a2e:45d5:0:0:0:0:0 with SMTP id s204-v6csp753516lja;
        Wed, 26 Sep 2018 10:59:51 -0700 (PDT)
X-Google-Smtp-Source: ACcGV62LaRKlAeJoVcCqIQRgHXwen7bLAev7n/gyBtIF7yWMLpmgBaL1q8D3Qm0zEMcDjPEmCjCz
X-Received: by 2002:a0c:a9d2:: with SMTP id c18-v6mr54933qvb.191.1537984791474;
        Wed, 26 Sep 2018 10:59:51 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1537984791; 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;
       dkim=pass [email protected] header.s=example header.b="Kh/wMFFv";
       spf=pass (google.com: domain of [email protected] designates <IP-Address> as permitted sender) smtp.helo=smtp1.example.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com
Return-Path: <>
Received: from smtp1.example.com (smtp1.example.com. [<IP-Address>])
        by mx.google.com with ESMTPS id 144-v6si4528390qkh.294.2018.
        for <[email protected]>
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Wed, 26 Sep 2018 10:59:51 -0700 (PDT)
Received-SPF: pass (google.com: domain of postma[email protected] designates <IP-Address> as permitted sender) client-ip=<IP-Address>;
Authentication-Results: mx.google.com;
       dkim=pass [email protected] header.s=example header.b="Kh/wMFFv";
       spf=pass (google.com: domain of [email protected] designates <IP-Address> as permitted sender) smtp.helo=smtp1.example.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com
Received: by smtp1.example.com (Postfix) id 1CEE260DBC; Wed, 26 Sep 2018 17:59:51 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=example.com; s=example; t=1537984791; bh=DalucSR/izsrTI/4cwdDwKrGi8R0OywUerOF7byykLI=; h=Date:From:Subject:To; b=Kh/wMFFvEE/uPx/7qKnYVZZACU6zzLl9S+Jwr1hXSBhIg0mfkqpVXgxvhUxqNkJXw
Date: Wed, 26 Sep 2018 17:59:51 +0000 (UTC)
From: Mail Delivery System <[email protected]>
Subject: Undelivered Mail Returned to Sender
To: [email protected]
Auto-Submitted: auto-replied
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status; boundary="DF7BD600B7.1537984791/smtp1.example.com"
Message-Id: <[email protected]>

Output of postconf -n

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
bounce_notice_recipient = [email protected]
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
html_directory = no
inet_interfaces = localhost
inet_protocols = ipv4
internal_mail_filter_classes = bounce
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
milter_default_action = accept
milter_protocol = 2
mydestination = $myhostname, localhost.$mydomain, localhost
mydomain = example.com
myhostname = smtp1.example.com
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
non_smtpd_milters = $smtpd_milters
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES
sample_directory = /usr/share/doc/postfix-2.6.6/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_tls_security_level = may
smtpd_milters = inet:
  • Please show a complete set of headers from a bounce message, and the output of postconf -n. Do not obfuscate if you can possibly avoid it. Sep 26, 2018 at 17:03
  • Hi Michael! Thank you for taking the time to comment. I have updated the issue with the details you asked and have only obfuscated information about the company I work for. I really appreciate your help.
    – jnrcorp
    Sep 26, 2018 at 18:26
  • I suspect the answer lies in customizing the Return-Path: <> to say [email protected] but I'm not sure how to accomplish this.
    – jnrcorp
    Sep 26, 2018 at 18:37
  • 1
    The Return-Path is supposed to be <> for a bounce message. This is normal and expected. I think the problem is going to be elsewhere. Sep 27, 2018 at 18:17

1 Answer 1


As Michael has mentioned, the empty Return-Path <> is recommended for NDR mails. As you've experienced, a lot of MTAs base the applying of DKIM signatures on this header. This had resulted in missing DKIM signatures which you've been able to resolve.

As SPF fallbacks to the HELO/EHLO domain if a Return-Path is missing, as stated in the spec:


For example, if the reverse-path was null, then the EHLO/HELO domain is used, with its associated problems (see Section 2.1)

If your main question is to get DMARC alignment on these mails, you can suffice with making sure you apply DKIM on the NDR mails. In that situation you're not required to setup individual SPF records for the smtp subdomains. This is advised to prevent losing NDR mails for non-DMARC supporting receivers.

If you have a long list of SMTP servers you could also publish a wildcard SPF which allows your IP addresses specifically.

Does this help you?



DMARC Analyzer

You must log in to answer this question.

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