What is the SPF record for Google Workspace?

For a domain that sends only through Google Workspace it is one TXT record on the root of the domain with the value v=spf1 include:_spf.google.com ~all. Google asks for the tilde rather than a hyphen, because a hard fail can block legitimate mail. A domain gets one SPF record, so merge any other senders into that same line.

Why is my DKIM record not available in the Admin console?

Google says to wait 24 to 72 hours after turning on Gmail for the domain before the key can be generated, and trying earlier returns a DKIM record not created error. You also need the Gmail Settings administrator privilege to see the Authenticate email page where the key is generated.

Can I start DMARC at p=reject straight away?

You can, and it is the fastest way to lose real mail. Google recommends a week at p=none while you read the daily reports, then quarantine for a small percentage using the pct tag, raised over time toward 100%. Reject means failing messages are never delivered, so every legitimate sender has to be authenticated first.

Google Workspace SPF record, DKIM and DMARC: exact values

Say a 12-person accounting firm moves to Google Workspace on a Friday. Mail flows, everyone is happy, and nobody opens the DNS panel again. Six weeks later the quarterly statements start landing in spam, a client swears a reminder never arrived, and somebody asks whether the email is broken.

It is usually not broken. It is unauthenticated, or authenticated in a way that does not line up with the address in the From line. Google Workspace does not publish DNS for you. You publish three records, and the order matters: SPF and DKIM have to be signing real mail before DMARC can tell you anything useful. Here are the exact values and the sequence we use on client domains, with the Admin console paths checked against Google Workspace Admin Help on 16 October 2026.

SPF: one include, and the tilde Google asks for

SPF lists the servers allowed to send mail for your domain. For a domain that sends only through Google Workspace, Google Workspace Admin Help gives one record, published as a TXT record on the root of the domain (host @ at most DNS providers):

Type: TXT
Host: @
Value: v=spf1 include:_spf.google.com ~all

The qualifier is a tilde, not a hyphen. Google states this plainly: the symbol should be ~ and not -, because a hyphen can be overly restrictive and cause delivery problems for legitimate mail. A hard fail is a goal to arrive at once DMARC reports are clean, not a setting to open with.

A domain gets one SPF record, not several. RFC 7208 treats more than one record beginning v=spf1 as a permanent error, so a second record added by a shop plugin or an old host silently takes the whole domain down to a PermError. Merge the mechanisms into a single record instead. Google publishes combined values for the usual pairings, for example a domain running both Workspace and Microsoft 365:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

To authorise a server by address rather than by include, add ip4: or ip6: just before ~all. Keep an eye on the budget while you do it: Google's guidance is that the record should not carry more than ten references to other domains or servers, which is the ten DNS lookups RFC 7208 allows in section 4.6.4. Four vendors with their own includes is usually enough to break it. We wrote the way out of that in the SPF too many DNS lookups guide.

One more thing people miss: if you send from subdomains, each subdomain needs its own SPF record. Subdomains do not inherit it.

DKIM: generate the key in the Admin console, then turn signing on

DKIM is the signature that survives a forward, and it is the record Google Workspace actually generates for you. Two things about the timing. First, after you turn on Gmail for the domain the key is not available immediately: Google says to wait 24 to 72 hours, and trying earlier produces a DKIM record not created error. Second, generating the key and publishing it is not the same as switching it on, and the last step is the one that gets forgotten.

In the Admin console, open Apps, then Google Workspace, then Gmail, then Authenticate email. You need the Gmail Settings administrator privilege to see it. Select the domain and click Generate New Record. Choose the 2048-bit key if your DNS provider supports it, since the longer key is the stronger one, and leave the prefix at its default value of google. Google recommends keeping that default and changing it only when the domain already has a DKIM key on that prefix.

Click Generate, then copy the record name and value and publish them at your DNS host as a TXT record:

Type: TXT
Host: google._domainkey
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqh... (the long value from the Admin console)

Then go back to Authenticate email, select the domain again, and turn on DKIM. Until you do, the record sits in DNS and nothing is signed.

If the 2048-bit value will not save, the cause is almost always the 255-character limit on a single TXT string. Some DNS hosts split the value for you and some do not. Ask the host whether longer TXT records are supported, and if they are not, Google's documented fallback is a 1024-bit key. That still clears the Gmail sender guidelines, which ask for keys of at least 1024 bits and recommend 2048.

DMARC: start at p=none with a report address

There is nothing to click in the Admin console for DMARC. It is one more TXT record, published on the _dmarc host. Before you add it, let SPF and DKIM authenticate real mail for at least 48 hours, which is Google's own prerequisite. A DMARC record on top of a DKIM key that is not signing yet produces a week of alarming reports about your own mail.

