The Workspace Email Authentication Master Checklist

Email authentication is a mandatory technical foundation for Google Workspace domains. If your DNS records lack SPF, DKIM, or DMARC—or if they are configured with syntax errors—major inbox providers like Google, Yahoo, and Microsoft will reject your messages or route them straight to the spam folder. This checklist gives Google Workspace administrators a complete, step-by-step framework to configure, align, and verify all essential authentication protocols across direct users and third-party sending services.

Google Workspace Authentication Summary

A production-ready Google Workspace domain requires three core DNS records: an SPF TXT record pointing to _spf.google.com, a 2048-bit DKIM TXT record generated in the Google Admin Console, and a DMARC TXT record with at least p=none for monitoring. All third-party sending services must be integrated into these records to prevent delivery failures.

Core Email Authentication Architecture

Modern mail delivery relies on three interconnected standards. These work together to verify that your domain identity matches the server actually transmitting the message:

Sender Header (RFC 5322 From: user@example.com)
                          │
       ┌──────────────────┴──────────────────┐
       ▼                                     ▼
SPF Check (RFC 5321 Mail From)     DKIM Check (Cryptographic)
Validates Sending Server IP        Validates Cryptographic Signature
       │                                     │
       └──────────────────┬──────────────────┘
                          │
                          ▼
                    DMARC Policy
       Requires: (SPF Pass AND SPF Alignment)
                 OR (DKIM Pass AND DKIM Alignment)
                          │
          ┌───────────────┴───────────────┐
          ▼                               ▼
       Aligned                         Failed
Delivery Approved             Policy Action (None/Quarantine/Reject)

Use the following checklist to audit your domain’s authentication framework from start to finish.

Phase 1: Sender Policy Framework (SPF)

SPF authorizes specific mail servers to send email on behalf of your domain name.

Checklist Items:

• [ ] Ensure exactly one SPF record exists. Multiple TXT records starting with v=spf1 violate RFC 7208 and cause an immediate PermError. If you have more than one, merge them by following Multiple SPF Records Detected (One Record Rule).
• [ ] Include Google’s mail servers. Your root domain TXT record must contain include:_spf.google.com.
• [ ] Keep DNS lookups under 10. SPF limits recursive DNS lookups (include, a, mx, redirect, exists) to 10. If third-party integrations push your record past this ceiling, resolving it requires Troubleshooting “Too many lookups” in SPF.
• [ ] Set the correct enforcement mechanism. Use a soft-fail (~all) while testing and stabilizing your infrastructure. Avoid using ?all (neutral), which provides zero security against spoofing.

Baseline Production Record:

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

If you encounter syntax mismatches or validation errors, refer to How to Fix Gmail Error 550 5.7.26: SPF Missing/Invalid.

Phase 2: DomainKeys Identified Mail (DKIM)

DKIM adds an encrypted signature to every outbound message, proving that the email was not modified while traveling between servers.

Checklist Items:

• [ ] Generate a 2048-bit key in Google Admin Console. In Apps > Google Workspace > Gmail > Authenticate email, create a new record. Use 2048-bit keys unless your DNS provider restricts TXT record length to 255 characters. Learn how in How to Generate 2048-bit DKIM Key in Admin Console.
• [ ] Publish the public key to DNS. Create a TXT record under the specified selector name (default is usually google._domainkey).
• [ ] Confirm external DNS resolution. Query the record using your terminal before enabling it: dig txt google._domainkey.example.com +short
• [ ] Start authentication in Google Admin. Click Start Authentication in the Workspace Admin Console. Confirm that the status switches to “Authenticating email.”
• [ ] Plan for zero-downtime key rotation. When updating keys every 6 to 12 months, use secondary selectors as outlined in How to Rotate DKIM Keys Without Breaking Delivery.

If tests show signature problems after setup, consult Resolving “Message not authenticated by DKIM”.

Phase 3: Domain-based Message Authentication (DMARC)

DMARC ties SPF and DKIM together. It verifies that the domain shown to users in the visible “From:” line matches the domain validated by SPF and DKIM (domain alignment). It also tells recipient servers what to do if those checks fail.

Checklist Items:

• [ ] Publish a DMARC record at _dmarc.yourdomain.com.
• [ ] Begin with a monitoring policy (p=none). Do not start with p=reject. Collect aggregate reports (RUA) for 2 to 4 weeks to identify legitimate mail sources you may have missed.
• [ ] Establish an aggregate reporting mailbox. Add a rua=mailto:dmarc-reports@example.com tag to receive daily XML delivery reports from recipient MTAs.
• [ ] Enforce strict policies gradually. Once all legitimate sending sources pass authentication with alignment, update your policy to p=quarantine, and finally p=reject. Review the policy transition rules in How to Resolve DMARC Policy Rejects: Reject vs. Quarantine.

Baseline Production Record (Monitoring Stage):

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

Phase 4: Third-Party Sending Services Alignment

Any third-party platform that sends email using your company’s domain name (such as Zendesk, Salesforce, HubSpot, or SendGrid) will fail DMARC unless aligned correctly.

Checklist Items:

• [ ] Never simply add third-party IPs to SPF. Always prioritize custom DKIM delegation via CNAME or dedicated selectors provided by the vendor.
• [ ] Configure custom return-path domains. Set up custom bounce subdomains (e.g., em.yourdomain.com or mail.yourdomain.com) so that SPF matches the visible “From:” address.
• [ ] Audit all external SaaS applications. Follow the step-by-step instructions in How to Align SPF/DKIM for Third-Party Apps.

Phase 5: Verification and Post-Flight Testing

Before concluding your deployment, verify the entire configuration across multiple external validation engines:

1. Google Admin Toolbox: Run a comprehensive diagnostic scan using How to Use Google Admin Toolbox “Check MX”. Confirm that all MX, SPF, and DKIM entries are verified with green checkmarks.
2. Raw Header Analysis: Send a test email from your Workspace account to an outside account (such as personal Gmail). View the raw message headers and confirm that the Authentication-Results line confirms:
   • spf=pass
   • dkim=pass
   • dmarc=pass