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 Microsoft 365 July 2026 price change is really about commitment term
Microsoft reset Microsoft 365 list prices on 1 July 2026. The headline seat numbers moved a little; the commitment term moved a lot. Here are the confirmed figures and the tenant check to run before the next renewal.
Mailbox forwarding rules survive the leaver: the offboarding check most runbooks skip
An enabled inbox forwarding or redirect rule keeps sending a departed employee mail long after the account is disabled. Here is how to find every one from Microsoft Graph and shut it before it becomes an exfiltration path.
The delegated OAuth grant that outlives the employee
Disabling an Entra account does not delete the delegated OAuth grants the person consented to. A third-party app can keep acting on a former employee until the grant itself is revoked. Here is how to read them and which scopes to treat as high risk.