When you're setting up email authentication, you'll encounter DomainKeys Identified Mail, or DKIM. A DKIM record is a special entry in your DNS that contains a public key. Recipient mail servers use this key to verify a digital signature attached to your emails, confirming that your message hasn't been tampered with and truly comes from your domain. This DNS record is made up of several 'tags', which are essentially settings. One of these is the g= tag, and its purpose can be a bit confusing at first.
The g= tag is an optional but useful part of the DKIM standard that allows for more specific control over your email signing policy. Let's break down what it does and how it works.
A DKIM record is a TXT record in your domain's DNS. Its content is a string of tag-value pairs separated by semicolons. As Hostinger explains, a tag is usually a single letter followed by an equals sign, and the value provides specific information. For example, the v=DKIM1 tag specifies the version, and the p= tag contains the actual public key data. While the p= tag is the only one that is strictly required, other optional tags like g= provide additional functionality.
The g= tag stands for "granularity". Its purpose is to limit which sending addresses are authorized to use a specific DKIM key. Essentially, it adds a layer of precision to your DKIM policy by tying a key to a specific user or a pattern of users at your domain.
The value you set for the g= tag is checked against the "local-part" (the part before the @ symbol) of the email address listed in the DKIM signature's i= tag (the identity tag). If they match, the signature is considered valid for that sender. If they don't match, the verification may fail.
The most common value for the g= tag is a single asterisk: g=*. This is a wildcard that means the DKIM key is valid for any user at the domain. If you omit the g= tag entirely from your DKIM record, it defaults to this wildcard behavior. This is why many standard DKIM setups don't explicitly include the tag; it's not needed for a general, domain-wide policy.
However, you can set it to a specific value for tighter control. Here are a few examples:
Using specific granularity is an advanced technique. You might do this if you have different systems sending email and want to issue separate, restricted keys for each one. For example, your automated billing system could have a key with g=billing, while your marketing platform uses a separate key with g=marketing. This segmentation can enhance security by limiting the impact if one key is ever compromised.
In short, the g= tag in a DKIM record controls the granularity of the public key, determining which user-level addresses are permitted to use it for signing. While it is optional and defaults to a wildcard (g=*) that allows any user, setting a specific value offers a powerful method for creating more precise and secure email sending policies.