Setting up SPF, DKIM and DMARC for Google Workspace

According to Google’s documentation, if you send only through Google Workspace the record is v=spf1 include:_spf.google.com ~all. Nothing needs to be done in the Admin console; the record goes into your domain’s DNS and can take up to 48 hours to start working. Each domain has one SPF record: any other sending services go into the same record, and it must not exceed 10 DNS lookups.

Google recommends ~all; with -all, it says, receiving servers may reject messages from senders not in the record. For DMARC the difference narrows: DMARC asks whether SPF passed aligned, and softfail and fail both mean it did not.

If you send only through Google Workspace:

ornek.com.tr  TXT  "v=spf1 include:_spf.google.com ~all"

The DKIM key is generated in the Admin console: Menu > Apps > Google Workspace > Gmail > Authenticate email. Only a super administrator can do this. According to Google, after Gmail is turned on for your organisation you must wait 24–72 hours before the key is available in the console.

For key length choose 2048 bits if your domain provider supports it, 1024 bits if it does not. The selector prefix defaults to google, which is the recommended option for Google Workspace; if your domain already has a key with the google prefix, you enter a different one. The record is a TXT record named google._domainkey with a value of the form v=DKIM1; k=rsa; p=….

After adding the record to DNS, go back to the console and click Start authentication. Google says DKIM can take up to 48 hours to start working; once the status reads “Authenticating email with DKIM”, signing is on.

A 2048-bit key does not fit in a single 255-character text string in DNS. Google’s fix is to split the key into several strings, each in its own quotes; if your DNS panel does not allow that either, fall back to the 1024-bit option.

Format (key shortened; take the value from the console):

google._domainkey.ornek.com.tr  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…" "…IDAQAB"

Google asks you to set up DMARC at least 48 hours after SPF and DKIM; if DMARC is turned on before SPF and DKIM are set up, mail from your domain may run into delivery problems. The record is a TXT record named _dmarc. Google’s recommended start is one week of p=none, then quarantine and reject. rua is optional but Google recommends always including it; Gmail does not support the ruf tag and sends no failure reports.

Google’s rollout example uses intermediate percentages such as p=quarantine; pct=5. RFC 9989 no longer defines pct; according to its Appendix A.6, intermediate values were applied differently from one receiver to the next. If you want a test phase, write pct=0; t=y together: a receiver following the new standard reads t=y, one following RFC 7489 reads pct=0, and both apply the policy one level lower.

Starting point:

_dmarc.ornek.com.tr  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@ornek.com.tr"

Test phase (one level lower under both standards):

_dmarc.ornek.com.tr  TXT  "v=DMARC1; p=quarantine; pct=0; t=y; rua=mailto:dmarc@ornek.com.tr"

Using Google Workspace does not exempt you from Gmail’s sender rules. According to Google, senders of more than 5,000 messages a day must set up all three of SPF, DKIM and DMARC; the minimum for every sender is one of SPF or DKIM. These rules apply only to mail sent to personal Gmail accounts.

In Mailskop’s September 2026 measurement, 49.5% of the 2,546 domains detected as running on Google Workspace had no valid DMARC record; 8.0% enforced reject. In the same measurement, 37.9% of Microsoft 365 domains had no DMARC.

Because the selector prefix can be changed in Google Workspace, Mailskop does not say DKIM is off when it finds no record at google._domainkey; it only reports that no record is published at the default prefix. In Microsoft 365 the selector names are fixed, so there absence is proof.