How to Set Up DMARC for Google Workspace

Google Workspace is one of the most popular email platforms for businesses, and Google itself now strongly recommends that every domain using its services has a DMARC record in place. If you are using Google Workspace for your company email, this guide walks you through setting up DMARC from start to finish, including the prerequisites that need to be in place first. For a broader look at email authentication for Google Workspace organizations, see our dedicated DMARC for Google Workspace landing page.

Prerequisites: SPF and DKIM for Google Workspace

Before you create a DMARC record, your domain needs both SPF and DKIM configured and working. Google Workspace supports both, but they require separate setup steps. If you want to understand how these three protocols relate to each other, read SPF vs DKIM vs DMARC.

SPF for Google Workspace

SPF tells receiving mail servers which servers are allowed to send email on behalf of your domain. For Google Workspace, your SPF record needs to include Google's mail servers. A basic SPF record for a domain that only sends through Google Workspace looks like this:

v=spf1 include:_spf.google.com ~all

If you also send email through other services like Mailchimp, SendGrid, or HubSpot, those need to be included in your SPF record too. You can build a complete SPF record at spfcreator.com.

Check your current SPF record to make sure include:_spf.google.com is present. If you have no SPF record at all, create one before proceeding.

DKIM for Google Workspace

DKIM adds a cryptographic signature to every email your organization sends. Google Workspace supports DKIM signing, but it is not enabled by default. You need to turn it on in the Google Admin console.

To enable DKIM in Google Workspace, go to the Admin console at admin.google.com, navigate to Apps > Google Workspace > Gmail > Authenticate email, select your domain, and click Generate new record. Google will give you a TXT record to publish in your DNS. The record name is usually google._domainkey.yourcompany.com and the value is the DKIM public key.

After publishing the DNS record, go back to the Admin console and click Start authentication. Google will verify the DNS record is in place and begin signing outgoing messages. Allow up to 48 hours for DNS propagation, though it usually takes much less.

If you need to generate DKIM records for additional sending services beyond Google Workspace, you can use dkimcreator.com.

The Recommended DMARC Record for Google Workspace

For Google Workspace users setting up DMARC for the first time, we recommend starting with this record:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourcompany.com; pct=100;

This record does three things. First, it declares your DMARC policy as none, meaning no email will be blocked or quarantined while you gather data. Second, it tells receiving mail servers to send aggregate reports to your specified email address. Third, it applies to 100% of messages, so you get complete visibility.

Replace dmarc-reports@yourcompany.com with an email address you control. This can be your personal inbox, a shared team inbox, or a dedicated reporting address. If your domain handles a lot of email, a dedicated address is a good idea because the reports can pile up.

Adding Your DMARC Record to DNS

The process for adding a DMARC record to your DNS depends on where your domain's DNS is hosted. Below are instructions for the most common scenarios Google Workspace customers encounter.

If Your DNS Is Managed by Google Domains or Squarespace

Google Domains was migrated to Squarespace Domains. If your domain is there, log in to your Squarespace Domains account, go to DNS > DNS Settings, and click Add Record. Set the type to TXT, the host to _dmarc, and paste your DMARC record value. Save the record.

If Your DNS Is Managed by Cloudflare

Log in to your Cloudflare dashboard, select your domain, and go to DNS > Records. Click Add record, set the type to TXT, the name to _dmarc, and the content to your full DMARC record string. Proxy status does not apply to TXT records, so leave it as DNS only. Save the record.

If Your DNS Is Managed by GoDaddy, Namecheap, or Another Registrar

The process is similar across most registrars. Find the DNS management section for your domain, add a new TXT record with the name _dmarc (some registrars may want _dmarc.yourcompany.com), and paste the record value. Set the TTL to 1 hour or leave it at the default.

Receiving and Understanding Your Reports

Within 24 to 72 hours of publishing your DMARC record, you should start receiving aggregate reports at the email address in your rua tag. Here is what to do with them.

Expect XML attachments. Aggregate reports arrive as compressed XML files from mail providers like Google, Yahoo, Microsoft, Apple, and others. Each report covers a time period (usually 24 hours) and lists every IP address that sent email claiming to be from your domain.

Look for your known sending sources. In the reports, you should see Google's IP ranges sending email that passes both SPF and DKIM. If you use other services to send email (marketing platforms, CRM systems, transactional email tools), their IPs should also appear with passing results.

Watch for failures. Messages failing DMARC could be unauthorized senders spoofing your domain, or they could be legitimate services you forgot to add to your SPF record or configure with DKIM. Before tightening your policy, investigate every failing source. If it is a legitimate service, fix its authentication. If it is unauthorized, you can safely let your future DMARC policy block it.

Give it at least two weeks. Some sending services or forwarding scenarios only show up occasionally. Two weeks of data at p=none gives you a solid picture before you start enforcing anything.

Moving from p=none to Enforcement

Once your reports consistently show that all your legitimate Google Workspace email and other authorized services are passing DMARC, it is time to tighten your policy. Here is the recommended progression for Google Workspace users.

Phase 1: Quarantine at a low percentage. Update your DMARC record to v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourcompany.com; pct=25;. This sends 25% of failing messages to the recipient's spam folder. Monitor your reports for a week. If nothing legitimate is getting caught, bump the percentage up.

Phase 2: Quarantine at full percentage. Change pct=25 to pct=100. All failing messages now go to spam. Run this for another week or two while monitoring reports. Check with your team that no one is reporting missing emails.

Phase 3: Reject. Update the policy to p=reject; pct=100;. This is the strongest protection available. Receiving mail servers will now drop any message from your domain that fails DMARC entirely. Spoofed emails never reach the inbox, the spam folder, or anywhere else.

For Google Workspace, the path to p=reject is usually straightforward because Google handles both SPF and DKIM well. The most common complication is third-party services that send email as your domain but are not properly authenticated. Email marketing tools and CRM platforms are the usual culprits. Make sure every service that sends on your behalf has both its SPF include added and DKIM configured before you enforce.

If you want a deeper understanding of each policy level and when to use them, see our guide on DMARC policy levels.

Monitor Your New DMARC Record

You've created your DMARC record — now make sure it keeps working. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.