A new domain can receive and send email before every authentication check is in place. This plain-language guide follows one small Google Workspace setup: prove domain ownership, route mail, authenticate outgoing messages and test delivery. The records below are examples; use the exact values shown in your own Google Admin account.
Domain verification proves control to Google; it is separate from mail routing. Passing these checks helps authenticate a message but does not guarantee inbox placement.
What happened in this setup
I had a new business domain and a Google Workspace mailbox. I added Google's domain verification record and the mail-routing record, then enabled DKIM and added the generated public key to DNS. The first message reached the Workspace inbox, but a test to a personal Gmail inbox went to Spam.
The message details showed SPF and DKIM passing while DMARC failed. After I corrected the DMARC DNS record, a later test showed all three checks passing. That message still went to Spam at first; subsequent tests worked. I cannot say the DMARC change alone fixed delivery. Gmail says authentication helps protect against spoofing and makes messages less likely to be rejected or marked as spam, but authentication alone does not guarantee inbox placement.
Understand the four DNS jobs
TXT domain verification
Google gives you a unique TXT value. Adding it to your domain's DNS shows Google that you control that domain. It does not route incoming mail or authenticate messages you send.
MX mail routing
MX records tell other mail systems where to deliver messages for your domain. Follow the current values in your Google Admin setup and your DNS provider's format. Remove old MX records only when Google's instructions for your setup say to replace them.
SPF and DKIM
SPF lists the services allowed to send mail for your domain. DKIM lets a receiving system check a cryptographic signature added to an outgoing message. If more than one service sends as your domain, account for every sender in the SPF design; publish only one SPF record for a given domain name.
DMARC
DMARC checks whether the domain visible in the message's From address aligns with a domain authenticated by SPF or DKIM. A monitoring policy can be a cautious starting point while you confirm which services send mail for you; stronger policies need evidence that legitimate senders are configured.
Add records in a safe order
- In Google Admin, add the domain and copy its unique verification TXT value.
- At the DNS provider, add that TXT record at the host name Google specifies.
- Return to Admin and verify the domain. DNS changes can take time to appear everywhere.
- Activate Gmail and follow the current Workspace MX instructions for your domain.
- Send and receive a basic test message before changing sender-authentication records.
- Generate a DKIM key in Google Admin, publish the exact TXT name and value, then start authentication in Admin.
- Publish SPF for every real sending service and add a DMARC record that matches your intended monitoring policy.
- Test again, then inspect the received message's authentication details.
DNS dashboards use different labels for record name, host, value and TTL. A provider may append the domain automatically. Check its instructions before entering a full domain name, and avoid pasting a record value into the wrong field.
Read the test message results
In Gmail, open the message details or original source and look for SPF, DKIM and DMARC results. A useful test includes a message from the new Workspace mailbox to an unrelated personal mailbox, a reply in the opposite direction and a second send after DNS has propagated.
- SPF fail: check which service actually sent the message and whether the domain's SPF record authorises it.
- DKIM fail or missing: confirm the selector name, complete TXT value and that Workspace authentication was started after publishing it.
- DMARC fail: check the From address and whether SPF or DKIM passed with a matching domain.
- All pass, but Spam: authentication is only one signal. Check the Spam folder and sender identity; do not assume a passing DNS setup guarantees inbox delivery.
A new domain may have little sending history. For this setup, I tested ordinary one-to-one messages first. Gmail also considers recipient feedback and other signals, so a clean authentication check did not immediately move every test into Inbox. If you send marketing messages, check the current sender requirements and unsubscribe rules before starting a campaign.
Keep keys and account access private
Google publishes the DKIM public key in DNS. Use the selector and key generated for your own domain; do not copy another domain's values. The service keeps the private signing key. Never share a password, recovery code, private key or cloud credential. Keep DNS changes and account recovery under the domain owner's control.
Keep a small record of the DNS provider, record purpose, date added, sender services authorised and the person responsible for renewals or later changes. This makes it easier to diagnose mail problems if you add a CRM, newsletter platform or website enquiry service later.
Sources and scope
This guide is about one new Google Workspace domain setup, not a complete email marketing deliverability programme. Google's current guidance recommends SPF, DKIM and DMARC for sending domains and explains that authentication reduces some risks without guaranteeing inbox delivery. Workspace's exact DNS values and available setup steps can change; use the instructions in your own Admin console and check the current official help pages below.
- Google Workspace: verify your domain with a TXT record
- Google Workspace: set up DKIM
- Gmail: email sender guidelines
- Gmail: check if a message is authenticated
For a website or form that sends mail through an external provider, review the provider's current sending and DNS instructions before adding it to SPF or DKIM. VikaSquare's software integration work begins with the systems, account ownership and handoffs involved; email delivery depends on the selected providers and their configuration.