Why Google Workspace Users Need DMARC

Google Workspace (formerly G Suite) routes your business email through Google's servers under your custom domain. While Google handles delivery reliably, the platform does not automatically prevent others from spoofing your domain — sending email that appears to come from anyone@yourdomain.com without your authorization.

DMARC closes this gap. It builds on SPF and DKIM to give receiving mail servers a clear policy: if email claiming to come from your domain does not pass authentication checks, treat it as suspicious and quarantine or reject it. Without DMARC, phishing attacks impersonating your brand can reach your customers, partners, or employees with no technical barrier stopping them.

The urgency has increased following Google's own sender requirements. Google now mandates that senders sending 5,000 or more messages per day to Gmail accounts must have a valid DMARC record in place. Organizations that do not comply risk their email being rejected or marked as spam by Gmail — which, with over 1.8 billion active users, represents a significant deliverability risk for any business.

There is also a compelling upside beyond protection. BIMI — the standard that displays your brand logo next to your emails in Gmail inboxes — requires a DMARC policy of p=quarantine or p=reject. Getting DMARC right is not just a security measure; it is the prerequisite for one of the most visible email branding wins available today.

Key point: Even if you send fewer than 5,000 emails per day, DMARC protects your domain from being used in phishing attacks against your customers. The configuration steps are the same regardless of sending volume.

Step 1: Verify Your SPF Record for Google Workspace

SPF (Sender Policy Framework) specifies which mail servers are authorized to send email on behalf of your domain. For Google Workspace, the correct SPF record is:

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

This single include mechanism covers all of Google's outgoing mail server IP ranges. The ~all qualifier is a soft fail — messages from unauthorized sources are marked as suspicious rather than outright rejected. Many organizations start with ~all and later tighten to -all (hard fail) once they are confident all legitimate sources are covered.

Combining Google Workspace with other sending services

If your domain also sends through other services — a marketing platform, a transactional email provider, or a helpdesk tool — those services need to be included in the same SPF record. For example, if you use Google Workspace and also send through SendGrid:

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

Remember: each include: counts toward the 10 DNS lookup limit. Keep your SPF record lean, and never publish more than one SPF TXT record for the same domain name — duplicate records cause immediate SPF failures.

After publishing or updating your SPF record, use the free SPF Checker to confirm the record resolves correctly and covers all the IP ranges Google uses for outbound mail.

Step 2: Turn On DKIM in Google Workspace Admin

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing message. The signature is generated using a private key held by Google's servers, and verified by receiving servers using a corresponding public key you publish in your DNS. This proves the message was sent by an authorized source and has not been tampered with in transit.

Google Workspace does not enable DKIM signing for custom domains automatically. You need to generate the key and enable signing from the Admin Console.

How to enable DKIM in Google Workspace

  1. Sign in to the Google Admin Console at admin.google.com.
  2. Navigate to Apps → Google Workspace → Gmail → Authenticate email.
  3. Select the domain you want to configure DKIM for (if you have multiple domains, repeat these steps for each).
  4. Click Generate new record. Google will create a 2048-bit RSA key pair and display the DNS TXT record you need to publish.
  5. The DNS record will look like this: 
    google._domainkey.yourdomain.com  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
    The host name is google._domainkey (or the full name google._domainkey.yourdomain.com depending on your DNS provider).
  6. Copy the TXT record value from the Admin Console and publish it in your DNS provider.
  7. Wait for DNS propagation — this can take up to 48 hours, though most DNS providers propagate within an hour or two.
  8. Return to Apps → Google Workspace → Gmail → Authenticate email and click Start authentication to activate DKIM signing.
Do not activate before DNS propagates: If you click Start authentication before the DNS record has propagated, Google's verification will fail. Wait until the record is visible in a DNS lookup tool before activating.

Once DKIM is active, use the DKIM Checker to verify that the google._domainkey selector resolves correctly and returns a valid public key for your domain.

Step 3: Create and Publish Your DMARC Record

With SPF and DKIM configured, you are ready to add the DMARC layer. DMARC is a DNS TXT record that defines the policy for handling authentication failures and specifies where to send aggregate reports about your domain's email traffic.

Start with a monitoring-only policy. This generates reports without affecting mail delivery, giving you time to identify all your legitimate sending sources before you enforce any restrictions:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Publish this as a TXT record in your DNS with the following settings:

  • Name / Host: _dmarc (some DNS providers require the full name: _dmarc.yourdomain.com)
  • Type: TXT
  • Value: the DMARC record string above
  • TTL: 3600 (1 hour) is a common starting value

The rua tag is where aggregate reports will be sent. Replace dmarc@yourdomain.com with the address where you want to receive these reports — ideally an inbox connected to a DMARC reporting tool that can parse the XML automatically.

Use the free DMARC Generator to build your record with the correct syntax. Once published, verify it resolves correctly using the DMARC Checker.

Step 4: Read Your DMARC Aggregate Reports

Once your DMARC record is live with a rua address, receiving mail servers will begin sending aggregate reports to that address. Google itself sends DMARC reports for mail received at Gmail, typically within 24 hours. These reports are the foundation of a safe path to enforcement.

What aggregate reports contain

