Postfix – proper header settings

gmailpostfixsmtp-headersubuntu-14.04

I'd like to ask you about setting up a proper header using to sending emails from my server which is running on Ubuntu 14.04 and Postfix is installed. All the emails sent from my server are marked as Spam by Gmail (to other mail services, emails are delivered with no problems). I read all the tips on this forum and nothing helps.

Going through a "Domain Health" test on mxtoolbox.com, I receive 2 warnings:

SOA Serial Number Format is Invalid
SOA Expire Value out of recommended range

But I think they're not very significant, everything else is fine which means that my SPF and DKIM are set up properly.

Sending an email to Gmail, I receive the following result:

Authentication-Results: mx.google.com;
   dkim=pass header.i=@MYDOMAIN.com;
   spf=pass (google.com: domain of office@MYDOMAIN.com designates MY.SERVER.IP as permitted sender) smtp.mailfrom=office@MYDOMAIN.com;
   dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=MYDOMAIN.com

Result from website mail-tester.com: 10/10. And result from: check-auth@verifier.port25.com:

==========================================================
Summary of Results
==========================================================
SPF check:          pass
DomainKeys check:   neutral
DKIM check:         pass
SpamAssassin check: ham

Is Sender-ID check missing?

Maybe setting up some additional headers attached to my email would help? Is there anybody out here who has had some experience related to this topic? What else can I do/check? There's no difference between an email with HTML and without it, both go to Spam (even simple messages). I want to send things like register confirmations and newsletters.

I saw that Gmail sends 2 headers I'd like to ask about: In-Reply-To and References. What do they stand for? Are they important?

Best Answer

No, there isn't any additional secret "non-SPAM" headers that Postfix doesn't add by default.

In this answer I explain the meaning of your suggested headers and the tests that have failed for you; they are not the cause for SPAM classification. Everything else is covered in the canonical question:

How to send emails and avoid them being classified as spam?

In-Reply-To and References are Identification Fields (RFC 5322 3.6.4), related to replies:

Though listed as optional in the table in section 3.6, every message SHOULD have a Message-ID: field. Furthermore, reply messages SHOULD have In-Reply-To: and References: fields as appropriate and as described below.

The In-Reply-To: and References: fields are used when creating a reply to a message. They hold the message identifier of the original message and the message identifiers of other messages (for example, in the case of a reply to a message that was itself a reply). The In-Reply-To: field may be used to identify the message (or messages) to which the new message is a reply, while the References: field may be used to identify a "thread" of conversation.

By them your mail user agent (MUA) can arrange the mails as threads, since the subject format Re: original subject alone hasn't got enough information for that: many emails can have same / empty subject and Re: can be replaced with a localized version, there can be replies to replies etc.

RFC 3834 3.1.8 introduces Precedence as a non-standard field for discouraging responses to bulk emails. Google uses the same header in its own way for (internal) labeling, which is not a spam filter; Gmail users can decide for themselves how important it is. However, when Precedence: bulk is added externally, it will cause the message to be labeled as bulk, too. This is not a standard nor a good practice. Read more. Using it doesn't affect for your email reputation, either. No magic here.

List-Unsubscribe is a good addition, but not something you absolutely should have. Its purpose is to provide an unsubscribe URL in a header that email clients could use as a standard unsubscribe button. Additionally, Gmail uses this as an auto-unsubscribe on "Report Spam" tool; it asks whether you want to Report spam or Unsubcribe and report spam. Carly Brantz explains this in depth.

Your DKIM, SPF and DMARC seems all pass; there shouldn't be anything wrong with them, either.

You are correct that SOA warnings are unrelated. SOA serial number format YYYYMMDDnn is only a recommendation: it's also common to use UNIX time and autoincrement, which are more easy to automate for example when using DNSSEC (dnssec-signzone -N unixtime). The only limitation is that it must increment. For SOA Expire, the recommended value per RFC 1912 2.2 is 1209600 - 2419200 seconds (14-28 days). Just like with the serial number, other value isn't necessarily bad and would only cause DNS related problems, not your mail ending up in SPAM folders.

Related Topic