First off, you can tell which profile is currently applied to a given machine by viewing the Windows Firewall properties dialog, shown here:

The box in red shows that this machine is receiving the standard profile. In order to determine whether to apply the standard or domain profile, Windows attempts to detect whether you are on the network where your AD domain exists or on another network. It does this in a fairly non-obvious way. When Group Policy is processed, the DNS suffix of the network connection that you are receiving Group Policy updates on is stored in the registry with the value: HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy\History\NetworkName. The next time that the computer is restarted or whenever a network connection change is detected (e.g. you connect to a new network or get a new IP address), the DNS suffix of the new connection is evaluated against the one stored in NetworkName. If they are different, then it is assumed that you are not on the AD network and therefore the standard profile is applied to the computer. If they are the same, then the domain profile is applied.

There are a couple of limitations with this approach. First off, PPP and SLIP type connections are ignored from this equation. This means that VPN connections are essentially always treated as standard profile (at least in the testing I've done). The other limitation is that it is fairly easy to circumvent this system by hard-coding a DNS suffix within the TCP/IP properties of a connection. For example, lets say that you normally connect to your AD network using a Wireless connection and that your AD DNS suffix is cpandl.com. If you hard code that DNS suffix into that wireless connection's TCP/IP properties and then go to your local Starbucks for a little WiFi action with your double, wet, non-fat caramel macchiato, your machine will look at the hard-coded DNS suffix and compare it to the suffix when you were on your AD domain, see that they are the same and assume you are still on the corporate network. This could be bad if the domain profile specifies to disable Windows Firewall. So, its important that if you're using different profiles, that DNS suffix is supplied by DHCP rather than hard-coded.