DMARC Setup for Google Workspace and Microsoft 365: A Small Business Guide

What DMARC Actually Does (and Why It Matters)

If your domain is yourcompany.com and you don't have DMARC published — or you have DMARC published at p=none — attackers can send email that appears to be from [email protected] to your customers, your employees, and your vendors. The recipient's inbox will accept it. The "From" line will show your domain. The display name will show your CEO's name if the attacker chose it well. There will be no technical signal that anything is wrong.

This is how the Business Email Compromise attacks work. They're often built on weak or missing email authentication.

DMARC is the policy layer that tells receivers (Gmail, Outlook, Yahoo, Apple Mail, etc.) what to do when an email from your domain fails authentication. Configured strictly, DMARC moves the attacker from "trivially impersonating your domain" to "needing a much harder attack" — typically a lookalike domain, which most people will eventually notice.

DMARC builds on two existing standards:

• SPF lists the IPs and services allowed to send mail for your domain
• DKIM cryptographically signs outbound mail so receivers can verify integrity

DMARC sits on top and says: "If a message fails SPF or DKIM checks (and the failures aren't aligned with my domain), here's what I want you to do." The options:

• p=none — Do nothing. Just send me reports. Useful for monitoring before you tighten.
• p=quarantine — Send to spam. The email is delivered, but not to the inbox.
• p=reject — Refuse to accept. The email is rejected at the SMTP layer.

The end goal for every small business should be p=reject. The path to get there safely is a 4-6 week monitoring period at p=none, then a step to p=quarantine, then p=reject.

If you're impatient and just want to skip to the final state: you can, but you risk legitimate mail being rejected if you missed a service. The monitoring period exists to catch every service that sends mail on your behalf — your help desk tool, your invoicing platform, your e-commerce platform, the marketing automation tool the team you forgot about. The reports tell you which services are failing so you can authorize them before you flip the switch.

Prerequisites

Before you touch DMARC, you need SPF and DKIM in place. Use our DNS Tools to inspect your current records.

For Google Workspace tenants:

• SPF should include include:_spf.google.com -all
• DKIM should be enabled in Admin Console → Apps → Google Workspace → Gmail → Authenticate Email. Set up the 2048-bit key, then publish the DNS record Google generates.
• After publishing the DNS record, return to the Admin Console and click "Start Authentication" to flip DKIM on.

For Microsoft 365 tenants:

• SPF should include include:spf.protection.outlook.com -all
• DKIM is enabled in Defender Portal → Email & collaboration → Policies & rules → Threat policies → DKIM. You'll publish two CNAME records pointing to selector1._domainkey and selector2._domainkey at Microsoft's infrastructure, then enable signing.

Once SPF and DKIM are both passing for legitimate outbound mail, you're ready to publish DMARC.

Setting Up DMARC Reporting

DMARC reports are the part most small businesses skip — and skipping them is why most small businesses stay at p=none forever. Without reports, you have no signal of which legitimate services are failing authentication, so you never feel safe enough to escalate the policy.

A DMARC report is a daily XML file sent by major mailbox providers listing every message they saw from your domain, what authentication checks it passed or failed, and the source IP. Raw XML is unreadable for humans. A DMARC reporting tool aggregates the XML into a dashboard.

Free DMARC reporting tools that work for small businesses:

• Postmark DMARC — free for any volume, weekly digest emails, dead-simple onboarding. Sign up, paste your domain, copy the rua=mailto: address into your DMARC record. Recommended for most small businesses.
• Valimail Monitor — free tier, more polished dashboard. Solid alternative.
• dmarcian — has a small-business free tier, more depth if you want to grow into it.

Pick one. The reporting tool gives you the email address you'll embed in your DMARC record.

Publishing the DMARC Record

The DMARC record is a TXT record at the subdomain _dmarc.yourcompany.com. The value is a string of semicolon-separated tags.

Starting record (monitor mode, recommended for first 2-4 weeks):

v=DMARC1; p=none; rua=mailto:YOUR_REPORTING_ADDRESS; pct=100; aspf=r; adkim=r; fo=1

Translation:

• v=DMARC1 — version
• p=none — policy: do nothing, just report
• rua=mailto:... — aggregate reports go here (paste the address from your reporting tool)
• pct=100 — apply the policy to 100% of messages (relevant once you escalate)
• aspf=r — relaxed SPF alignment (the default; allows subdomains to align)
• adkim=r — relaxed DKIM alignment (the default; allows subdomains to align)
• fo=1 — generate forensic reports when any underlying check fails

Where you publish this depends on your DNS provider. Almost every DNS provider (Cloudflare, Google Domains, GoDaddy, Namecheap, Route 53) lets you add a TXT record through their dashboard. The host/name field gets _dmarc (your provider will add .yourcompany.com automatically). The value is the full string above.

After publishing, give DNS 5-15 minutes to propagate, then verify the record with our DNS Tools — type your domain, select DMARC, and confirm the record matches what you published.

Reading Your DMARC Reports

Once the record is live, your reporting tool will start receiving aggregate reports from major mailbox providers within 24-48 hours. The first useful report typically arrives 2-3 days in.

What you're looking for:

Pass-rate by source. Your reporting dashboard will show every IP/service that sent mail claiming to be from your domain. Each gets a pass/fail rate against SPF and DKIM. A healthy state is 95%+ pass rate from every legitimate source, and 0% pass from anything you don't recognize.

