G Suite DKIM: Google Record and Brevo Setup

What is G Suite DKIM and where do you turn it on?

G Suite DKIM is the DomainKeys Identified Mail signing built into Google's business email, which Google renamed Google Workspace in 2020. The mechanism is defined in RFC 6376. Google's outgoing servers sign each message with a private key, and receiving servers fetch the matching public key from your DNS to check the signature. If you never set it up, Google still signs your mail, but with a default key on a Google-owned domain rather than your own. That signature passes DKIM, but it doesn't align with your From domain, so it does nothing for DMARC. To use your own domain, a super admin opens the Admin console and goes to Apps > Google Workspace > Gmail > Authenticate email. Select the domain, click Generate new record, pick a key length, and Google shows you the host name and TXT value to publish. Signing doesn't start until you come back to the same screen and click Start authentication. That step often gets forgotten, because publishing the DNS record feels like the finishing line.

What does a G Suite DKIM record look like?

A G Suite DKIM record is a TXT record in your domain's DNS. The host is the selector plus the fixed label _domainkey. Google's default selector is google, so the full name is google._domainkey.yourdomain.com. You can pick a different prefix when you generate the key, and that's useful if you're rotating keys or run several Workspace domains. The value starts with v=DKIM1; k=rsa; followed by p= and a long base64-encoded public key. Copy the value exactly as Google shows it. A missing character or a stray space in the p= string breaks the signature for every message.

Most DNS panels want the host without the domain: just google._domainkey. If you type the full name, many providers append the zone anyway, and you end up with google._domainkey.yourdomain.com.yourdomain.com. It's the same doubled-host problem described in our GoDaddy DKIM setup for Brevo senders. To check what's actually published, run dig TXT google._domainkey.yourdomain.com and compare the p= value character by character with the Admin console.

Should the Google DKIM key be 1024 or 2048 bits?

Pick 2048 bits unless your DNS host can't store it. Google offers both lengths, and a longer key is harder to factor. The catch is a DNS format limit. RFC 1035 caps a single character-string inside a TXT record at 255 characters, and a 2048-bit public key encoded in base64 runs well past that. Most modern DNS panels split the value into several quoted strings automatically. Receivers then join those strings back together before checking the key. Some older panels reject the value outright, or truncate it without telling you. A truncated key looks fine in the panel but fails at every receiving server.

1. 1 Generate the 2048-bit key in Authenticate email and copy the full TXT value.
2. 2 Paste it into your DNS panel as one TXT record at google._domainkey.
3. 3 If the panel refuses it, split the p= value into chunks of 255 characters or fewer, each in its own quotes, all inside one record.
4. 4 Query the record with dig and confirm the joined strings match Google's value exactly.
5. 5 If your provider can't handle multi-string TXT at all, generate a 1024-bit key instead. It's weaker, but a working key beats a broken one.

Why does DKIM still fail after publishing the Google record?

Publishing the record is only half the job. Google's admin help warns that DNS changes can take up to 48 hours to spread, and until the record resolves, the Start authentication button either fails or shows an error. When mail keeps failing after that, the cause is almost always one of a handful of things. Check them in Gmail by opening a received test message, choosing Show original, and reading the DKIM line along with the d= domain in the DKIM-Signature header.

• Start authentication never clicked: the record exists, but Google keeps signing with its default domain, so the d= value isn't yours.
• Doubled host name: the panel appended the zone to a fully qualified host, so the record sits at the wrong name.
• Truncated key: a 2048-bit value was cut at 255 characters by a panel that doesn't split strings.
• Wrong nameservers: the record was added at the registrar while DNS is actually served somewhere else.
• Body changed in transit: a mailing list or security gateway rewrites the message after signing, which breaks the body hash.

Does G Suite DKIM cover email sent through Brevo?

No. A DKIM signature is added by the server that sends the message, and Google's key only signs mail that leaves Google's own servers. When EmailFlow OS sends your outreach, it goes out from your own inbox address but through your own Brevo account and your own sending domain. It never goes through a shared platform sender. Brevo is the server doing the sending, so Brevo has to sign it, and Brevo gives you its own DKIM record to publish on your domain for that.

Here's how it works in EmailFlow OS. You record one video and upload it, connect your Brevo account and sending domain, and import your prospect list into EmailFlow OS. EmailFlow OS then builds a personalised version of that single recording for each recipient and sends each one via Brevo. Because the Google and Brevo keys use different selectors, both DKIM records can live on the same domain without clashing. Getting both in place before you ramp up volume is part of domain warm-up for cold outreach, and it's covered in more detail in our guide to cold outreach with EmailFlow OS.

How do SPF and DMARC fit with Google and Brevo on one domain?

DKIM is only one of three records mailbox providers look at. Since February 2024, Gmail has required SPF and DKIM from all senders, and DMARC as well from anyone sending more than 5,000 messages a day to Gmail addresses. With Workspace and Brevo sending for the same domain, these are the details that tend to go wrong:

• One SPF record only: RFC 7208 allows a single v=spf1 TXT record per domain. Merge Google's include:_spf.google.com and Brevo's include into that one record rather than publishing two.
• 10-lookup limit: SPF evaluation fails with a permerror once it needs more than 10 DNS lookups, and every include counts toward that limit.
• DMARC alignment: the d= domain in at least one passing DKIM signature, or the SPF domain, has to match your From domain. Under relaxed alignment a subdomain counts.
• Start with p=none: publish _dmarc with p=none and a rua address, read the aggregate reports for both senders, and only then move to quarantine or reject.

Header and structure requirements for the messages themselves are covered in our cold email format guide, which covers structure, headers and video.

Questions people ask

? Is G Suite DKIM the same as Google Workspace DKIM?

Yes. Google renamed G Suite to Google Workspace in 2020, and the DKIM feature didn't change. You still generate the key under Apps > Google Workspace > Gmail > Authenticate email, publish it as a TXT record at google._domainkey by default, and turn on signing with Start authentication.

? How long does Google DKIM take to start working?

Google's admin help says DNS changes can take up to 48 hours to propagate. Once dig returns the full TXT value at google._domainkey, you can click Start authentication. Signing then applies to new outgoing mail. Messages sent before that point keep Google's default signature on a Google-owned domain.

? Can I have two DKIM records on one domain?

Yes. Each DKIM record lives at its own selector, such as google._domainkey for Workspace and a separate selector for Brevo. Receivers read the s= tag in each message's DKIM-Signature header to know which key to fetch, so multiple keys don't conflict. SPF is different: that has to stay as one record.

? What happens if I skip DKIM for my own domain in Workspace?

Google still signs your mail, but with a default key on a Google-owned domain. DKIM passes, but it doesn't align with your From domain, so DMARC can only pass through SPF. That leaves mail exposed whenever forwarding breaks SPF, which happens often.