Type: TXT
Host: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com

The rua tag is optional in the spec and Google recommends always including it, which we agree with: without it you get a policy and no evidence. Each address needs the mailto: prefix, and if the report mailbox is on a different domain than the record, that other domain has to publish a DNS record authorising the reports. Point it at a mailbox you will actually read, or at a parser.

If you are still in the middle of turning DKIM on, Google recommends a record with pct=0 while you review the daily reports.

The sp tag sets a separate policy for subdomains. Leave it out and subdomains inherit the parent policy, which is what you want in most small deployments.

The three records, in the order we publish them

This is the sequence we work through on a client domain, and the check that has to pass before the next record goes in.

Step	Record	Value or action	Check before moving on
1	TXT on `@`	`v=spf1 include:_spf.google.com ~all`	Exactly one record starting `v=spf1`, ten references or fewer
2	Admin console	Authenticate email, Generate New Record, 2048-bit, prefix `google`	The record appears in the Admin console (24 to 72 hours after Gmail is on)
3	TXT on `google._domainkey`	The value copied from the Admin console	The full value saved, not truncated at 255 characters
4	Admin console	Turn on DKIM for the domain	A test message to a Gmail address shows `dkim=pass`
5	TXT on `_dmarc`	`v=DMARC1; p=none; rua=mailto:dmarc@example.com`	48 hours of SPF and DKIM passing first, then reports arriving

The senders that break it a month later

Three records pass on day one and then an invoicing tool, a CRM, a shop or a newsletter platform starts sending as your domain and DMARC starts failing for that stream alone. It is worth understanding the rule rather than the record.

DMARC passes when a message passes SPF or DKIM and the domain that passed lines up with the domain in the From header. Google puts it as alignment: DMARC passes or fails based on how closely the From header matches the sending domain identified by SPF or DKIM. A vendor sending with its own envelope domain can pass SPF on its own name and still fail DMARC for yours.

So the preference, every time, is a DKIM signature on your domain from each vendor, published on its own selector. That costs no SPF lookups and it survives forwarding. Piling vendor includes into SPF is how domains reach the ten-lookup wall. Where the mail is genuinely leaving Google, SMTP relay and send mail as are the two Workspace routes worth knowing, and they authenticate differently.

Verify in the headers, not in a checker

A DNS checker tells you the record exists. It cannot tell you what Gmail did with a real message. Send one to an address you control and read the result.

In Gmail on the desktop, next to Reply click More, then Show original. The Authentication-Results header carries the verdicts, and a passing signature reads as dkim=pass. Faster still, Google documents the inbox signal: a message that passed shows Mailed by and Signed by lines in the sender details, and a question mark next to the sender name means it did not authenticate.

Two details from Google worth knowing before you debug a header for an hour. Gmail checks only the first five DKIM signatures listed in that header, so a long chain of forwarders and relays can push yours out of view. And on a forwarded message that passes SPF or DKIM but whose ARC chain shows it failed earlier, Gmail treats the message as unauthenticated, which is why forwarding breaks SPF in ways DNS cannot fix.

If a DKIM signature is in the header and still failing, the usual causes are a short list, and the DKIM fail guide for Google Workspace walks them in order.

Then the ramp, and the thresholds you are being measured against

A record at p=none protects nobody. It buys you a week of evidence. Google's recommended rollout is one week at none for all mail while you read the daily reports, which is usually long enough for every mail stream to show up at least once. Then quarantine for a small share using pct: Google's example is that a small organisation might start at 10% and a large one at 1%. Raise it over time toward 100%. Reject is optional, and Google is clear about what it means, that failing messages are rejected by receiving servers and never delivered.

Meanwhile, the Gmail sender guidelines set the floor for every domain on the internet: SPF or DKIM on all mail, valid forward and reverse DNS, and spam rates kept under 0.3%. Cross roughly 5,000 messages in 24 hours to personal Gmail accounts and you are a bulk sender, which requires SPF, DKIM and a published DMARC record, where a policy of none is accepted. The enforcement ladder is laid out in our p=none to p=reject rollout.

How Guanacos Tech helps

We set this up as a scoped piece of work for small and mid-sized teams in North America and Latin America: read what is in DNS today, publish the three records in the order above, confirm each one on a real message rather than in a checker, inventory the third-party senders nobody wrote down, then watch the DMARC reports with you through the ramp. How we work fits on one page. If you would rather have it verified than researched, that is what Google Workspace consultants are for, and half an hour with your DNS panel open is enough to say which of the three records is missing and what the ramp should look like for your mail.

SPF, DKIM and DMARC for Google Workspace: the exact records, in order