DMARC Setup for Google Workspace: The Step Almost Everyone Skips

The default that quietly breaks DMARC

Google Workspace signs your outbound mail with DKIM before you configure anything. The signature is real and it verifies correctly. The problem is which domain it signs as.

Until you generate your own key, Google signs with a shared infrastructure domain that looks like yourdomain-com.20230601.gappssmtp.com. DKIM means DomainKeys Identified Mail, a cryptographic signature that proves a message was not altered and was sent by whoever controls the signing domain.

DMARC does not care whether a signature verifies. It cares whether the signing domain lines up with the domain in your visible From address. That test is called alignment. A signature from gappssmtp.com can never align with yourcompany.com, because Google owns gappssmtp.com and thousands of other tenants share it.

So DMARC quietly falls back to SPF alone. SPF holds up fine on a direct send. It breaks the moment someone forwards your email or a mailing list relays it, because the forwarding server is not on your SPF list. At that point you have no passing mechanism left. If your policy is set to p=reject, that message is gone and nobody is told.

This is why "Google already does DKIM" is one of the most expensive half-truths in email. Fixing it takes about twenty minutes and one waiting period.

Before you start: the 24 to 72 hour wait

If you turned Gmail on for your domain in the last few days, the Admin console will not hand you a DKIM key yet. Google requires you to wait 24 to 72 hours after enabling Gmail before key generation becomes available.

If you click Generate new record and get an error saying the record could not be created, this is almost always the reason. It is not a broken account. Wait a day and try again.

You also need to be signed in as a super administrator, or hold a custom admin role that includes the Gmail Settings privilege. We cover how to grant that safely further down.

Step one: get SPF right first

Google's own documentation is explicit that you should have SPF or DKIM working before you publish a DMARC record, and that you should allow 48 hours after setting them up before you turn DMARC on. Publishing DMARC first is how people bounce their own invoices.

SPF stands for Sender Policy Framework. It is a DNS record listing which servers may send mail for your domain.

This record lives at your DNS host, not in Google Workspace. Google generates keys, it does not host your zone.

• Record type: TXT
• Host or Name field: @ (this means the root of your domain)
• Value: v=spf1 include:_spf.google.com ~all
• Only one SPF record is allowed per domain. If you already have one for a CRM or invoicing tool, merge the include: statements into a single record rather than adding a second one. Two SPF records is a permanent error, not a warning.
• SPF allows a maximum of 10 DNS lookups. Each include: counts. Blow past 10 and the whole record fails.
• Google recommends ~all (softfail) rather than -all (hardfail).

Step two: generate the key in the Admin console

This is the step with no shortcut. There is no Admin SDK endpoint and no API for generating a Google Workspace DKIM key. It has to be done by a human clicking through the Admin console. Any service claiming full automation is either doing this by hand behind the scenes or driving your browser.

Sign in at admin.google.com and follow this exact path, using the labels as the interface names them:

Menu, then Apps, then Google Workspace, then Gmail, then Authenticate email.

Pick your domain from the Selected domain menu. If you run multiple domains or domain aliases, note that each one needs its own key. Generating a key for the primary domain does nothing for the others.

Click Generate new record. You get two choices.

• DKIM key bit length: choose 2048 if your DNS host supports it. Choose 1024 only if your host cannot handle long TXT values. 2048 is stronger and is Google's recommendation.
• Prefix selector: the default is google, which produces a DNS host of google._domainkey. Leave it alone unless your domain already uses the google selector for something else, in which case pick a different prefix and remember what you chose.

Step three: publish the TXT record, and mind the host field

Google now shows you two values: DNS Host name (TXT record name) and TXT record value. Copy both into your DNS host's control panel.

The host field is where most setups silently fail. Most DNS providers auto-append your domain to whatever you type. So if you paste the full google._domainkey.yourcompany.com into a field that appends, you publish a record at google._domainkey.yourcompany.com.yourcompany.com. Nothing errors. Nothing warns you. The record simply does not exist where Google looks for it.

The rule: at most hosts, enter only google._domainkey and let the host add the rest. A few hosts want the fully qualified name. If you are unsure, publish it, then query it and see what actually answers.

The value starts with v=DKIM1; k=rsa; p= followed by a long base64 key.

• A single TXT string is capped at 255 characters. A 2048-bit key exceeds that, so it cannot be entered as one string.
• Some DNS panels split long values for you automatically. Some silently truncate them, which produces a record that looks fine and never validates.
• If your host does not split automatically, break the value into chunks and wrap each chunk in its own set of double quotes, one after another in the same value field. Google's documentation shows this format explicitly.
• Do not add line breaks or spaces inside the base64 key itself.
• Leave TTL at your host's default, commonly 3600 seconds. A low TTL does not speed up first publication, since there is nothing cached to expire. It only helps later if you rotate the key.

Step four: click Start authentication

Go back to the Authenticate email page and click Start authentication.

