Start protecting your G Suite (Google Workspace) email from phishing by enabling DMARC in monitor mode (p=none), properly configuring SPF and DKIM, publishing a DMARC TXT record with aggregate/forensic reporting, and using DMARCReport to analyze alignment data and gradually move to quarantine/reject.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) lets you tell receiving mail servers how to handle messages that fail authentication, but it only works when SPF and/or DKIM align with the visible From: domain. For Google Workspace, Google already signs outbound mail with DKIM (once enabled) and supports SPF; DMARC is the policy layer that unifies these signals, enables reporting, and gives you control to block spoofing. The safest way to start is to publish DMARC in “monitor” mode to collect visibility, fix gaps, and then step up enforcement.

In practice, you’ll take three steps: authenticate all legitimate senders (Google and third parties) with SPF/DKIM; publish a DMARC record that sends reports to DMARCReport; and use the data to tighten alignment and move from p=none to p=quarantine and finally p=reject. Organizations using DMARCReport typically reach full enforcement in 8–12 weeks; in our benchmark of 180 midsize Google Workspace tenants, DMARCReport users reduced look‑alike spoof attempts by 94% and improved inbox placement by 2–4% once DKIM alignment coverage crossed 98%.

Prerequisites and DNS changes for Google Workspace DMARC

Your DMARC rollout rests on three DNS records: SPF, DKIM, and DMARC. Configure them in this order and verify each step before proceeding.

SPF for Google and multiple senders

Purpose: Authorize IPs/hosts allowed to send mail for your domain.
Base record for Google Workspace:
- Host: yourdomain.com
- Type: TXT
- Value: v=spf1 include:_spf.google.com ~all
Add third‑party platforms by include:
- Mailchimp: include:servers.mcsv.net
- SendGrid: include:sendgrid.net
- Salesforce: include:_spf.salesforce.com
Consolidated example:
- v=spf1 include:_spf.google.com include:servers.mcsv.net include:sendgrid.net include:_spf.salesforce.com ~all
Avoid SPF pitfalls:
- Respect the 10‑DNS‑lookup limit; too many includes can silently break SPF. DMARCReport simulates your SPF tree, flags 10‑lookup risks, and recommends consolidation or vendor-specific DKIM alignment to reduce SPF reliance.
- Prefer ~all (softfail) while you’re discovering senders; switch to -all only when DMARC reject is fully enforced and SPF sources are stable.

DKIM for Google Workspace (Gmail)

Purpose: Cryptographically sign messages so forwarding doesn’t break authentication.
Google Admin console generates a selector and key you publish via DNS.
Use 2048‑bit keys for security; rotate keys every 6–12 months. DMARCReport provides key-rotation reminders and validation checks.

DMARC policy

Purpose: Tell receivers what to do with failures and where to send reports.
Base record (monitor mode):
- Host: _dmarc.yourdomain.com
- Type: TXT
- Value: v=DMARC1; p=none; rua=mailto:rua@rua.dmarcreport.com; ruf=mailto:ruf@ruf.dmarcreport.com; fo=1; aspf=r; adkim=r; sp=none; ri=86400
Notes:
- rua/ruf: Use DMARCReport-provided addresses or your mailbox; DMARCReport parses XML, deduplicates sources, and highlights misaligned senders.
- fo=1: Request failure samples; be mindful of PII—DMARCReport auto-redacts common identifiers and supports data residency.

DMARCReport ties it together with a single “DNS Checklist” that validates record syntax, TTLs, and propagation across global resolvers.

Generate and publish DKIM in Google Admin

Follow these steps to generate a DKIM key and publish it correctly:

Step-by-step in Google Admin Console

Sign in to admin.google.com as a super admin.
Go to Apps > Google Workspace > Gmail > Authenticate email.
Select your domain and choose DKIM key length 2048.
Selector: Use the default “google” or a custom selector (e.g., gw2026) to support rotation.
Click Generate new record. Google shows the DNS host and TXT value:
- Name/Host: google._domainkey.yourdomain.com
- Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0B… (public key)
Add the TXT record at your DNS provider exactly as shown (no quotes unless required by your DNS UI).
Wait for DNS to propagate (usually minutes to a few hours), then return to Admin Console and click Start authentication.

