DEV Community

loading...
Cover image for How to fix Postfix emails sent to Gmail addresses not being received

How to fix Postfix emails sent to Gmail addresses not being received

jdrch
He/Him/His. Mechanical engineer by day, home sysadmin by night. Thoughts here are mine only & do not represent those of my employer or any group of which I am a member.
・3 min read

So you've followed the instructions to mailutils and postfix, but the test echo "This is the body of the email" | mail -s "This is the subject line" your_Gmail_address command isn't resulting in any emails showing up at your_Gmail_address.

What's going on? Here's how I solved the problem (on Debian 10).

As difficult as email delivery is to set up and troubleshoot, the good news is that emails that fail to be delivered generally get bounced, and the bounced email contains useful error information.

Let's open our inbox and see what's there. In the terminal, run $ mail. You should see something like this (if you don't, check your system mail logs. Doing so is outside the scope of this post):

$ mail
"/var/mail/jdrch": 1 message 1 new
>N   1 Mail Delivery Syst Sun Apr 25 14:22  70/2479  Undelivered Mail Returned to Sender
Enter fullscreen mode Exit fullscreen mode

Hit Enter to read the email. Look for a line beginning with Diagnostic-Code:. In my case, the line is:

Diagnostic-Code: X-Postfix; mail for gmail.com loops back to myself
Enter fullscreen mode Exit fullscreen mode

loops back here is informative. In computing terminology, looping back means that somewhere along the way a destination location resolved to the source location. In a network, e.g. email, context, those locations are typically URLs or IP addresses.

Gmail's SMTP server URL is gmail-smtp-in.l.google.com. Let's figure out what that resolves to using dig, which returns the IP address of input URLs resolved using the machine's DNS settings¹:

$ dig gmail-smtp-in.l.google.com

; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> gmail-smtp-in.l.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1243
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;gmail-smtp-in.l.google.com.    IN      A

;; ANSWER SECTION:
gmail-smtp-in.l.google.com. 2   IN      A       0.0.0.0

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Apr 25 14:29:16 CDT 2021
;; MSG SIZE  rcvd: 71
Enter fullscreen mode Exit fullscreen mode

In ;; ANSWER SECTION: we see that the Gmail SMTP server URL is resolving to 0.0.0.0, which always means the machine itself. So emails sent to Gmail addresses are coming right back to the source machine.

Now we know our problem is on the DNS side. It could be a DNS server, DNS filtering service, firewall, or something similar. In my case, it was 2 Pi-hole blocklists, and whitelisting the server URL fixed the issue:

$ dig gmail-smtp-in.l.google.com

; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> gmail-smtp-in.l.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19729
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;gmail-smtp-in.l.google.com.    IN      A

;; ANSWER SECTION:
gmail-smtp-in.l.google.com. 599 IN      A       108.177.111.26

;; Query time: 25 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Apr 25 14:33:09 CDT 2021
;; MSG SIZE  rcvd: 71
Enter fullscreen mode Exit fullscreen mode

Aha, now ;; ANSWER SECTION: contains an IP address that at least looks more correct than 0.0.0.0 (TBH I have no idea what Google's SMTP server IPs are.)

The echo test command at the outset now works.

Discussion (1)