This is the single most common reason a correctly published record does nothing. The DNS is right, the key is right, and Google is still signing with gappssmtp.com because nobody told it to switch over. Publishing the record is only half the job. Google will not start using the key until you press the button.

If it fails, your DNS has not propagated yet. Give it up to 48 hours and try again. Do not regenerate the key, because that produces a new value and invalidates the record you just published.

Step five: publish the DMARC record

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It tells receiving servers what to do when SPF and DKIM both fail to align, and it asks them to send you reports.

Wait 48 hours after DKIM starts authenticating, then add one more TXT record at your DNS host.

Start at p=none. This changes nothing about delivery and simply collects data. Read the reports for two to four weeks, confirm every legitimate sender is aligning, then move to p=quarantine, then p=reject. Jumping straight to reject is how a company loses a month of order confirmations.

• Record type: TXT
• Host or Name field: _dmarc (the same auto-append trap applies here)
• Starting value: v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com
• The rua address receives daily XML reports. These are machine-readable, not human-readable. Point them at a parsing service or you will never open them.
• The pct tag takes a whole number from 1 to 100. If you leave it out, the policy applies to 100 percent of your mail.
• Add adkim=s and aspf=s only once you are confident. Those switch alignment from relaxed to strict and will break subdomain senders.

How to actually check it worked

A green tick in the Admin console tells you Google accepted the record. It does not tell you your mail is aligning in the real world. Check both ends.

First, query DNS directly. From a terminal, run nslookup -type=TXT google._domainkey.yourcompany.com 8.8.8.8 and confirm a v=DKIM1 record comes back in full. Do the same for _dmarc.yourcompany.com. Querying against 8.8.8.8 rather than your local resolver rules out a stale cache in your own network.

Second, and this is the check that matters, send a message to an address outside your organisation and inspect it. In Gmail, open the message, click the three dots, choose Show original. You will see a summary table for SPF, DKIM and DMARC.

Look at the d= value on the DKIM line. It must say your domain. If it still says gappssmtp.com, signing is not live regardless of what the Admin console shows. DMARC should read pass. Better still, forward that message from a different mailbox and check again. Surviving a forward is the whole point, because that is the case SPF cannot cover.

One quirk worth knowing: Gmail only checks the first five DKIM signatures on a message. If your mail passes through a gateway that adds signatures, yours can fall outside that window.

Letting someone help without handing over your password

Google Workspace has proper delegated administration, so nobody ever needs your login. Create a custom admin role and assign it. A super administrator does this at Account, then Admin roles, then Create new role.

Under Privileges, expand Services, then Gmail, and tick Settings. That grants access to Gmail configuration including the Authenticate email page, and nothing else. No mailbox access, no user management, no billing. Assign the role to the helper's account, and remove it when the work is done.

Worth knowing: a user with a custom admin role can never modify your account or any other administrator's account. That limit is built in.

Note that this covers the Google side only. Your DNS records live with your registrar or DNS host, which is a separate system with its own access model. Most decent DNS providers have their own delegated user or team feature. Use that rather than sharing a login.

We work exclusively through delegated roles like these. We do not accept passwords, government IDs, or card numbers from clients, and we will not ask for them. If anyone helping with your email authentication asks for your Workspace password, that is the moment to stop.

What Google Workspace cannot do for you

Being honest about the edges saves you a support ticket.

Google Workspace does not host your DNS. The Admin console generates the key and then hands you text to paste somewhere else. Google Domains is gone, sold to Squarespace. Every DNS change happens at your registrar.

There is no API for DKIM key generation. You can automate the DNS side if your provider has an API, but the key itself requires a person in the Admin console.

Google does not read your DMARC reports. The rua address collects raw XML from every receiving server on the internet. Google Postmaster Tools at postmaster.google.com shows you spam rate, reputation and authentication pass rates for mail sent to Gmail recipients, which is genuinely useful, but it is not a DMARC report parser and it only covers Gmail.

Google only signs mail that leaves through Google. Your invoicing tool, your CRM, your marketing platform and your helpdesk each send as your domain through their own servers. Each needs its own DKIM key and its own SPF entry. Turning on Workspace DKIM does nothing for them, and they are usually what breaks a move to p=reject.

Finally, none of this is a deliverability guarantee. Authentication removes a reason to reject you. It does not override sending reputation, content filtering, or list quality.

If you would rather not do this yourself

Everything above is genuinely doable in an afternoon by anyone comfortable editing DNS. If you have one domain, one sending platform and a bit of patience, do it yourself and keep the money.

Where people tend to want help is the messy version: several domains, a dozen third-party senders nobody documented, an SPF record already over the lookup limit, and a DMARC policy that has to move to reject without dropping legitimate mail. That is the work we do at Verified Everywhere. We operate through delegated admin roles, never passwords, and we tell you what we changed and why. If that is useful, get in touch. If not, the guide above is the whole method.