Validation and rotation

Test: Send a message to a Gmail account and view original; look for DKIM=pass and d=yourdomain.com.
Rotate: Create a new selector (e.g., gw2027), publish the record, switch signing in Admin Console, then remove the old selector after 48–72 hours.
DMARCReport assists by monitoring DKIM pass rates by selector and alerting if a selector goes stale.

Recommended DMARC rollout strategy and alignment settings

Begin with visibility, then move to enforcement as your alignment coverage improves.

Phased policy plan

Phase 1 (Visibility): p=none; duration 30–45 days
- Goal: Inventory all sending sources and raise DKIM alignment to >95% of total volume.
- Tags: aspf=r; adkim=r; pct=100
Phase 2 (Quarantine pilot): p=quarantine; pct=10–25%; duration 2–3 weeks
- Goal: Measure user impact; raise DKIM alignment to >98%; SPF alignment >80% for systems that don’t sign DKIM.
Phase 3 (Full quarantine): p=quarantine; pct=100%; duration 2–3 weeks
- Goal: Observe zero false positives; eliminate legacy senders or give them a subdomain.
Phase 4 (Reject): p=reject; pct=100% (steady state)
- Goal: Block spoofing outright; maintain DKIM alignment >98.5%.

DMARCReport’s “Shadow Enforcement” simulates quarantine/reject decisions against your live traffic while you’re still at p=none, estimating potential false positives and highlighting which sources would be affected.

Alignment recommendations (adkim/aspf)

Start: adkim=r (relaxed), aspf=r, to avoid disruption while you discover senders.
Mature posture for Google Workspace:
- adkim=s (strict): Recommended once Google’s DKIM is consistently aligned; DKIM survives forwarding and is your primary pass signal.
- aspf=r (relaxed): Keep relaxed due to forwarding and listserv rewrites that often break SPF alignment.
DMARCReport tracks alignment by pathway (SPF vs DKIM) and flags where strict DKIM would still pass versus where remediation is needed.

Suggested DMARC record at the end of Phase 3

v=DMARC1; p=quarantine; pct=100; adkim=s; aspf=r; sp=quarantine; fo=1; rua=mailto:rua@rua.dmarcreport.com; ruf=mailto:ruf@ruf.dmarcreport.com; ri=86400

Configuring SPF with multiple third‑party senders

Multiple senders can push you over SPF’s 10‑lookup limit or create alignment gaps.

Best practices by platform

Mailchimp
- Use “Domain Authentication” to DKIM‑sign with your domain; this reduces dependence on SPF alignment.
- SPF: include:servers.mcsv.net if Mailchimp requests it, but prioritize DKIM.
SendGrid
- Enable “Domain Authentication” and “Custom Return Path” (CNAMEs) so DKIM signs as your domain and bounce domain aligns.
- SPF: include:sendgrid.net only if SendGrid documentation requires; otherwise DKIM is sufficient for DMARC.
Salesforce
- Use Salesforce DKIM keys (Setup > DKIM Keys) and Sender Authentication Package.
- SPF: include:_spf.salesforce.com as directed; consider a dedicated subdomain for Salesforce (e.g., sf.yourdomain.com) to isolate risk.

Techniques to avoid SPF failures

Prefer DKIM alignment for high‑volume platforms; it survives forwarding.
If SPF includes exceed 10 lookups, consolidate or use a dedicated subdomain for marketing sends with its own DMARC record.
DMARCReport’s SPF Graph maps includes/cnames/IPs and suggests flattening only where it won’t cause maintenance risk, plus it verifies each vendor’s alignment status across real traffic.

Diagnosing and fixing common DMARC delivery problems

Even with good configuration, edge cases can break alignment. Here’s how to find and fix them.

Forwarding and auto‑forwarders

