Setting up G Suite Through Cloudflare

dns

#1

My site is hosted through iPage, and after having some issues with Outlook, I decided to buy a year of G Suite, but I’m having trouble setting it up.

I’ve verified my site, but I need to alter the MX records, and I’m not sure how to edit them through Cloudflare. Here’s what I need, according to Google:

MX records may be located in DNS Management, Mail Server Configuration, or Name Server Management. You may have to enable advanced settings to edit your MX records.

Delete all existing MX entries. By default, MX records may already be present.

Enter the following MX records.

You may not be able to enter the priority value exactly as it appears in the table below—if you can, make sure each record follows the indicated order. If you aren’t able to assign priorities, you should only enter aspmx.l.google.com… Set any TTL values to 1 Hour (value=3600).

And then it lists five entries, starting with APMX and followed by four alt tags. Sorry if this is a dumb question and those instructions are crystal clear to everyone else, I just don’t know email settings very well.


#2

The DNS tab here at Cloudflare will let you add MX records. The first value would be a @ for your domain email, and a window will pop up where you can enter one of those aspmx records with the varying priorities. Then do this for the other aspmx records. I don’t know those alt tags would be. MX records are pretty basic.


#3

The “alt tags” are just the names of their MX servers, which they recommend entering as follows:

|Blank or @|3600|MX|1|ASPMX.L.GOOGLE.COM.|
|Blank or @|3600|MX|5|ALT1.ASPMX.L.GOOGLE.COM.|
|Blank or @|3600|MX|5|ALT2.ASPMX.L.GOOGLE.COM.|
|Blank or @|3600|MX|10|ALT3.ASPMX.L.GOOGLE.COM.|
|Blank or @|3600|MX|10|ALT4.ASPMX.L.GOOGLE.COM.|

This is 5 separate MX records in a row, with priorities of 1, 5, 5, 10 and 10 respectively.


#4

Also, these steps are backwards… you should add the new MX records and then delete the old ones. I don’t know why every hosted mail provider gets this backwards.


#5

In principle, I agree completely. When I ran a small hosting provider I too said to delete first. Not at first, but I learned why eventually:

  1. Start with the easy steps. Adding the record is harder, and if a user encounters errors (my provider won’t accept 0, it says a trailing dot is invalid, my provider only allows fixed 10,20,30,40,50 priorities but the instructions say to use 5), then the user will resolve these, pat themselves on the back for a job well done and go for a lobster dinner. Only later will anyone notice their mail is still hitting the old provider because they left old records in place.

  2. Deleting records first always works, adding new records first doesn’t. e.g. you can’t add a www CNAME if there are www A/AAAA records in place. I know of one managed DNS provider that only allows one record of a single type: One www A record, one www AAAA record, and only one MX+priority combination for each label. Gross. But delete-first works for all of these weird cases, while add-first only usually works.

And I know I said 2, but a 3) Any well designed DNS management tool will only apply changes when the user is done (apply button), so in reality the order doesn’t matter. This is the only safe way of updating DNS records without dropping any traffic at all due to #2. This doesn’t apply to MX records but it potentially can to any other type of record that needs to be updated in lockstep with matching records, especially when CNAMEs are involved.

Luckily most end users don’t care that much when small glitches happen during updates/migrations, so real-time interfaces only cause a small set of issues.


#6

Yeah… our DNS updates are immediate so the steps could lead to a gap, but I totally understand how users can manage to muck up the works. After 15 years as a mail admin I get a little hypersensitive over little things. :wink:


#7

Agreed. I’d literally rather do it for a customer so that I can do it right than risk they’ll muck up a live email flow. Email (and to a lesser extent DNS) have been my career and I’m definitely a fan of doing it right.

But when a customer of unknown skill is involved, all bets are off.


#8

Thanks for the help everyone. I was worried over nothing, it was straightforward enough. I’d rather be over cautious than screwed. I genuinely appreciate the advice, cheers!


#9

This topic was automatically closed after 14 days. New replies are no longer allowed.