Enter the domain your Workspace inboxes actually send from. We pull its live SPF record, read it the way a receiving server does, and check the one line that matters most: the Google include.
Loading tool…
Lower stack cost. Back in the inbox. Built to send at any scale.
We rebuild it properly: secondary domains, inboxes, SPF, DKIM and DMARC set to enforcement, warmup and safe sending limits, blacklist monitoring on top. Send-ready in about 17 days. No campaigns, no copy, no lead lists. Infrastructure only.
Almost a decade building cold outreach infrastructure, including his own sending and verification stack built from scratch. 20+ B2B clients at companies worth $10M and above, all in tier one countries.
Free · Written plan + fixed price · No sales call required
The SPF Checker for Google Workspace pulls the live SPF record for a domain and reads it with Google Workspace in mind. A healthy Workspace sending domain publishes exactly one SPF record, and that record includes include:_spf.google.com, which authorizes Google servers to send for the domain. This checker shows the record exactly as published, confirms whether the Google include is there, and flags the mistakes that quietly break sending.
One single record that includes include:_spf.google.com. If other tools send for the same domain, their includes go into the same record. A common shape is v=spf1 include:_spf.google.com ~all, with any extra senders added before the ending mechanism.
No. Google supplies the include value, but the record is published in your own DNS. Nothing is authorized until the TXT record exists at the root of the sending domain.
SPF is one of three checks. DKIM has to be turned on in the Google Admin console with its key published, and DMARC has to exist at the _dmarc name. The SPF Checker on this site reads any record in a general way, while this page reads it for Workspace specifically.
No. A domain may only carry one SPF record. Receivers that find two treat the domain as having no valid SPF at all. Merge the sender into the existing record instead.
The final mechanism tells receivers how strict to be about
No. A domain can carry only one SPF record. Two records cause a permanent error and every SPF check fails. Merge all the includes into one line and publish that single record.
The check returns a permanent error and SPF fails outright. Cut the count by removing dead includes for tools you no longer use. Flatten a nested include only where it is safe and recheck the count after each change.
Usually minutes to a few hours. The delay depends on the TTL of the old record and on resolver caches. Check with a lookup tool instead of resending test emails.
Yes. Every sending subdomain needs its own SPF record. Subdomains do not inherit the root domain record, so a subdomain with no record has no SPF at all.
DMARC needs alignment, not just a pass. The domain that SPF checks must match the visible From domain. If they differ, DMARC fails even when SPF passes on its own.
The tilde in ~all means softfail. The dash in -all means hard fail. Start with softfail while you test, then move to hard fail once every real sender is included.
Only if that server actually sends mail as your domain. Contact form notifications are a common example. If the host never sends as your domain, leave it out, because it just adds lookups.
It covers what is broken, what we would build, the timeline, and one fixed price. Want it walked through instead? Book a 15 minute plan walkthrough.
Or just reply to the plan email. Either works.
