Press "Enter" to skip to content

Tag: email

DNSSec signed Google Apps/G Suite Email

I’ve been using Google Apps, aka Google Workspace aka Google Suite (or just G Suite) for a while now and it’s annoyed me that I was getting “marked down” on e-mail security testers such as Internet.nl and the UK Government’s National Cyber Security Centre (NCSC) Check Your Email Security Service because Gmail for Business (G Suite) didn’t support DNSSEC (Domain Name System Security Extensions) signed MX hosts.

However, I’ve managed to find Google’s DNS Sec settings which – combined with other setups on my main domains – mean I get 4 green ticks from the NCSC, 97% from Internet.nl (I’m let down by Google’s support of old TLS and Ciphers settings and no DANE TLSA records) and all green (apart from DANE) on Hardenize : so nice strong secure email!

Read more

Google normally suggest you use the following MX (Mail Exchanger) records in your DNS settings if you use G Suite:

PriorityMail Server (MX Entry)
1ASPMX.L.GOOGLE.COM
5ALT1.ASPMX.L.GOOGLE.COM
5ALT2.ASPMX.L.GOOGLE.COM
10ALT3.ASPMX.L.GOOGLE.COM
10ALT4.ASPMX.L.GOOGLE.COM
The normal suggest Google Suite Email Servers for Businesses

(The records can actually be in any order and the priority can be anything – but Google do recommend that aspmx.l.google.com is set as the “highest priority” which is actually 1)

However, after a bit of searching (using DuckDuckGo and not Google 😉 ), led me to a blog post by Nis Bornoe and Kura the following G Suite DNSSEC signed MX records:

Google’s DNSSEC Signed Mail Servers (MX Entry)
mx1.smtp.goog
mx2.smtp.goog
mx3.smtp.goog
mx4.smtp.goog
Google’s “hidden” DNS SEC Signed MX Records

These domains are hosted on Google owned Charleston Road Registry (CRR)’s .goog top level domain (not to be confused with their .google and .gle brand top-level domains: or the 98 other ones they applied for) and .goog domains can “only be registered to Google Inc and its affiliates” so you’ve got some confidence they are legitimate.

However, whilst myself and Nis and Kura do not seem to have had any problems using these IPv4 and IPv6 supported DNSSEC signed nameservers (and according to DNSlytics and WhoisXMLAPI there are over 930 domains currently using them), they are not officially supported or documented (from what we can find) and have been running since at least 2019 – so they should be reasonably safe to use.

The only “catch” may may be that, for some reason, they do NOT have a reverse DNS (Pointer aka PTR) record setup – which is actually only a problem if those mail servers are use for sending OUT email (not just receiving it) – however, many only testers do assume that your inbound and outbound mail servers are the same. I can confirm, via a test email, that outbound mail goes out via servers such as mail-wr1-f52.google.com which are correctly configured.

Techy: Removing an rate limit block from Exim

During testing/investigation of an issue, I had to send “bad emails” to my Exim based mail server which after a number of attempts blocked me using the rate limit that had been configured:

451-The server has reached its limit for processing requests from your host.
451 Please try again later.

I didn’t want to wait for over an hour for the block to clear so I had to find out how to clear the block manually. On the mail server, I found the Exim data files in /var/spool/exim/db and using the exim_dumpdb tool to view the “ratelimit” block list:

# exim_dumpdb /var/spool/exim/ ratelimit

and then limiting it to the sending IP address (which I had checked via /var/log/exim_rejectlog ):

# exim_dumpdb /var/spool/exim/ ratelimit | grep 2001:db8:9:a::
28-Oct-2022 16:50:01.247104 rate:      1.877 key: 1h/per_mail/2001:db8:9:a::
28-Oct-2022 16:50:14.986765 rate:      1.937 key: 1h/per_conn//2001:db8:9:a::

Okay, that’s confirmed the block – but now to remove it. To do this, I had to use the “practically no documentation and no ui” tool exim_fixdb :

exim_fixdb /var/spool/exim/ ratelimit

It then just showed a prompt “>” with no instructions. But if the “key” was provided:

# exim_fixdb /var/spool/exim/ ratelimit
Modifying Exim hints database /var/spool/exim//db/ratelimit
> 1h/per_mail/2001:db8:9:a::
28-Oct-2022 16:50:01
0 time stamp: 28-Oct-2022 16:50:01
1 fract. time: .247104
2 sender rate: 1.877

Pressing “d” then deleted that record (and I repeated it for the other entry). Once I had finished, I just used “q” to quit exim_fixdb.

Hope it helps!

Bug Report: [WontFix] cPanel Outbound emails to account holders from cpanel@ domain can fail SPF checks

In an effort to prove to myself that I am actually trying to do work this last month, I’m making a note of all the bugs in 3rd party software I find.

Today is a bug reported to cPanel Inc on the 6th June 2022 under their tracking request ID 94453274 affecting outbound emails sent from servers running their WHM/cPanel software to web hosting customers whose account has an notification.