Unauthorized sources. Sources you don't recognize sending email as your domain. Sometimes legitimate (a forgotten marketing tool, an old vendor's mail relay), sometimes hostile (someone trying to spoof you). Investigate every unknown source before escalating your policy.

Failed but legitimate sources. Tools that are sending real mail for you but failing SPF or DKIM. The most common: third-party invoicing tools where SPF was never updated, or DKIM was never enabled. Fix these by either adding them to your SPF includes, enabling DKIM at the vendor, or using a tool like SubdomainSync to handle subdomain delegation.

You're ready to escalate from p=none to p=quarantine when:

1. You've had at least 14 days of reports
2. Every legitimate source is passing SPF or DKIM at 95%+
3. You've investigated every unknown source and either authorized or confirmed it's hostile
4. Your DMARC reports show consistent volume (no surprise spikes from new sources)

Escalating to Quarantine and Reject

The escalation pattern most pros use:

Week 0: Publish p=none. Start monitoring.

Week 2-4: Confirm pass rates are high and no surprises. Move to:

v=DMARC1; p=quarantine; pct=25; rua=mailto:YOUR_REPORTING_ADDRESS; aspf=r; adkim=r; fo=1

Note pct=25 — DMARC will apply the quarantine policy to only 25% of failing messages. This lets you catch any remaining legitimate-but-failing services in the wild without blocking 100% of them. Watch the reports for a week.

Week 4-5: If reports stay clean, bump pct:

v=DMARC1; p=quarantine; pct=100; rua=mailto:YOUR_REPORTING_ADDRESS; aspf=r; adkim=r; fo=1

Now 100% of failing messages go to spam at major receivers. Watch another week.

Week 5-6: Move to reject:

v=DMARC1; p=reject; pct=100; rua=mailto:YOUR_REPORTING_ADDRESS; aspf=r; adkim=r; fo=1

Failing messages now get refused at the SMTP layer. Your domain is now actively protected against spoofing.

If at any stage you see legitimate mail being affected, drop back to the prior step, fix the issue, and re-escalate. There's no shame in this — most enterprises take 3-6 months to land at p=reject. The fact that you got there at all puts you in a small minority of small businesses.

Common Gotchas

Subdomains. Your DMARC record applies to your apex domain (yourcompany.com) by default, not to subdomains (marketing.yourcompany.com, staging.yourcompany.com). If you send mail from subdomains, either publish a separate DMARC record at each subdomain, or use the sp= tag in your main record to set a default subdomain policy. Example: sp=quarantine in your apex record makes all unspecified subdomains inherit that policy.

Mailing lists and forwarding. When someone forwards an email through a mailing list (or a personal "forward all to my Gmail" rule), SPF often breaks because the source IP changes. DKIM survives forwarding if the body wasn't modified. This is why DKIM is more important than SPF for DMARC — it survives forwarding. Make sure DKIM is passing for your primary mail flow, and DMARC's default OR-of-SPF-and-DKIM logic will handle forwarded mail correctly.

Third-party services you forgot about. The single most common reason DMARC reports show failing legitimate mail: a service that was set up two years ago and forgotten. Common culprits: Mailchimp, HubSpot, Constant Contact, ZenDesk, FreshDesk, Stripe transactional emails, Calendly, your e-commerce platform, your appointment reminder tool. Each one needs to be either added to your SPF includes, configured for DKIM with your domain, or moved to a subdomain that has its own SPF/DKIM setup.

Display name impersonation. DMARC protects your domain. It doesn't protect against an attacker registering [email protected] with the display name "CEO Name." The recipient's mail client may show only the display name, hiding the actual sender address. This attack bypasses DMARC entirely — it requires inbox-side anti-impersonation controls (Microsoft Defender's "user impersonation protection," Google's "anomalous sender" warnings). Make sure both are enabled in your tenant.

Lookalike domains. DMARC doesn't help against an attacker who registers breachhor1zon.com (the digit 1 instead of letter i) and sends from there. Their domain has its own DMARC record, which they control. The only defense is monitoring for lookalike domains (services like DomainTools, RiskIQ, or DnsTwist for the free open-source approach) and training your team to inspect the actual email address, not just the display name.

What to Do This Week

1. Run the Exposure Report on your primary domain. Confirms SSL/TLS basics and gives a baseline score.
2. Inspect your current DMARC state via our DNS Tools. If you have no DMARC record or it's still at p=none, you have work to do.
3. Sign up for a free DMARC reporting tool (Postmark, Valimail, or dmarcian).
4. Publish the starting p=none record with your reporting email embedded.
5. Schedule a calendar reminder for 2 weeks out to review reports and consider the move to p=quarantine.

That's it. No new vendors, no licenses, no agents on endpoints. Just three DNS records and a 4-week patient process. When you're done, you'll have closed the single most common attack path against small businesses.

Final Word

If you do nothing else from this guide: publish a starting DMARC record at p=none with reports going to a free tool. That single action gives you visibility into who's already spoofing your domain. The data will probably surprise you. From there, the path to p=reject is methodical and reversible at every step.

DMARC is the rare security control that's free, requires no new software, and stops a specific high-impact attack pattern. There's no good reason for any small business to not have it deployed at p=reject within 60 days of reading this.