The fix is to make every legitimate sender pass DMARC through either SPF or DKIM using the same organizational domain that appears in the visible From address. For Microsoft 365, that usually means enabling DKIM for each custom domain, keeping SPF under the lookup limit, and publishing one correct DMARC TXT record in DNS. For Google Workspace, it usually means turning on DKIM for the sending domain, using the correct SPF include, and handling aliases or third-party senders so the visible From domain matches the authenticated domain.
I start with the message source, not the policy. A stricter DMARC policy does not repair broken authentication. It only tells receivers what to do after authentication fails. The practical order is simple: identify every sender in reports, fix SPF or DKIM for each sender, verify the visible From domain, then move the policy through p=none, p=quarantine, and p=reject.
Suped's product is useful in this workflow because it turns raw DMARC XML into source-level issues, fix steps, and alerts. You still need to update Microsoft 365, Google Workspace, and DNS, but Suped gives you the evidence for what to change first.
The direct fix
DMARC fails only when both possible paths fail: SPF does not pass with the visible From domain, and DKIM does not pass with the visible From domain. If either path passes and uses a matching organizational domain, DMARC passes. That rule is the same whether the mailbox is in Microsoft 365 or Google Workspace.
The fastest way to repair a domain is to group failures by sending source. I look for Microsoft 365 user mail, Google Workspace user mail, automated application mail, billing notices, calendar tools, scanners, and any gateway that rewrites mail. Each source needs a clean path through SPF or DKIM. DKIM is usually the better long-term path because forwarding and list software break SPF more often than DKIM.
- Find the source: Use DMARC aggregate reports to see the IP, sending service, SPF result, DKIM result, and domain used by each identity.
- Fix DKIM first: Turn on DKIM signing for each custom domain that sends mail through Microsoft 365 or Google Workspace.
- Fix SPF second: Keep one SPF TXT record per hostname, include only active senders, and stay under the 10 DNS lookup limit.
- Check the From domain: The visible From domain must share the same organizational domain as the passing SPF or DKIM identity.
- Stage the policy: Do not jump to reject until the report data shows your legitimate senders are consistently passing.
Microsoft Defender portal domain authentication screen
Do not treat p=reject as the repair
A reject policy blocks unauthenticated mail after receivers apply DMARC. It does not make Microsoft 365, Google Workspace, or a third-party sender authenticate correctly. Move to reject only after the sources in your reports are known and fixed.
Microsoft 365 fixes
For Microsoft 365 custom domains, DMARC lives in your public DNS, not inside a Microsoft 365 control that manages the custom domain record for you. The Microsoft DMARC guide also makes the core rule clear: DMARC checks whether SPF or DKIM passes and uses a domain that matches the visible From domain.
The most common Microsoft 365 problem is custom-domain DKIM left disabled. Mail then depends on SPF. SPF often passes for the envelope sender but fails DMARC because the envelope domain is not the same organizational domain as the visible From domain. Enabling DKIM for the custom domain gives Microsoft 365 mail a stronger path to pass DMARC.
Basic Microsoft 365 SPF recordDNS
Host: @ Type: TXT Value: v=spf1 include:spf.protection.outlook.com -all
That SPF record is enough only when Microsoft 365 is the only service sending for the domain. If payroll, support, billing, or marketing systems send with the same visible From domain, add only the senders you still use. Multiple SPF TXT records at the same hostname cause SPF permerror, which breaks the SPF path for DMARC.
|
|
|
|---|---|---|
DKIM fail | Custom domain off | Enable DKIM |
SPF permerror | Two SPF records | Merge records |
SPF fail | Missing sender | Add source |
DMARC fail | Domain mismatch | Fix sender |
Inbound false fail | Gateway rewrite | Check connector |
Common Microsoft 365 DMARC issues and fixes
If a security gateway sits in front of Microsoft 365 for inbound mail, separate inbound authentication failures from outbound failures. That gateway can change the apparent source IP before Microsoft evaluates SPF. For outgoing mail from your own domain, focus on your public DNS, custom-domain DKIM, and the source listed in DMARC reports.
For deeper Microsoft-specific authentication failures, this related page on Office 365 failures is useful when DKIM or SPF is failing before DMARC even has a chance to pass.
Google Workspace fixes
For Google Workspace, the first repair is the same: make Gmail sign with DKIM for the domain that users place in the visible From address. The Google DMARC setup says to set up SPF or DKIM before DMARC, add the DMARC record at the domain host, and start with a monitoring policy.
In Google Workspace, aliases and secondary domains deserve extra care. A user can send as an alias, but DMARC still judges the visible From domain against SPF or DKIM. If Gmail signs with a different domain than the alias domain, DKIM will not satisfy DMARC for that alias. The clean fix is to authenticate the alias domain itself or route that sender through a path that signs with the alias domain.
Basic Google Workspace SPF recordDNS
Host: @ Type: TXT Value: v=spf1 include:_spf.google.com -all
SPF alone is not enough for many Google Workspace domains because aliases and forwarding can break the SPF path. I prefer DKIM for core user mail and SPF as a supporting control. If you have several alias-domain cases, the related page on Google alignment handling covers those domain relationships in more detail.
Microsoft 365
- DKIM setup: Create the selector CNAMEs, then enable signing for each custom domain.
- SPF source: Use the Microsoft include only where Microsoft 365 sends mail.
- DMARC record: Publish it at the DNS host for the custom domain.
Google Workspace
- DKIM setup: Generate the key in Admin console, add the TXT record, then start signing.
- SPF source: Use the Google include only where Gmail sends the message.
- DMARC record: Publish it at the domain host, not as a Gmail setting.
DNS records that work
A clean DMARC record is boring, which is exactly what you want. Use one TXT record at _dmarc for the domain. Put aggregate reports in rua. Avoid strict SPF or DKIM matching unless you know every subdomain and sender path is ready for it.
Safe starting DMARC recordDNS
Host: _dmarc Type: TXT Value: v=DMARC1; p=none; pct=100; rua=mailto:d@example.com
Use this kind of record while you collect reports and repair sources. If the domain already has a DMARC record, edit the existing one instead of adding another. Two DMARC records at the same hostname cause DMARC discovery problems and inconsistent receiver behavior.
Later enforcement recordDNS
Host: _dmarc Type: TXT Value: v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:d@example.com
Before changing policy, validate DNS. A domain health check is the broadest first pass because it checks DMARC, SPF, and DKIM together. If you only need the DMARC TXT record parsed, use the DMARC checker.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
The tool result should match what you expect before you edit policy. If SPF shows too many lookups, remove old senders or use a managed hosted SPF approach. If DKIM is missing, repair DKIM in the platform before changing DMARC. If DMARC has no reporting address, add one so you can see what receivers are doing.
When hosted DNS controls help
Suped has Hosted DMARC for teams that want staged policy changes without repeatedly editing the raw DMARC TXT value. Suped also has Hosted SPF and SPF flattening for domains that keep hitting SPF lookup limits as new senders are added.
Use reports to find the real problem
DMARC reports show the repair order. I read them by source first, then by domain result. A source sending a large amount of legitimate mail gets fixed before a small source. A source failing both SPF and DKIM gets fixed before one where DKIM passes and only SPF fails.
Raw XML is painful at scale, especially when Microsoft 365, Google Workspace, and other business systems all send for the same domain. Suped's DMARC monitoring groups sources, detects failures, and turns them into steps to fix. It also adds real-time alerts, blocklist (blacklist) monitoring, and deliverability context so authentication issues are not isolated from reputation issues.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For most teams, Suped is the best overall practical DMARC platform because it combines DMARC monitoring, SPF and DKIM diagnostics, Hosted DMARC, Hosted SPF, Hosted MTA-STS, policy staging, alerts, and an MSP-friendly multi-tenant dashboard in one product. The important part is not the dashboard itself. The value is knowing which DNS or platform change removes the next real failure.
- Prioritize volume: Fix high-volume legitimate sources before low-volume noise.
- Separate inbound: Do not confuse messages you receive with messages your domain sends.
- Track domains: Watch every custom domain, alias domain, and active subdomain.
- Review policy: Move enforcement only after reports show legitimate mail passing.
A safe rollout path
The safest rollout is not slow for its own sake. It is staged so failures become visible before receivers start quarantining or rejecting legitimate mail. Microsoft and Google both recommend starting with monitoring, then increasing enforcement after you understand the report data.
DMARC policy rollout stages
Use these stages after SPF and DKIM are active for the domain.
Monitor
p=none
Collect reports and identify sources.
Trial
quarantine 10%
Apply enforcement to a small share.
Contain
quarantine 100%
Increase enforcement after repairs.
Block
reject 100%
Reject failing mail after sources pass.
I normally keep relaxed matching unless the domain has a reason to demand exact subdomain matching. Strict SPF or DKIM matching creates avoidable failures for subdomain senders. It is better to protect the domain with a clean sender inventory, a strong reject policy, and separate subdomains for systems that need their own authentication path.
Flowchart showing the DMARC repair path
Do not forget parked domains. If a domain never sends mail, publish SPF and DMARC records that say no mail is authorized. That reduces spoofing risk without adding operational complexity.
Third-party senders
Most persistent DMARC issues are not caused by Microsoft 365 or Google Workspace user mail. They come from third-party systems that send with your visible From domain but authenticate with their own envelope domain, their own DKIM domain, or no DKIM signature at all.
The fix is specific. Either configure the sender to sign DKIM with your domain, configure a custom return-path that uses your domain for SPF, or send through Microsoft 365 or Google Workspace if that route is appropriate for the mail type. Do not just add every vendor include to SPF. That creates lookup-limit problems and still does not solve DKIM domain mismatch.
|
|
|
|---|---|---|
DKIM mismatch | Custom DKIM | Most senders |
SPF mismatch | Return-path | Bounce control |
Lookup limit | Hosted SPF | Many senders |
Shared sender | Subdomain | Bulk mail |
Third-party sender repair choices
Best practice for sender isolation
Use subdomains for automated mail when you can. A subdomain gives you separate SPF, DKIM, DMARC policy, and reputation handling, while the parent domain keeps cleaner controls for person-to-person mail.
When a vendor cannot sign DKIM with your domain or use a matching return-path, do not put that sender behind a strict parent-domain policy. Move that mail to a subdomain with a separate DMARC record, then watch it until the source is stable.
What good looks like
A healthy Microsoft 365 or Google Workspace DMARC setup has predictable signs. User mail signs with DKIM using the custom domain. SPF has one record per hostname and includes only active senders. DMARC reports show known sources, not mystery IPs. The policy is at reject for protected domains, and parked domains reject everything.
The fastest path is practical: fix DKIM for Microsoft 365 and Google Workspace, repair SPF only where needed, use DMARC reports to find third-party senders, and stage the policy after the data proves legitimate mail passes. Suped's product helps keep that process continuous by detecting new failures, sending alerts, and giving each domain a clear list of issues to resolve.
- First check: Confirm there is exactly one DMARC TXT record at the correct hostname.
- Second check: Confirm Microsoft 365 or Google Workspace DKIM is active for each sending domain.
- Third check: Confirm SPF has one record and does not exceed the DNS lookup limit.
- Fourth check: Confirm every high-volume source passes either DKIM or SPF for the visible From domain.
