DMARC at p=none is not protection: what a deliverability check reads from public DNS
A DMARC record at p=none observes spoofing without blocking it. A free deliverability check reads SPF, DKIM, and DMARC from public DNS and tells you exactly which of those three is only watching. Here is how to run it and read it.
Publishing a DMARC record is not the same as enforcing one. A record at p=none tells receivers to report on spoofed mail and deliver it anyway. Plenty of domains stop there and believe the job is done. The ITSailor deliverability check reads SPF, DKIM, and DMARC straight from public DNS and grades what each policy actually does, with no access to the domain required.
Last verified: 2026-08-03.
Prerequisites
- The domain name. Nothing else: every record checked is public DNS.
- A resolver, or the check itself at /tools/deliverability.
What the check reads
- SPF. Presence, the all mechanism (a plus-all authorises the whole internet), duplicate records (an RFC 7208 PermError), and the 10-DNS-lookup limit.
- DMARC. Presence, policy (none, quarantine, or reject), the pct tag, and whether aggregate reporting (rua) is set. A p=none is flagged as monitoring only.
- DKIM. Common selectors are probed; a key under 2048 bits is flagged as weak.
Google and Yahoo have required DMARC for bulk senders since February 2024, so a missing or monitoring-only record is a live deliverability risk, not a theoretical one.
Expected output
# Read the enforcing policy directly
dig +short TXT _dmarc.example.com
# v=DMARC1; p=none; rua=mailto:dmarc@example.com <- observing only
# v=DMARC1; p=quarantine; ... <- spoofed mail to spam
# v=DMARC1; p=reject; ... <- spoofed mail refused
A p=none result is the one to act on: it means no forged mail is actually being blocked.
Side effects
Moving from p=none to p=quarantine or p=reject can send legitimate but unauthenticated mail to spam, so stage it. Read the rua aggregate reports first, fix the senders that fail alignment, then raise the policy. The check itself is read-only DNS and changes nothing.
Rollback
Every step is a DNS record edit and reversible. Lower the policy back to p=none if a legitimate sender breaks, fix that sender, then raise it again. Keep the previous record text so the revert is exact.
Limitations
This reads public DNS at one moment and infers DKIM key length from the record; it does not send a test message or verify alignment against live traffic, which the aggregate reports do over time. A clean record is evidence of a good configuration, not proof that no spoofing attempt will ever land.
Sources and further reading
Turn the procedure into a tenant decision.
The Architecture Workshop maps the checks, side effects, and rollback path to your own Microsoft 365 environment.
Review the workshopMore from Ops Log
The Google Workspace scope for reading a leaver's app grants is not read-only
Listing a Google Workspace user's third-party app tokens needs admin.directory.user.security, the same scope that deletes them, and Google lists no read-only variant. Microsoft Graph lists the equivalent grants with Directory.Read.All. Treat the Google credential as a revocation key.
The Azure role called Cost Management Reader is not read-only
Cost Management Reader is described as able to view cost data, yet its action list carries a Microsoft.Support wildcard that includes creating and updating support tickets. The built-in Reader role matches it on every Cost Management feature and cannot write a ticket.
A Microsoft 365 DKIM CNAME target has two documented formats: read it per domain, never build it
Microsoft documents two DKIM CNAME target formats for Microsoft 365 custom domains, one ending in onmicrosoft.com and one in dkim.mail.microsoft. The page splits them by new versus existing custom domain and never mentions tenant age. Read each domain's values with Get-DkimSigningConfig.