Until you generate a key in the Admin console and click Start authentication, no DKIM signature carries your own domain, so DMARC has nothing on the DKIM side to align with and has to pass on SPF alone, which breaks on the first forward. This guide covers that and the rest of what goes wrong on Workspace: the single SPF record and the ten-lookup ceiling that a second one blows past, what Gmail expects once it counts you as a bulk sender, the sending limits of a mailbox that was never a sending platform, when smtp.gmail.com is the wrong host and the SMTP relay is the right one, and how to confirm the result on a real send to an Unspam seed address. The one thing that tells you whether you are finished is the d= value in the DKIM-Signature header of one of your own messages.
Google Workspace does not generate a DKIM key for your domain in the general case, and Google documents only two exceptions: if your domain provider is Squarespace the key is created and added to your DNS records automatically, and you might not need to set up DKIM if your domain already has it by default or you bought the domain from a Google partner when you signed up.
For a domain that sends only through Workspace, Google publishes exactly one value: v=spf1 include:_spf.google.com ~all, as a TXT record on the root domain with the host field set to @. Two things wreck it. A second SPF record on the same name is a permanent error and neither record is used, which is what happens the third time a new tool tells you to add this TXT record. And Google documents a ceiling of ten include: tags, which a help desk, an invoicing app and a marketing platform reach faster than anyone expects.
Gmail's sender guidelines treat you as a bulk sender once you send more than 5,000 messages a day to personal Gmail accounts, counted per primary domain. Google's own example is 2,500 from solarmora.com plus 2,500 from promotions.solarmora.com, which together cross the line. Bulk senders must publish DMARC, though the policy may be p=none, and the From domain must align with either the SPF domain or the DKIM domain. Google also states that bulk sender status has no expiry date, and mail that fails the requirements is spam foldered or rejected with a 5.7.26 error.
Trial accounts are held to 500 messages and 500 unique external recipients per day. A paid account rises to 2,000 messages a day, but it also caps at 3,000 external recipients and 2,000 unique external recipients, and messages sent over SMTP, POP or IMAP take at most 100 recipients each. The counters run on a rolling 24-hour window rather than the calendar day, so nothing resets at midnight and a send that started fine gets cut off halfway through.
smtp.gmail.com is authenticated with one account's own address plus an app password and Google caps it at 2,000 messages per day, so it is a mailbox route rather than an application route.
DKIM signs a hash of the body, so any modification after signing invalidates it and the receiver logs body hash did not verify in the Authentication-Results header. Google's DKIM troubleshooting page names outbound gateways as the usual cause, specifically ones that append a footer to every outgoing message, and tells you to make sure the gateway does not modify outgoing messages. The same page notes that Gmail evaluates only the first five DKIM signatures on a message, so a valid signature sitting sixth in the stack is never checked.
Google does not write DNS records for you. Every record below lives at your domain host, and the Admin console only generates the values and then checks them. SPF and DKIM come first, and Google asks you to wait 48 hours after those before adding DMARC. All the DKIM work happens under Apps > Google Workspace > Gmail > Authenticate email, and you must be signed in as a super administrator.
| record | default | the problem | the fix |
|---|---|---|---|
| SPF | Nothing is published unless you published it. Adding Google's MX records does not add SPF. | With no record there is no SPF pass to align with. With two records on the same name, neither is used. Past ten include: tags, the record stops evaluating and every sender fails at once. | Publish one TXT record on the root domain, host field @, value v=spf1 include:_spf.google.com ~all. Merge every other sender into that same record rather than adding a second one. Google recommends ~all over -all, and notes that SPF changes can take up to 48 hours to take effect. |
| DKIM | Off for most domains. Google notes two exceptions: a Squarespace-hosted domain gets the key created and added automatically, and a domain that already has DKIM by default or was bought from a Google partner at signup may not need setup at all. Everywhere else, after you turn on Gmail you must wait 24 to 72 hours before the Admin console will generate a key, and until you finish, the Authenticate email page reads You must update the DNS records for this domain. | Without your own key there is no signature carrying your domain, so DMARC has to pass on SPF alone. That lasts until the first forward or mailing list, which breaks SPF and takes the DMARC result with it. | Under Apps > Google Workspace > Gmail > Authenticate email, select the domain, keep the default prefix selector google, choose the 2048 bit key length if your DNS host supports it, publish the TXT record at google._domainkey, then return and click Start authentication. The status changes to Authenticating email with DKIM once Google verifies it. |
| DMARC | Not published, and Google never publishes it for you. | Gmail requires a DMARC record from bulk senders, and Google tells you to allow 48 hours after setting up SPF or DKIM before adding one, so you are not enforcing a policy against authentication that has not propagated yet. | Publish a TXT record at _dmarc.yourdomain.com, starting at v=DMARC1; p=none with an rua address, read the aggregate reports, then tighten to p=quarantine and p=reject. Point rua at a dedicated group or mailbox: Google warns that large organizations can receive hundreds or thousands of reports a day. |
| Additional domains | The Authenticate email page has a Selected domain menu listing the domains on your account, and each one starts with no key of its own. | Teams generate a key for the primary domain, then send from a second domain that has none, and every message from it fails DKIM alignment while the primary domain looks perfect. | Google's instruction is explicit: if you are setting up DKIM for more than one domain, complete the steps for each domain, and get a unique DKIM key from the Admin console for each one. Publish google._domainkey under every domain you send from, not just the primary. |
Once you have updated these records, confirm they pass with Unspam's free SPF checker, DKIM checker, and DMARC checker.
Unspam does not connect to Google Workspace. It has no Gmail API integration, no admin access, and it never signs in to your account. You get a seed address, you send it a real message the same way your recipients get one, and Unspam reads what arrived. If you want the test to repeat on a schedule, you can supply SMTP credentials for automated inbox placement tests, and that is the only credential Unspam ever holds.
Start a spam test or an inbox placement test in Unspam and copy the address it generates. Placement tests deliver to seed mailboxes at Gmail, Outlook, Yahoo and five other providers and report where each copy landed. An inbox placement test also issues a Test ID. Paste it into the subject line or the body before you send, or the message reaches the seed mailboxes and is never matched to your test.
If the mail in question is a person composing in Gmail, send it as that user, not from your super administrator account, which usually has different signatures, groups and history. If it is an application, trigger the application so the message leaves over the host it uses in production, smtp.gmail.com or smtp-relay.gmail.com. The route changes the result: the relay lets an app send as any address in your organization, while smtp.gmail.com forces the From to the authenticated account.
In the Unspam report, check the SPF, DKIM and DMARC results. The signing domain is the tell. If d= is a subdomain of gappssmtp.com rather than your own domain, you never finished the Admin console steps, and DMARC is resting on SPF alone if it passes at all. The same report scores the content, links and headers, so you can see whether authentication is the whole story or only the first part of it.
A spam score tells you how one filter grades the message. An inbox placement test tells you where the copies actually landed across the seed providers, which is the question you were asking. The split is rarely uniform: a domain Gmail has trusted for years can still be filtered somewhere else, and that pattern points at reputation and content rather than at your DNS.
DNS is the slow part here. Google says SPF changes can take up to 48 hours, and that the Admin console may keep showing the DNS warning for up to 48 hours after you added the DKIM record correctly. Verify the published values with the Google Admin Toolbox Dig and Check MX tools rather than trusting the banner, then send again to a fresh seed address. If your volume is high enough, add the domain to Postmaster Tools and watch the spam rate: Gmail asks you to keep it below 0.10% and to avoid ever reaching 0.30%.
The same test renders your campaign in 50+ real email clients, Gmail, Outlook, Apple Mail, iPhone, and Android among them, each in light and dark mode, via email client previews, so you confirm placement and rendering in one pass.
Google's own documentation says the Authenticate email page can keep telling you to update your DNS records for up to 48 hours after you added the correct TXT record, and separately warns you not to click Start authentication before the record is actually published. Treat the banner as decoration, not as a diagnostic. Confirm the live value with the Admin Toolbox Dig tool and read a real message's Authentication-Results header for DKIM=pass.
DNS caps a single character string at 255 characters and a 2048 bit key is longer than that. Google's fix is to split the key characters into multiple text strings, each in its own quotes, inside the one record. Some DNS panels do this for you, some reject the input, and some accept it and store a truncated value, which is the worst outcome because the record looks published and never verifies. If your host genuinely cannot store it, Google offers the 1024 bit option for exactly this case.
Google documents that if the sender is not in one of your domains, the relay changes the envelope sender from user@domain_you_don't_own to postmaster@your_domain. Bounces then come back to your postmaster address and the Return-Path stops matching the From. Google also marks the Any addresses option as not recommended, because it makes you more vulnerable to abuse, either by malicious software on your users' devices or by incorrect SMTP settings.
Google states plainly that the Email sender guidelines do not apply to messages sent to Google Workspace accounts. Mail you send to a colleague on your own domain, or to another business running Workspace, is not graded the way mail to a personal Gmail account is. If your only test is your own inbox, you are testing the one path that was never going to fail. Send to seed mailboxes at real consumer providers instead.
The deliverability problems Google Workspace senders hit most often, each with the fix that resolves it.
Two different things produce this. Google's documentation says the message can persist for up to 48 hours after a correct record is added, so the console is often simply stale. The other cause is skipping the last click: generating the key and publishing the TXT record does nothing on its own, and the status only changes to Authenticating email with DKIM after you return to Authenticate email, click Start authentication, and Google verifies the record.
The fix Check the published record directly with the Google Admin Toolbox Dig tool at google._domainkey.yourdomain.com instead of trusting the console. Then send a message to an outside address and read the Authentication-Results header: DKIM=pass with d= set to your own domain means the job is done whatever the banner says. If the record is correct and Start authentication has been clicked, wait out the 48 hours.
A 2048 bit public key is longer than the 255 character maximum for a single DNS character string, so the key has to be stored as several quoted strings inside one TXT record. Some control panels split it for you, some refuse the input outright, and some accept it and silently truncate, which is the worst case: the record exists, looks right in the panel, and never validates.
The fix Split the key into multiple text strings yourself, each wrapped in its own quotes within the same TXT record, which is exactly what Google's DKIM troubleshooting page instructs. Then verify with Dig that what comes back matches the Admin console value character for character. If your provider truly cannot store it, regenerate the key at 1024 bits, which Google offers for hosts that do not support 2048 bit keys.
The app is authenticating to smtp.gmail.com with one user's address and an app password. Google documents that on this path the From address must match the authenticated account, so any other From is replaced. The mail is authenticated and delivered, it just is not from the address customers expect, and replies land in the wrong mailbox.
The fix Move the app to the SMTP relay. In the Admin console go to Apps > Google Workspace > Gmail > Routing, configure the SMTP relay service, and set Allowed senders to Only addresses in my domains so the app can send as billing@. Point the app at smtp-relay.gmail.com on port 587 with TLS, and authenticate with Require SMTP Authentication or the Only accept mail from the specified IP addresses option. Note that Google's two pages state the relay ceiling differently, one as 10,000 messages per user in a 24 hour period and the other as 10,000 recipients per user per day, so size your batches against the lower reading.
The cap that stopped you was probably not the message count. A paid Workspace account gets 2,000 messages a day, but only 3,000 external recipients and 2,000 unique external recipients, and messages sent through SMTP, POP or IMAP are limited to 100 recipients each. A 600 message run that includes distribution lists blows through the recipient counters long before the message counter. Limits run over a rolling 24 hour period, not a calendar day, so nothing resets at midnight.
The fix Count recipients, not sends, and check which counter you hit before changing anything. If the volume is real and recurring, move it off the mailbox: the SMTP relay allows 10,000 messages per user in 24 hours, and genuine marketing belongs on a platform built for it. On a trial, expect 500 messages and 500 unique recipients a day until the domain has paid $100 USD or the equivalent, and note that Google says the increase can take up to 75 days after that threshold to apply.
The Workspace key only signs mail that leaves Google's servers. A newsletter sent from a marketing platform never touches that key, so it needs its own DKIM record published for your domain on the selector that platform gives you. Google's DMARC troubleshooting page sends you to the third party's documentation for precisely this case. The same applies to help desks, e-commerce receipts, CRM notifications and anything else sending as your domain.
The fix Inventory every system that sends as your domain, then authenticate each one: publish the platform's DKIM record on its own selector, and fold its SPF mechanism into your single SPF record. Use the DMARC aggregate reports at your rua address to find the senders you forgot, since that is what those reports are for. Then send a test message through each source to a seed address so you can read the d= domain per system instead of guessing.
Because DMARC checks the signing domain, not the signature. Outbound Workspace mail is signed on a Google infrastructure domain, a subdomain of gappssmtp.com, and that d= value can never match your From domain. Gmail's sender guidelines require the domain in the From header to align with either the SPF domain or the DKIM domain. Generating your own key under Apps > Google Workspace > Gmail > Authenticate email is what makes the DKIM half of that alignment possible.
If Workspace is your only sender, one TXT record on the root domain, host field @, value v=spf1 include:_spf.google.com ~all. If you also send through a marketing platform, a help desk or a billing system, add their mechanisms into that same record. Never publish a second SPF record on the same name, and keep an eye on Google's documented limit of ten include: tags.
Google recommends ~all, and describes it as telling receiving servers to mark messages as spam if they come from servers that are not listed in the record. -all asks receivers to reject outright, which is only safe once you are certain every legitimate sender is in the record. Since SPF is only one of the two ways to satisfy DMARC, the stricter qualifier buys less than people assume and costs more the day someone adds a new tool.
One, checked in August 2026. The record used to chain into _netblocks, _netblocks2 and _netblocks3, and a lot of advice still assumes it does. Today _spf.google.com answers with a single record of ip4 and ip6 ranges and no nested includes, so it spends one of your ten. Verify it yourself before you flatten anything on the strength of an old blog post, because it is Google's record and Google can change it.
Only once you pass 5,000 messages a day to personal Gmail accounts, counted across your primary domain and its subdomains together rather than per subdomain. The 2,000 message per user daily cap makes that hard from one mailbox and easy across a team or a relay. Google says the status has no expiry date, so it stays once you cross it. The requirements do not apply to messages sent to Google Workspace accounts.
No. Unspam has no Gmail API integration and never signs in to your account or your Admin console. There are two touch points: a seed address you send a real message to, and, for tests that run on a schedule, SMTP credentials you supply for automated inbox placement tests. Everything in the report is read from the message that arrived. The free tier covers 10 spam tests and 3 inbox placement tests a month with no card; paid plans start at $9 per month with a 14-day refund.
Google Workspace platform details were verified against publicly available documentation in August 2026 and may have changed since. Google Workspace is a trademark of its respective owner. Unspam is not affiliated with or endorsed by Google Workspace.
