Sign in

Google Apps Admin Help



Email gateway

Print

This article is for administrators with an advanced understanding of email delivery.

Table of Contents

Overview
Benefits
Inbound gateway
Dual deployment
Outbound gateway
Troubleshooting

Overview

An email gateway allows you to route all mail through your own network. This 'best practices' document describes the benefits of a gateway, offers step-by-step instructions to Google Apps administrators using Qmail, and provides helpful links to non-Google websites.

To set up an email gateway, you must be able to configure a mail transfer agent (MTA) on a server that you control and you must have access to a DNS lookup tool such as dig. The instructions for configuring your MTA will be specific to the software that you are using. This guide offers instructions for Qmail administrators, but you can adapt these instructions to your own brand of MTA software. Google does not support MTA configuration.

For additional assistance, we have a number of partners who can offer this service.

↑ back to top

Benefits

Some of the benefits of an email gateway are:

  • Archiving
    Ex. Save a copy of all messages
  • Filtering
    Adhere to message content policies (ex. filter sensitive content, such as social security numbers, or add a footer to all messages
  • Monitoring
    Ex. Keep track of volume and spikes
  • Compliance
    Meet auditing requirements for regulatory compliance, and data retention obligations for disaster recovery
  • Dual-deployment
    Simultaneously deliver mail to Google Apps as well as your existing system for particular users (users can try Apps with no risk), or redirect mail for certain users on the same domain to Google Apps (gradually migrate users)

↑ back to top

Inbound gateway

An inbound gateway manages email addressed to users at your domain.

Your mail transfer agent must be configured to route all inbound mail for your domain to the Google Apps mail servers.

In some cases, you will want to configure "dual deployment" in which mail is delivered to both your mail server and to the Google Apps mail servers. This requires some additional configuration steps after you have configured inbound mail routing.

Adminstrators of all Google Apps editions can configure routing and dual deployment for inbound mail.

Here are instructions for setting up your mail transfer agent to route inbound mail for your domain to the Google Apps mail servers.

  1. Configure your MTA to relay mail for mydomain.com:

    These are the commands to run on your MTA host if you are using Qmail.

    • Configure your mail server to accept mail for your domain.
      # echo mydomain.com >> /var/qmail/control/rcpthosts
      

    • Configure your mail server to route mail for your domain to a Google Apps mail server.
      # echo mydomain.com:aspmx.l.google.com >> /var/qmail/control/smtproutes
      

    • Tell Qmail to reread its configuration files.
      # svc -h /service/qmail
      
  2. Add an MX record for your mail server and remove all MX records pointing to Google after making note of their TTL (time to live) values, to be used in step 6.
    The method for changing MX records will depend on how you handle your DNS records.
    • If you manage your own DNS servers then you'll need to configure your name server software. An example of software for running DNS servers is TinyDNS. You should use small values for TTL (time to live) when testing your DNS settings so that you can quickly revert changes if needed.
    • If you have your own domain host, then you will need to use your domain host's web interface to set the MX records.
    • If you initially purchased your domain from Google Apps, you will be using the domain host provided by Google Apps. Instructions for accessing your domain host are below:
      • Log in to the control panel at https://www.google.com/a/mydomain.com (change mydomain.com to your actual domain name)
      • Click the Domain Settings tab
      • Click the Domain Names secondary tab
      • Click Advanced DNS settings

      You will see instructions for editing MX records on the Advanced DNS settings page.

  3. Verify that you have set the MX record correctly:

    $ dig mx mydomain.com | grep MX
    mydomain.com.      1800    IN      MX      10 mta-host.com.
    

    You should see the hostname of your mail server (shown here as mta-host.com). If the results still show MX records for the Google mail servers, you may be displaying the cached results from an earlier DNS lookup. You can try to run the command from another computer, flush the cache on your DNS server, or wait for the record to expire.

  4. Configure Google Apps to properly handle incoming mail from the gateway (Premier and Education Edition only):
    1. Log in to the control panel to manage your domain at https://www.google.com/a/mydomain.com (change mydomain.com to your domain name)
    2. Select the Service settings tab
    3. Select Email from the drop-down menu
    4. Add your inbound gateway's IP addresses to the Inbound gateway box. This will improve spam handling. Google will still provide spam filtering on mail from these servers, but proper gateway configuration will reduce the number of messages falsely marked as spam. If you're using Postini, make sure you add these addresses: 64.18.0.0/20 207.126.144.0/20.

  5. Verify that mail is delivered:

    Send a message to user@mydomain.com from a computer that gets the correct host when looking up the MX record. Then, log in to the Google Apps email account to verify that the message was received.

  6. Make sure only messages that pass through the gateway are delivered to your Google Apps users.
    • Wait for at least as long as the TTL (time to live) of the MX records pointing to Google removed in step 2. This ensures that all potential senders are now pointing to your gateway.
    • In the Email settings screen from step 4, check the Only let my users receive email from the email gateways listed above box. Note that this will cause Google Apps to reject incoming mail from all other servers.

↑ back to top

Dual deployment

After you have configured mail routing, you can make some additional configuration changes to allow "dual deployment" in which mail is delivered to an account on both your local mail server and on Google Apps. This is particularly useful during the testing phase of a Google Apps implementation because users can easily revert back to the original mail system.

We describe a method for setting up a dual deployment with a domain alias. This has several advantages over routing mail to a different Google Apps account. The from address of users will be their real email address which can help ensure that spam filters work correctly. In addition, when you switchover from the old mail system to the new system, users will have access to all the data that they created during the testing phase.

  1. Configure your MTA to deliver mail for mydomain.com to the local mail server:

    Here are the commands to run on your MTA host if you are using Qmail:

    # echo mydomain.com >> /var/qmail/control/locals
    

    Remove the entry for mydomain.com from /var/qmail/control/smtproutes that was entered in the steps above for routing mail. Then tell Qmail to reread its configuration files.

    # svc -h /service/qmail
    
  2. Set up a domain alias:
    • Log in to the Google Apps control panel to manage your domain at https://www.google.com/a/mydomain.com (change mydomain.com to your actual domain name)
    • Select the Domain Settings tab
    • Select the Domain Names secondary tab
    • Click the Add a domain alias link
    • Add a subdomain to the text box, such as g.mydomain.com
    • Click the Continue and set up email delivery button
    • Click the I've completed these steps button

    You will see a message like this in the Domain Names tab:

    Domain alias g.mydomain.com    - Updating... This may take up to 48 hours to complete.
    
  3. Create an MX record for the domain alias:

    You will need to set up an MX record so that mail for g.mydomain.com is delivered to the Google mail servers listed here. See the instructions above for how to change MX records for your domain.

  4. Verify that your MX record has been created:
    $ dig mx g.mydomain.com | grep MX
    g.mydomain.com. 1800	IN	MX	10 aspmx.l.google.com.
    
  5. Wait for the domain alias to be verified:

    When the alias is added to your control panel and the MX records are properly configured, you will see a message like this in the Domain Names tab:

    Domain alias g.mydomain.com    - Active
    
  6. Forward mail for selected users to Google Apps:
    # echo "&user@g.mydomain.com" > ~alias/.qmail-user
    # chown alias:nofiles ~alias/.qmail-user
    # svc -h /service/qmail
    
  7. Verify that mail is successfully delivered to Google Apps:

    Verify that mail to your domain alias is working by sending email to user@g.mydomain.com. Then, log in to the Google Apps user account for mydomain.com and verify that the message was received.

    Verify that mail sent through your gateway is working by sending mail to user@mydomain.com.

↑ back to top

Outbound gateway

An outbound gateway manages email sent from users at your domain.

You must have the Education or Premier Edition to utilize the Google Apps outbound gateway feature.

  1. Configure Google Apps to route outgoing mail to your SMTP server:
    • Log in to the control panel to manage your domain at https://www.google.com/a/mydomain.com (change mydomain.com to your domain name)
    • Select the Service Settings tab
    • Select Email from the drop-down menu
    • Add the IP address or hostname of your SMTP server to the Outbound gateway text box.
  2. Get the IP addresses used by the Google mail servers:

    You can get the up-to-date range of IP addresses used by Google to send mail by querying Google's DNS for its SPF records:

    $ dig txt _spf.google.com | grep spf
    _spf.google.com.	300	IN	TXT	"v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 
    ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ?all"
    
    

  3. Configure your mail transfer agent to selectively relay email sent from Google Apps:

    Follow Qmail's instructions for allowing selected clients to send outgoing messages.

    # cat <<EOF >> /etc/tcp.smtp
    > 216.239.32-63.:allow,RELAYCLIENT=""
    > 64.233.160-191.:allow,RELAYCLIENT=""
    
    > 66.249.80-95.:allow,RELAYCLIENT=""
    > 72.14.192-223.:allow,RELAYCLIENT=""
    > 209.85.128-159.:allow,RELAYCLIENT=""
    > 66.102.0-15.:allow,RELAYCLIENT=""
    > EOF
    # tcprules /etc/tcp.smtp.cdb /etc/tcp.smtp.tmp < /etc/tcp.smtp
    

  4. Modify your SPF records (if required):

    If you have configured your DNS servers to provide SPF records for your domain, then you will need to ensure that the Google mail servers and your outbound gateway addresses are included in the SPF record.

  5. Verify that outbound mail sent through your gateway is working:

    Send an email from Google Apps to a user outside your domain.

↑ back to top

Troubleshooting

  • If outbound mail bounces with this error, then you may not have configured the smtproutes file.
    Sorry. Although I'm listed as a best-preference MX or A for that host, it isn't in my control/locals file, so I don't treat it as local.

  • If mail to the domain alias bounces with this error, then check that Google Apps shows the domain alias is Active.
    No such user

  • If outbound mail bounces with the following error, it means that you may not have correctly configured selective relaying.
    sorry, that domain isn't in my list of allowed rcpthosts

  • If you need to troubleshoot a problem sending outbound mail, note that the original message that is sent back in the mail bounce doesn't contain the public IP address of Google's mail server. You can get this IP address from the logs of your SMTP server. For example, you will see the following in Qmail's logs:
    @4000000046659c1e2281a804 tcpserver: ok 13942 :65.61.157.245:25 py-out-1112.google.com:64.233.166.180::34385

↑ back to top

updated 7/27/2009

Was this information helpful?

Tell us how we're doing: Please answer a few questions about your experience to help us improve our Help Center.