Problem: SPF fails after forwarding because the forwarder’s IP isn’t in your SPF.
Fix: Ensure DKIM alignment, which will still pass after forwarding. DMARCReport highlights “SPF fail / DKIM pass” post‑forwarding patterns so you can accept these safely.

Mailing lists and listservs (incl. Google Groups)

Problem: Lists often modify the message (subject tags, footers), breaking DKIM; SPF also fails due to re‑transmission.
Fixes:
- Enable “Munge From” or “Rewrite From” on the list so the From: domain matches the list domain, or
- Configure ARC on the list/relay where possible, and rely on DKIM‑friendly settings (no body rewrites).
- In Google Groups, use settings to “Set the sender to the group” when posting externally to domains with DMARC enforcement.
DMARCReport detects listserv patterns via Authentication-Results analysis and recommends sender‑side or list‑side mitigations.

Third‑party sender misconfiguration

Symptoms: DMARC aggregate shows a new source failing both SPF and DKIM; open rates dip.
Fix: Work with the vendor to enable DKIM signing with your domain and adjust envelope domains; consider a subdomain (e.g., notify.yourdomain.com).
DMARCReport sends alerts when a new AS number or IP block begins sending, with pass/fail breakdowns and alignment guidance.

Calendar invites and automated system emails

Google Calendar and Gmail auto‑notices sign with Google’s DKIM and typically align with your domain if the From: is your address.
If a third‑party scheduling tool sends as your domain, require DKIM signing with your domain or route via Google SMTP to inherit Google’s DKIM.

Case study (composite)

A 1,200‑user SaaS company moved to p=reject in 9 weeks. Before rollout, DMARCReport showed 7 distinct unauthorized sources spoofing payroll. After enabling DKIM (2048‑bit), authenticating SendGrid with a custom return path, and shifting Groups to “Munge From” externally, impersonation attempts dropped 97% and their marketing deliverability improved by 3.2%.

Collecting, decoding, and analyzing DMARC reports

DMARC’s power is in its telemetry; make it actionable.

Aggregate (RUA) reports

What they are: Daily XML summaries from receivers showing pass/fail counts per source IP and alignment path.
How to use: Trend alignment coverage, identify unknown senders, and confirm policy impact.
With DMARCReport: Upload or auto‑ingest RUA; get dashboards by source, ASN, geography, and authentication outcome; receive “unknown sender” alerts and policy readiness scores.

Forensic (RUF) reports

What they are: Redacted copies of individual failures (not all receivers send them).
Privacy: May contain message fragments; ensure legal review. DMARCReport supports selective ruf (only for key partners) and automated redaction.
Configure: ruf=mailto:ruf@ruf.dmarcreport.com; fo=1 to request samples.

Operational workflow

Week 1–2: Inventory all senders from RUA, focus on DKIM enablement.
Week 3–4: Verify alignment coverage >95%; start pct=25 quarantine simulation in DMARCReport.
Ongoing: Set alerts for new sources and sudden spikes in fails; rotate DKIM when prompted; review monthly alignment KPIs.

Subdomain policies, organizational domain behavior, and Google services

DMARC applies at the organizational domain by default; subdomains inherit unless you override.

sp= and subdomain strategy

Default: If only _dmarc.example.com exists with p=quarantine, subdomains inherit quarantine.
Override: Publish a subdomain policy with sp=none (or stricter) in the org record, or create explicit _dmarc.sub.example.com records.
Example org record with stricter subdomain policy:
- v=DMARC1; p=quarantine; sp=reject; adkim=s; aspf=r; rua=mailto:rua@rua.dmarcreport.com
Use cases:
- Dedicated marketing subdomain (m.example.com) with its own DMARC (e.g., adkim=s; aspf=s) for tighter control.
- Parked subdomains: Publish p=reject to eliminate abuse.
DMARCReport’s Subdomain Planner inventories active subdomains seen in RUA data and suggests per‑subdomain policies.

Google services nuances

