How to pitch DMARC to clients using Google Workspace
Updated on 29 Oct 2026: We updated the Google Workspace rollout advice and clarified Gmail sender requirements.
Pitch DMARC to Google Workspace clients as an ongoing service that controls use of their email domain. The client already trusts Google Workspace for mailboxes and identity within everyday collaboration, but DMARC sits above the mailbox layer. It covers the visible From domain across Google-sent mail and every other system that sends with that domain.
The practical MSP pitch is simple: the service identifies every legitimate sender, confirms SPF and DKIM alignment, publishes a staged DMARC policy, monitors aggregate reports, fixes failures, and moves the domain toward enforcement while reducing the risk of disrupting valid email. That turns DMARC into a managed service with discovery, change control, reporting, and client accountability.
For a broader service model, keep this inside your DMARC for MSPs offer. Suped, our DMARC platform, fits this workflow when you need multi-client visibility, automated issue detection, alerts, and client-ready reports in one operating console.
- Risk: A client domain can be impersonated even when the company uses Google Workspace correctly.
- Trigger: A phishing concern, cyber insurance request, compliance review, or deliverability issue opens the conversation.
- Deliverable: The MSP delivers a sender inventory, DNS changes, report monitoring, and staged policy enforcement.
- Proof: The client sees authenticated legitimate volume, unresolved senders, policy progress, and completed fixes.
Explain what Google Workspace does not cover
A Google Workspace client often assumes Gmail security settings and DMARC are the same thing. They are not. Google Workspace can sign outbound Gmail with DKIM and support SPF, but the DMARC record lives in the client DNS zone. DMARC also evaluates mail claiming to be from the domain, including billing systems, website forms, CRMs, scanners, ticketing tools, and other application mail.
Google's DMARC setup guide says to enable SPF and DKIM at least 48 hours before DMARC, authenticate third-party senders, and publish the DMARC TXT record at _dmarc in DNS. Use _dmarc.example.com for the full record name, replacing example.com with the client domain; some DNS hosts append that domain automatically. No Google Admin console setting publishes DMARC. The client still needs a managed rollout plan.
Google Admin console showing Google Workspace DKIM authentication settings.
The gap is where the MSP earns the service margin. The client does not need a lecture about TXT syntax. They need someone to identify legitimate senders, explain failed alignment, approve safe DNS changes, and decide when enforcement is ready.
Keep the promise precise. DMARC enforcement limits unauthorized use of the client's exact visible From domain at participating receivers. It does not stop lookalike domains, display-name impersonation, abuse of a compromised mailbox, or malicious content sent through an authorized account. It also does not guarantee inbox placement.
Client-ready framing
Use this wording in sales calls: Google Workspace helps authenticate mail that Google sends for you. DMARC enforcement limits unauthorized use of the exact domain in the From address and gives us reports about senders observed by participating receivers.
- Scope: Google Workspace is one sender, not the whole sender estate.
- Control: DMARC states the domain owner's requested treatment when neither SPF nor DKIM passes with alignment.
- Evidence: Aggregate reports identify observed sending sources and their authentication results.
- Outcome: The end state is enforcement with known senders authenticated.
Use Gmail sender requirements to explain urgency
Google's sender requirements already apply to mail sent to personal Gmail accounts, including mail sent through Google Workspace. All senders need SPF or DKIM. Bulk senders need both SPF and DKIM, plus DMARC with at least p=none; direct mail must pass DMARC through SPF or DKIM alignment.
Google's bulk sender definition counts about 5,000 messages or more within 24 hours across the same primary domain and its subdomains. Bulk sender status is permanent once assigned. Check total traffic across Google Workspace and third-party senders, rather than only one mailbox.
- Explain the minimum honestly: p=none meets Google's DMARC policy requirement, but it does not request rejection or quarantine of impersonation.
- Keep the service scope clear: bulk marketing and subscribed mail also needs one-click unsubscribe. Authentication alone does not satisfy every sender requirement.
Use compliance as the starting point for the conversation. The managed service then works toward enforcement after the client's legitimate senders are authenticated.
Map DMARC to service outcomes
A strong pitch connects DMARC to things the client already pays an MSP to manage: risk reduction, operational continuity, compliance evidence, and clear reporting. Avoid starting with acronyms. Start with the operational question: who is allowed to send mail as this domain, and what handling should receivers apply when everyone else tries?
|
|
|
|
|---|---|---|---|
Impersonation | Enforce DMARC | Policy plan | Approved senders pass under reject |
Unknown senders | Inventory sources | Sender list | Approved sender pass rates |
DNS drift | Review records | Change log | No duplicate or invalid records |
Reporting | Summarize results | Client report | Authentication trends and open issues |
Compact pitch map for a Google Workspace DMARC service.
This is also the point to separate implementation from DMARC monitoring. The initial setup creates visibility. The managed service keeps that visibility useful as new applications, vendors, domains, and DNS changes appear.
Policy stages clients understand
Use policy stages as business checkpoints rather than technical tags alone.
Monitor
p=none
Collect reports and identify legitimate senders before enforcement.
Optional test
p=quarantine; t=y
Request reduced handling at receivers that support t=y; other receivers can apply quarantine.
Quarantine
p=quarantine
Request spam-folder treatment for mail that fails DMARC.
Reject
p=reject
Request rejection after every approved sender passes reliably.
Lead with a Google Workspace DMARC readiness audit
For MSP owners, the easiest first step is a lightweight DMARC readiness audit for each Google Workspace client. It gives the client something concrete without forcing them into enforcement on day one. The audit should answer whether SPF exists, whether Google DKIM is active, whether a DMARC record exists, where reports go, and which non-Google senders appear in the data.
Google Workspace DMARC audit flowchart covering domains, SPF and DKIM checks, sender inventory, the DMARC record, and reports.
The audit should be specific enough to create action. A vague result such as email authentication needs improvement does not sell a service. A useful result names each finding, such as a missing DMARC record, inactive Google DKIM signing, an SPF lookup-limit problem, or a billing platform that fails DMARC because neither authentication method passes with alignment.
For Google Workspace-only sending, Google's SPF instructions use v=spf1 include:_spf.google.com ~all. Keep one SPF record per hostname. If other systems use that hostname for SPF, merge their authorized mechanisms into the existing record and count nested includes toward the ten-lookup limit.
For Google Workspace DKIM setup, open Apps > Google Workspace > Gmail > Authenticate email in Google Admin console. Generate a 2048-bit key where supported, publish the supplied selector and public key in DNS, then click Start authentication. Send an external test message and inspect its Authentication-Results header for dkim=pass using the client domain.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
When the first audit finds issues, the next conversation should be about service delivery. Group findings into immediate DNS fixes, sender-owner questions, and monitored rollout items. That keeps the project from becoming a free troubleshooting session.
- Inventory: List all domains, aliases, subdomains, and parked domains that use the client's brand.
- Authenticate: Confirm one valid SPF record and active Google DKIM signing before tightening DMARC policy.
- Discover: Use reports to find application mail, vendor mail, in-house relays, and unknown sending sources.
- Remediate: Fix legitimate senders before tightening policy.
- Report: Show management what changed and what still needs a business decision.
Explain SPF and DKIM alignment
The most common MSP mistake is pitching DMARC as if the client only sends mail through Gmail. Google Workspace is important, but many client domains also send invoices, password resets, support replies, and marketing mail. DMARC cares whether those messages pass SPF or DKIM and whether the authenticated domain matches the visible From domain.
Weak pitch
- Claim: We will add a DMARC record and the domain is protected.
- Gap: It ignores sender discovery and client-side ownership.
- Risk: Valid business email breaks when policy is tightened too fast.
Stronger pitch
- Claim: We will find every legitimate sender before enforcement.
- Method: We will review both SPF and DKIM results; DMARC needs one passing method with alignment.
- Result: The client gets a staged path to reject with fewer surprises.
For clients that use many senders, explain that SPF and DKIM results are not enough on their own. A message can pass SPF for its Return-Path domain or DKIM for its signing domain (d=) and still fail DMARC if neither authenticated domain matches the visible From domain under the configured alignment mode. DMARC passes when either SPF or DKIM passes with alignment. Relaxed alignment, the default, accepts the same organizational domain; strict alignment requires an exact match. Forwarding often breaks SPF, so an aligned DKIM signature is usually the more durable path.
Alternative DMARC records under RFC 9989, publish one at a timedns
Host: _dmarc Type: TXT Value: v=DMARC1; p=none; rua=mailto:d@example.com Host: _dmarc Type: TXT Value: v=DMARC1; p=quarantine; t=y; rua=mailto:d@example.com Host: _dmarc Type: TXT Value: v=DMARC1; p=quarantine; rua=mailto:d@example.com Host: _dmarc Type: TXT Value: v=DMARC1; p=reject; t=y; rua=mailto:d@example.com Host: _dmarc Type: TXT Value: v=DMARC1; p=reject; rua=mailto:d@example.com
These examples follow RFC 9989, which made pct historic and added t=y for testing. Publish only one of these DMARC policy records at a time, replacing the previous value and using the real reporting address. Google rollout examples that still show pct use legacy syntax. Supporting receivers interpret p=quarantine; t=y as a request for none, and p=reject; t=y as a request for quarantine. Receivers that ignore t=y can apply the full published policy, so test mode is not a safe preview everywhere. Do not promise percentage-based enforcement. For a controlled rollout boundary, stage a known mail stream on a subdomain with its own DMARC policy.
Plan centralized report intake
An MSP usually sends aggregate reports to a reporting domain outside the client's organizational domain. That creates an external report destination. The reporting-domain owner must authorize receipt in DNS, or some receivers will withhold reports even when the client's DMARC record is valid.
External aggregate report authorizationdns
Client DNS Host: _dmarc.client.example Type: TXT Value: v=DMARC1; p=none; rua=mailto:aggregate@reports.example Reporting-domain DNS Host: client.example._report._dmarc.reports.example Type: TXT Value: v=DMARC1;
The authorization record belongs in the DNS zone for the report destination, not the client zone. When onboarding a client into Suped, use the report destination and authorization values supplied for that organization, then verify that aggregate data arrives before closing the setup task.
Aggregate reports cover traffic seen by reporting receivers. Not every receiver sends reports, and internal Google Workspace messages are not guaranteed to appear. Pair report data with sender-owner confirmation and external test messages. Measure approved senders separately from unauthorized traffic so blocked impersonation does not obscure their authentication results.
- Ownership: Record who controls the client DNS zone and the report-destination DNS zone.
- Authorization: Verify external destination authorization before expecting reports from participating receivers.
- Validation: Confirm DNS resolution and actual report arrival for every onboarded domain.
- Privacy: Document report retention and access because aggregate data exposes sending patterns.
Define the managed service scope
A DMARC offer becomes profitable when the boundaries are clear. Separate the service into assessment, implementation, monitoring, remediation, and reporting. That structure stops DMARC from being treated as unlimited DNS support and gives the client a clear reason to keep paying after the first TXT record goes live.
This also makes it easier to package DMARC monitoring as a recurring service. The setup project creates the baseline. The monthly service keeps sender data clean, watches for new failures, and gives the client readable evidence. Quote setup separately and define recurring fees by monitored domains and included remediation work, with a report cadence and response targets in the agreement.
Avoid these scope traps
- Free fixes: Do not include unlimited vendor remediation in a basic audit.
- DNS ownership: Confirm who can approve records before the project starts.
- Sender silence: Make clients responsible for naming business owners for unknown senders.
- False finish: Do not call the work complete while the policy remains permanently at monitoring.
For clients with limited DNS access or frequent sender changes, Hosted DMARC can reduce repeated DNS tickets during policy changes. Hosted SPF helps when the client has many authorized senders and the SPF record approaches its ten-lookup limit.
Show the Suped workflow
Suped, our DMARC platform, supports repeatable MSP delivery with client separation, automated issue detection, hosted record management, blocklist (blacklist) monitoring, alerts, and client reporting. The operating rhythm matters more than the dashboard: onboard, review, remediate, approve, enforce, and report.
MSP organizations page showing client organizations, domain counts, email volume, and domain status columns
A Google Workspace DMARC service needs a place to track many clients without mixing domains, reports, and ownership. Suped's MSP dashboard supports that workflow: add a client organization, onboard domains, monitor policy and authentication health, review issues, and produce client reports without handing the client raw XML.
What to show clients
- Current state: Show DMARC policy, reporting status, observed Google Workspace volume, and other sources.
- Issue list: Show failed alignment, missing DKIM, SPF issues, and unknown sending sources.
- Fix path: Show exact steps to resolve each issue and verify the result.
- Client report: Show policy progress, authentication health, and open decisions in plain language.
After onboarding, keep a recurring review cycle with alert thresholds, sender remediation, policy staging, and reporting that a nontechnical client can understand.
Handle common objections
Most objections are reasonable. The client is worried about breaking email, adding another security task, or paying for something they thought Google already covered. The response should be concrete and tied to delivery.
- Already protected: Google Workspace protects Google mailboxes, while DMARC covers use of the visible From domain across all senders.
- Breakage fear: The rollout starts with monitoring and reaches enforcement after legitimate senders pass. Test mode is optional because receivers that ignore it can apply the full policy.
- DNS concern: Use change approval, rollback notes, and hosted records where the client wants fewer DNS changes.
- Value concern: The service produces monthly evidence: authenticated senders, failures, fixes, and policy progress.
If the client asks whether Google Workspace alone is enough, answer with the sender list. If every legitimate message comes through Google and Google DKIM is active, the rollout is simpler. If reports show other systems, those systems need owner approval and authentication work before enforcement.
Use this rollout checklist
The client should see a clear sequence before they approve the work. This gives the MSP defined milestones and makes enforcement controlled and auditable.
- Access: Confirm admin access, DNS access, reporting address, and client approval contacts.
- Google: Check SPF, DKIM, routing, aliases, domains, and outbound relay behavior.
- Senders: Run reports long enough to audit client senders before enforcement begins. Cover infrequent billing cycles and seasonal campaigns rather than relying on a fixed number of days.
- Policy: Publish monitoring first, then stage quarantine and reject after checking legitimate senders. Use RFC 9989 test mode only with the full-policy compatibility risk understood.
- Review: Meet with the client on failures, unknown sources, and sender owner decisions.
- Maintain: Keep monitoring after reject because new senders and DNS changes still create risk.
Do not skip discovery
Moving straight to reject on a Google Workspace client sounds efficient, but it ignores application mail and vendors. Use measured enforcement after report data confirms legitimate sources.
Close with a defined next step
Ask the client to approve a readiness audit for one domain, with a named DNS approver and business contact. Offer this next step: "We will confirm Google Workspace authentication, identify other senders, and return a scoped plan before changing enforcement." Agree on the review meeting and the evidence needed to authorize the next policy stage.
Frequently asked questions
Explain DMARC as an exact-domain control. Google Workspace helps authenticate mail Google sends, while DMARC publishes requested handling when neither SPF nor DKIM passes with alignment for the client's visible From domain.
No. Start with monitoring, identify legitimate senders, fix alignment failures, then apply quarantine and reject when reports and external tests show the domain is ready. Test mode is optional and does not protect against full-policy enforcement at receivers that ignore it.
RFC 9989 made pct historic because receivers applied percentage sampling inconsistently. The t=y tag requests reduced handling at supporting receivers; receivers that ignore it can apply the full published policy. Use a separate subdomain policy when the client needs a controlled rollout boundary.
Audit SPF, Google DKIM, the current DMARC record, external report authorization, all known senders, unknown report sources, DNS ownership, and the client's approval process.
Yes. Google-sent mail can pass while application mail, scanner mail, or web form mail fails DMARC because neither SPF nor DKIM passes with alignment. Aggregate reports expose failures seen by reporting receivers; external test-message headers help verify individual senders.
Suped, our DMARC platform, gives MSPs a multi-client place to analyze reports, find authentication issues, manage hosted records, receive alerts, and create client reports. Its blacklist monitoring supports reputation checks alongside the authentication workflow.