Each aggregate report is an XML file that covers a 24-hour period. For every IP address that sent email claiming to be from your domain, the report shows:

  • The source IP address and a reverse DNS lookup
  • The number of messages sent from that source
  • Whether SPF passed or failed, and which domain was evaluated
  • Whether DKIM passed or failed, and which selector was used
  • The overall DMARC disposition applied (none, quarantine, or reject)

Common sources in Google Workspace reports

When you start receiving DMARC reports for a Google Workspace domain, you will typically see traffic from:

  • Google's own mail servers — these should pass SPF and DKIM once both are configured correctly.
  • Third-party marketing platforms — tools like Mailchimp, HubSpot, Klaviyo, or ActiveCampaign that send email using your domain name. Each needs its own SPF include and ideally its own DKIM key.
  • Forwarding services — email forwarded through third-party services often breaks SPF alignment (because the forwarding server's IP is not in your SPF record) and may break DKIM if the message is modified.
  • Transactional email providers — services like SendGrid, Postmark, or Amazon SES used for automated notifications or receipts.

The goal of the monitoring phase is to account for every source you see in reports. Any legitimate source that is failing authentication needs to be fixed before you move to enforcement.

Turn XML reports into clear dashboards

DMARC aggregate reports arrive as compressed XML files attached to emails — not designed for human reading. DMARCFlow automatically collects, parses, and visualizes every report so you can see at a glance which sources are passing or failing, track trends over time, and identify exactly what needs to be fixed before you enforce.

Start parsing your DMARC reports free

No credit card required. Full reporting dashboard from day one.

Step 5: Reach Enforcement — and Unlock BIMI

The monitoring phase is not the destination — it is the preparation for enforcement. Once your DMARC reports consistently show that all legitimate sending sources are passing authentication, you are ready to move your policy to p=quarantine and eventually p=reject.

Moving from p=none to p=quarantine

Update your DMARC record to:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com

With p=quarantine, messages that fail DMARC are delivered to the spam or junk folder rather than the inbox. This is a meaningful protection step — spoofed emails can no longer reach your recipients' primary inbox. At the same time, it gives you a safety net: if a legitimate sender was missed during monitoring, their mail is filtered rather than rejected outright.

Spend several weeks at p=quarantine while continuing to monitor reports. Look for any legitimate sources that start appearing as failures — this is your opportunity to fix them before moving to full rejection.

Moving from p=quarantine to p=reject

Once reports show a stable, high pass rate and you have confirmed all legitimate sending sources are authenticated:

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com

With p=reject, mail that fails DMARC is rejected by the receiving server before delivery. This is the strongest protection available — spoofed messages claiming to come from your domain simply never arrive at their intended targets.

BIMI unlocked: Once you reach p=quarantine or p=reject, your domain qualifies for BIMI. BIMI displays your brand logo next to your emails in Gmail, Yahoo Mail, and Apple Mail inboxes. Use the BIMI Checker to verify your setup once you are ready to configure it.

Using pct to ramp up gradually

If you want to move cautiously, use the pct tag to apply your policy to a percentage of failing messages. For example, to apply quarantine to 20% of failing messages initially:

v=DMARC1; p=quarantine; pct=20; rua=mailto:dmarc@yourdomain.com

Increase the percentage incrementally over several weeks while watching your reports for unexpected failures. This staged approach is especially useful for organizations with complex sending environments.

Watch for forwarded mail at p=reject: Automatic email forwarding is the most common source of unexpected DMARC failures at enforcement. When a message is forwarded, the original sender's SPF record typically does not cover the forwarding server's IP. If you have users who forward mail to personal accounts, investigate this before moving to p=reject.

Google Workspace DMARC Checklist

Use this checklist to confirm each step of your Google Workspace DMARC setup is complete:

  1. SPF record published — contains include:_spf.google.com with no duplicate TXT records on the same domain name
  2. Additional senders included in SPF — all marketing platforms, transactional services, and other sending tools have their SPF mechanisms added
  3. SPF verified — confirmed passing via the SPF Checker
  4. DKIM key generated in Google Admin Console — 2048-bit key created under Apps → Google Workspace → Gmail → Authenticate email
  5. DKIM DNS record published — TXT record at google._domainkey.yourdomain.com live in DNS
  6. DKIM signing activated — Start authentication clicked in Admin Console after DNS propagation
  7. DKIM verified — confirmed via the DKIM Checker
  8. DMARC record published — TXT record at _dmarc.yourdomain.com with p=none and a valid rua address
  9. DMARC verified — confirmed via the DMARC Checker
  10. Aggregate reports flowing — reports arriving at your designated address or DMARC dashboard
  11. All sending sources identified and authenticated — no legitimate sources appearing as DMARC failures
  12. Policy moved to enforcement — p=quarantine or p=reject once reports confirm clean pass rates

Google Workspace makes it straightforward to enable SPF and DKIM — the main effort is in the DMARC monitoring phase, where you identify and fix every sending source before moving to enforcement. Take your time with that phase, use the aggregate reports as your guide, and you will reach a fully enforced DMARC posture that protects your domain, meets Google's sender requirements, and qualifies your brand for BIMI logo display in Gmail.