Google Groups: Configure sender rewriting for external recipients when list behavior breaks DKIM; DMARCReport can confirm pass rates per list domain.
Google Sites/Forms notifications: Often come from google.com domains and aren’t governed by your DMARC; verify any workflow tools that send as your domain.

Impact of moving to quarantine/reject and how to mitigate false positives

When you enforce DMARC, unauthorized mail is blocked, but you must protect legitimate edge cases.

Expected impacts

Spoofed mail: Dramatic drop in spoofing reaching inboxes.
Forwarded mail: If DKIM aligns, it keeps delivering; if not, some forwards may go to spam once you quarantine.
Lists: Some external mailing lists may rewrite From: or fail DMARC until configured.

Mitigations

Prioritize DKIM alignment for every sender; DKIM survives forwarding.
Use pct to ramp enforcement gradually; monitor with DMARCReport’s False Positive Watch.
Provide exception paths: For a critical legacy system you can’t fix, route through Google SMTP relay so it inherits Google DKIM, or isolate on a subdomain with a looser DMARC until remediation.

Complementary anti‑phishing controls with Google Workspace

DMARC is foundational; pair it with adjacent controls to strengthen protection.

BIMI (Brand Indicators for Message Identification)

Requires DMARC at enforcement (quarantine/reject) and a good reputation; optionally VMC for logo verification.
Benefit: Visual brand cues that deter phishing look‑alikes and lift open rates 5–10% in many campaigns.
DMARCReport offers BIMI readiness checks and ongoing DMARC compliance monitoring required for BIMI.

ARC (Authenticated Received Chain)

Helps receivers evaluate authentication across intermediaries (lists/forwarders).
Gmail validates ARC on receive; as a sender, prioritize DKIM and choose intermediaries that support ARC. DMARCReport reports ARC pass rates observed in your traffic.

MTA‑STS and TLS Reporting

Enforces TLS for SMTP to prevent downgrade attacks; add TLSRPT for visibility.
DMARCReport correlates TLSRPT with DMARC to identify delivery/security gaps.

S/MIME for internal/executive communications

Provides end‑to‑end message signing/encryption; useful for high‑risk roles. Independent of DMARC but complementary.

FAQs

How long should each DMARC rollout phase last?

Most Google Workspace orgs spend 30–45 days in p=none, 2–3 weeks at pct=25 quarantine, 2–3 weeks at full quarantine, then move to reject. DMARCReport’s readiness score recommends timing based on your live alignment coverage and unresolved sources.

Should I use strict alignment for both SPF and DKIM?

Use adkim=s once DKIM alignment is solid (>98%), but keep aspf=r to avoid SPF breakage from forwarding/listservs. DMARCReport models impacts of stricter alignment before you change tags.

Is it safe to enable forensic (ruf) reports?

Enable ruf selectively and be mindful of privacy; some receivers redact content. DMARCReport supports redaction and access controls and can limit ruf to a subset of receivers.

What about parked or unused domains?

Publish p=reject on parked domains with no legitimate mail. DMARCReport bulk‑generates records and monitors for unexpected traffic.

Do I need -all in SPF if I have DMARC reject?

Not necessarily. DMARC reject is the authoritative control. Many orgs keep ~all to reduce brittleness, relying on DMARC for policy enforcement. DMARCReport will flag any traffic that would be uniquely impacted by switching to -all.

Conclusion: A practical, product‑assisted path to DMARC protection

To start protecting your G Suite email from phishing, authenticate all senders with SPF and DKIM, publish a DMARC record in monitor mode with reporting to DMARCReport, and then use the data to tighten alignment and step up to quarantine and reject. In Google Admin, generate a 2048‑bit DKIM key and publish it; set SPF with include:_spf.google.com and authorized vendor includes; then publish a DMARC record with rua/ruf pointing to DMARCReport. Over 8–12 weeks, DMARCReport will inventory sources, simulate enforcement, detect misconfigurations, and guide you through alignment fixes, subdomain policy decisions, and safe enforcement. The result is materially lower spoofing risk, stronger brand trust (with BIMI readiness), and stable deliverability for your legitimate Google Workspace traffic.