Press "Enter" to skip to content

Tag: gmail

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 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 (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: DNSSec signed Google Apps/G Suite Email

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

PriorityMail Server (MX Entry)
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 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)
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 which are correctly configured.

Request Tracker (RT) and Google Apps

If you are trying to setup Best Practical’s Request Tracker (RT) system (originally written by Jesse Vincent, but I more associate Dave Rolsky with it), to work with a Google Apps hosted domain (so you have Google Mail/Gmail for your domain), you may find the following useful.

  1. First of all, install “rt” on your Linux box and install “fetchmail” using your package manager if it isn’t already installed
  2. Setup an email account something like “support@” or “rt@” (I’ll use “rt@” in these examples) in Google Apps. Make a note of the password you set
  3. In /opt/rt3/etc/ (if you used the default install location), you’ll need to set the following:
    Set( $RTAddressRegexp,'^rt(\+[a-z]+)?\@example\.com$');
  4. Do the basic configuration of “rt” and make your queues – I made the following queues:
    Queue name Reply address Comment address
  5. Log into your new Google Apps Gmail account with the details you created and agree to the terms of service etc
  6. Click on “Settings” and “Filters” and create a series of filters such as:
    • To: [Next step]
    • Skip the Inbox (Archive it)
    • Apply the label: backend
    • Never send it to Spam [Create filter]
    • To: [Next step]
    • Skip the Inbox (Archive it)
    • Apply the label: backend-comments
    • Never send it to Spam [Create filter]
  7. For the “general” queue’s “Reply” address (, do not setup a filter
  8. Once done, on your Linux server where you have installed the Request Tracker, edit /etc/fetchmailrc to read similar to:

    set daemon 60
    set invisible
    set no bouncemail
    set no syslog
    set logfile /var/log/fetchmail
    proto IMAP service 993 user pass PA55W0RD
    folder Inbox ssl
    mda "/opt/rt3/bin/rt-mailgate --url --queue General --action correspond"
    proto IMAP service 993 user pass PA55W0RD
    folder general-comments ssl
    mda "/opt/rt3/bin/rt-mailgate --url --queue General --action comments"

    proto IMAP service 993 user pass PA55W0RD
    folder backend ssl
    mda "/opt/rt3/bin/rt-mailgate --url --queue Backend --action correspond"
    proto IMAP service 993 user pass PA55W0RD
    folder backend-comments ssl
    mda "/opt/rt3/bin/rt-mailgate --url --queue Backend --action comments"

    Of course changing to the email account you created, PA55W0RD to the password set for that email account, to the location of your Request Tracker installation (it has to be accessible from the server you are creating this file on), the “folder” name to correspond with the label you set for that queue and comments, etc and repeating for as many queues as you have.

  9. Save the file and start fetchmail using /sbin/service fetchmail start or your Linux distribution’s service starter
  10. Watch the log file using tail -f /var/log/fetchmail

    And that should be RT up and running with Google Apps for you!