Outgoing SMTP mail servers considerations

Mail with gmail.com as From address vanishing

It started really bad: Someone asked me why he hasn’t received an answer from me in two weeks, and I had answered his mail the same day I got his.

It turned out that Gmail had thrown mail into the black hole without any warning. Probably the updated DMARC policy, which has been mentioned for long now.

Solution: When using gmail.com as a From address, also use smtp.gmail.com as the outgoing SMTP mail server. This ensures that the mail arrives properly to gmail.com recipients as well.

Bonus: The sent mails appear in Google’s web interface’s Sent folder as well. I would have done well without this favor.

That was really annoying, frankly speaking.

SPF entries

There’s another comprehensive post on SPF, DKIM and DMARC. It’s important to keep these entries properly set and to update them when the outgoing servers change.

This (SPF) mechanism helps spam filters tell if the sender of the mail is authentic, by looking for an SPF record in the domain name’s TXT record.

For example, since I’m relaying through my web host’s server, billauer.co.il, the desired SPF record should read:

v=spf1 +a +mx +ip4:208.76.80.100 +ip4:46.232.183.0/24 +ip4:23.83.208.1/20 +ip4:177.153.0.128/25 +ip4:191.252.57.0/25 -all

• The +a part means to pass the mail if the A entry if the sending domain appears
• The +mx means the same for the MX entry
• The other IP4 parts say that if these addresses (or address blocks) appear, pass the mail
• Finally, the -all part in the end says that if none of the previous entires matches, drop the mail

(In Cpanel, go to EMail > Authentication to set this up)

A word about “include records”. I used to have one saying “+include:relay.mailchannels.net”, which means “get the SPF record from relay.mailchannels.net”, and add whatever records they have. Which makes sense in a way, since their servers are expected to appear on the list. On the other hand, if this record is missing (or their DNS temporary out of business), it’s a fatal error. So I’m not happy about this idea. The solution above, copying their records (which is the long list of IP4 address blocks), is suboptimal in that I may miss some new servers or so, but this can’t cause a fatal error.

Checking the current SPF record

(actually, it has changed since)

$ dig txt billauer.co.il

; <<>> DiG 9.6.2-P2-RedHat-9.6.2-5.P2.fc12 <<>> txt billauer.co.il
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1406
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;billauer.co.il.            IN    TXT

;; ANSWER SECTION:
billauer.co.il.        14400    IN    TXT    "v=spf1 +a +mx +ip4:208.76.80.100 +ip4:46.232.183.0/24 +ip4:23.83.208.1/20 +ip4:177.153.0.128/25 +ip4:191.252.57.0/25 -all"

;; AUTHORITY SECTION:
billauer.co.il.        28920    IN    NS    ns2.totalchoicehosting.com.
billauer.co.il.        28920    IN    NS    ns1.totalchoicehosting.com.

;; ADDITIONAL SECTION:
ns1.totalchoicehosting.com. 4736 IN    A    208.76.85.138
ns2.totalchoicehosting.com. 131050 IN    A    192.96.216.208

;; Query time: 173 msec
;; SERVER: 194.90.0.1#53(194.90.0.1)
;; WHEN: Thu Sep  7 18:23:52 2017
;; MSG SIZE  rcvd: 256

Checking directly on the authoritative DNS is better when monitoring quick changes.