Email issues, might be MX records or something more subtle

[Gilbo]

Hey guys,

I moved a domain's email servers over to Google Apps today, and I have an odd issue. Users on 1 domain of our company, can't send email to those on the other. Everything is hosted on Google Apps for your Domain. The transition of both domains DNS happened about 6 hours ago today.


What Works:
1. Users of domain2 can send email to domain1 (just not vice versa).
2. Everyone can send email to the rest of the universe (i.e. I can send a test email from the troublesome domain to my personal email account).

What Doesn't Work:
1. Sending email from domain1 to domain2.


The error follows:

Delivery to the following recipient failed permanently:

xyz@canril.com

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 553 553 5.3.0 <xyz@90george.com>... no such user@90george.com - on relay of: MAIL FROM:<xyz@90george.com> (state 14).

I left the domains in there so you can look up the MX records yourselves, if it helps. I'll post them below in a second.

If I'm reading that correctly, it's complaining --not that the destination email account doesn't exist--, but that the sending one doesn't. WTF? For the record, the sending account exists. I can login into it, etc.

I've done DNSStuff.com checks on both domains to ensure the servers report the MX records correctly. They do.

This has been driving me batty all afternoon...

 

[Gilbo]

DNS records:


domain1 (gets bounces when sending to domain2)
domain2 (everything's okay --I think)



P.S. At the moment I think it's some sort of odd spam check where they check the existence of the sending email account, if they can. Maybe something about my current configuration is breaking that check?

 

[MaxBurn]

Can the rest of the world send email to both domains?

 

[Gilbo]

Yep. Domain1 & domain2 can both send and receive to other domains. I've verified this using my personal email address.


It's possible it might not work with other Google hosted domains, and/or other domains on our old ISP. I think there's something fishy going on with my old ISP which still does DNS (but no longer mail since I changed the MX records).


This is why I think this:

1. I used to get a similar error when I sent from a Google Apps test address. For example, if my ISP's mail server had an alias that pointed to "zyx@canril.test-google-a.com", I could send email from the Google account to anyone else, but if I sent it to someone on our domain, and the sending address didn't match (because the username was being changed for the new rollout - eg johndoe@domain1.com vs johnd@domain1.com) I would get the same error message.


The only thing is that only Google's servers should be in the loop and even if they check the user account's existence as a spam protection measure, it exists on their own servers! So what's the deal?

Could my old ISP be doing something odd here?

 

[Gilbo]

Hmmm. Even though the MX records were changed there were aliases on the ISPs management portal.

I've deleted all these and I'm not getting an error. Email is just not getting delivered silently, which is different at least...


I'm hoping the emails get delivered in a few hours, and everything starts working properly again.

 

[Gilbo]

Well a message to our ISP (who used to manage the email) has bounced with "554 recursive", which is new:

Delivery to the following recipient failed permanently:

canril02@magma.ca

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 554 554 5.0.0 rewrite: excessive recursion (max 50), ruleset canonify - on relay of: MAIL FROM:<xyz@90george.com> (state 14).

An email sent just before it to my personal address went through.

The email to domain2 is still MIA. I'm guessing it will probably fail in a bit .

 

[ddrueding]

That is interesting. I've moved a whole bunch of domains to Google Apps. Many still have the DNS hosted elsewhere, while new acquisitions use Google for everything. Give me a test account to send to and I'll test from some other Google Apps domains.

 

[Gilbo]

Hey Dave,

No need for a test address, you can just use my address, which is jonathan DOT guilbault AT canril.com.


We had no SPF configured. I don't think it's required, and not having it shouldn't have broken anything but I've set that up.


I think it may be a more subtle DNS issue. I think the way my CNAME and A records resolve might be causing a problem. I'm doing a little research and thinking about it. For now, here are the dns records:

For the MX records the first number is the TTL, the second the priority (i.e. 600 is the TTL, 100 is the priority in the first MX record).

canril.com. NS mag2.magmacom.com.
canril.com. NS mag1.magma.ca.
canril.com. NS mag3.magma.ca.
canril.com. 600 MX 100 aspmx.l.google.com.
canril.com. 600 MX 200 alt1.aspmx.l.google.com.
canril.com. 600 MX 300 alt2.aspmx.l.google.com.
canril.com. 600 MX 400 aspmx2.googlemail.com.
canril.com. A 206.191.51.136
www A 206.191.51.136
canril.com. 600 TXT "v=spf1 include:_spf.google.com ~all"

Specifically, I think the issue may be that there's a straight A record for Canril.com pointing directly to a server that's only a webserver.

Is that a problem? It exists to point people who type in "canril.com" straight to the webserver "www.canril.com", but could it be screwing up our Mail servers now that they're hosted outside the ISP hosting our website?


EDIT: But, I guess if that's the case, no one could email us... blech.

 

[Gilbo]

Sorry for the endless string of posts.


On the subject of A records (the end of the last post):


Maybe Google doesn't check SPF, but does Google check A records?

eg. Like Sonic.net in this help thread. That's why it fails if Google sends it. (Although it doesn't fail for GMail, but maybe they only do the check for Google Apps accounts?)

 

[Gilbo]

I'm probably going to delete that A record and see what happens.

Worst case is people have to type www.canril.com in lieu of canril.com to get to our website.

 

[ddrueding]

Message sent, no error returned.

 

[Gilbo]

Well it looks like other Google Apps domains are immune from whatever is affecting our particular domain. We seem to be able to send & receive with no problem.


I don't like the looks of this. It's starting to look more like some sort of odd bug.

I don't think deleting that A record is going to do anything .

 

[Will Rickards]

Here is my dns records for my google apps domain.

 

[Will Rickards]

I tried to see if you were on the spam blacklists and it says it can't get the IP for canril.com.
http://network-tools.com/default.asp?prog=sbl&host=canril.com
It works for 90george.
Looks like that A records was necessary for something.

 

[blakerwry]

Did you get this resolved?

I meant to spend some time looking at it, but got distracted. If you still have trouble I would be happy to take a look. I troubleshoot issues like these all day long.

 

[Pradeep]

DNS records:


domain1 (gets bounces when sending to domain2)
domain2 (everything's okay --I think)



P.S. At the moment I think it's some sort of odd spam check where they check the existence of the sending email account, if they can. Maybe something about my current configuration is breaking that check?

Yeah, to avoid spam problems most ISPs don't have open relays.

 

[Gilbo]

It seems to be mostly resolved. I still have email issues with one email user, but their account was created after the others and it may just be a delay thing.

I have to get the straight canril.com address pointing back to www.canril.com.

 

[Gilbo]

In the end, I think it was just DNS propagation issues and some type of SPAM protection on the receiving servers.

 

[blakerwry]

Changing DNS providers (SOA records) always takes 48 hours to cache out - because this is what the TLD root DNS servers use for all domains.

If you did not change DNS providers, and just chagned the MX records, then it's really up to your provider how long it takes for their records to cache out. Some use 10 minutes, while others use 10 days. It appears that your DNS provider - magma.ca uses 48 hours by default, but has set your new MX records for 10 minutes

The old records may have been 2 days, which means that some servers could have held on to the old records for that long. Ideally you can have your DNS provider update the TTL on records in advance of any changes. In this case, you'd have to have them update the TTL 2 days in advance of the actual MX change.

The other issue often involved in cases like these is that you may update the DNS records, servers, etc. But if you are still sending mail through a host configured manually (such as the previous MX server or a server that uses the previous DNS provider) your mail may deliver to the old server or fail altogether. This happens all the time when people change hosts, but forget to notify the old hosting provider (or the provider forgets to remove the domain). Mail traversing through the old hosting provider fails because they still have a manual definition for your domain pointing to one of their servers.

And the last issue we run unto are clients who do not honor DNS TTLs. This is quite common, as many clients will perform a DNS lookup on pop/SMTP server and then cache the result until the program is closed. Thus, any DNS changes do not take effect until the client is restarted, or worse the computer is rebooted. Both Microsoft and Mozilla products suffer from some form of connection information caching and need to be restarted when servers are updated/changed.


In any of the above cases, an NDR (bounce back) is probably going to provide the information you need to troubleshoot the problem. Pay special attention to both host names and IP addresses.

 

[blakerwry]

I should mention that everything looks OK at this point in time. Your MX records correctly point to google A records and those A records resolve just fine.

I would not expect to have any problems delivering to your domains.