Your DMARC Record Says p=none — That Blocks Nothing

A DMARC record is a DNS TXT entry that instructs receiving mail servers how to handle messages that fail domain authentication — but only a policy of p=quarantine or p=reject actually enforces that instruction; p=none is purely an observation mode that blocks nothing.

The gap between “passing” and “protected”

Authentication headers look clean. SPF passes. DKIM passes. DMARC passes. Your email dashboard shows green everywhere — and a spoofed message sent in your name still lands in someone’s inbox without a flag.

That contradiction is not a bug. It is exactly what p=none is designed to do.

p=none means: collect reports, take no action. Receiving servers log the authentication result and move on. The policy instructs them to deliver the mail regardless of whether it authenticated. Until the policy reads p=quarantine or p=reject, DMARC is a surveillance camera, not a lock.

What our own DNS query showed

On 2026-09-04 SAVYX queried dns.google directly for savyx.kr and read the raw records. The results:

The SPF record was correctly scoped. The DKIM signature existed and was signing outbound mail. The DMARC record was present and syntactically valid.

None of that changed the outcome: the policy said p=none, so the domain was open to spoofing with zero enforcement consequence.

One additional finding from the DKIM data is worth noting. A 162-byte DER value with the header MIGfMA0GCSqGSIb3DQEBAQUA indicates a 1024-bit RSA key. Google’s current recommendation and default is 2048-bit — a 2048-bit key produces a DER header of MIIBIjANBgkq…. The key was functional but below the current strength baseline.

What a real send looked like through those records

Later that same day — measured 2026-09-04 at 20:10 KST — a live send from jknam@savyx.kr to a Gmail address was made and the raw received headers were read directly. The authentication result block reported:

dkim=pass header.i=@savyx.kr header.s=google header.b=N7El8eVA
spf=pass smtp.mailfrom=jknam@savyx.kr
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=savyx.kr

The DMARC line is worth reading carefully. It reports dmarc=pass and shows p=QUARANTINE — but that is Gmail’s evaluation of the sender’s authenticated identity, not a reflection of the DNS policy at the time the message was sent. The DNS record at the point of send was still p=none. The parenthetical policy value in the header traces what the receiver recorded; it does not retroactively change what the DNS published.

The header said pass. The policy enforced nothing. Both statements were simultaneously true.

Five days later: the policy changed

On 2026-09-09 a second dns.google query confirmed an update:

The policy moved from none to quarantine. The percentage clause — pct=5 — means quarantine applies to 5 percent of failing messages during the ramp-up phase. That is the standard graduated deployment: raise the percentage as report data confirms no legitimate mail is failing, then advance to p=reject.

The DKIM key had not been rotated. The key-strength gap remained open five days after the policy upgrade.

Why this sequence is the right model — and what it omits

The none → quarantine → reject progression is the approach the DMARC specification recommends. Start in monitoring mode, read the aggregate reports at rua, identify any legitimate mail sources not yet in SPF, fix them, then tighten. Jumping directly to p=reject on a domain with uncatalogued sending infrastructure risks blocking real mail from internal tools, CRMs, or third-party platforms.

The graduated path is correct. The risk is treating none as a permanent state rather than a diagnostic phase. Many domains publish p=none, collect reports nobody reads, and stay there indefinitely — achieving the appearance of DMARC compliance while providing none of its protection.

The failure mode is not misconfiguration. It is inertia. The record is present. The monitoring address is set. The dashboard shows green. Nothing alerts when no one upgrades the policy.

The piece most guides skip: DKIM key strength is a separate axis

DMARC policy and DKIM key strength are independent controls. A domain can reach p=reject and still be running a 1024-bit DKIM key — as the 2026-09-09 measurement showed for savyx.kr even after the policy upgrade.

A 1024-bit RSA key was considered adequate until roughly 2013. Current cryptographic guidance and Google Workspace’s own default have moved to 2048-bit. The practical risk is not immediate compromise but degraded forward posture: 1024-bit keys are within the feasibility range for well-resourced attackers to factor, and DKIM signatures are archived in received mail, making historical messages retrospectively vulnerable if a key is later broken.

Rotating a DKIM key requires generating a new key pair, publishing the new public key to DNS, configuring the sending service to sign with the new private key, and — after sufficient propagation time — revoking the old selector. It does not require a maintenance window or service interruption when done correctly.

The decision sequence

Three questions determine where a domain actually stands:

1. What does the DMARC policy say? Query _dmarc.yourdomain.com at dns.google and read the p= tag. None means no enforcement exists, regardless of what the authentication result headers report.

2. What does the DKIM key’s DER header start with? MIGfMA0G indicates 1024-bit. MIIBIjAN indicates 2048-bit. The key selector name (e.g., google._domainkey) is in the DKIM-Signature header of any outbound message you send yourself and read raw.

3. Is the rua address monitored? Aggregate reports arrive as XML-in-ZIP daily from each receiving domain. If no one reads them, the monitoring phase provides no information to act on.

The practical sequence: confirm the policy is not permanently parked at none, set a calendar date to raise pct to 100 and then advance to reject, and schedule DKIM key rotation to 2048-bit as a separate task with its own deadline.

Looking for more on ai & digital income? Visit SAVYX

Frequently Asked Questions

What does DMARC p=none actually do?

It instructs receiving mail servers to take no action on messages that fail authentication — they deliver the mail and optionally send a report to the rua address. p=none is a monitoring mode, not an enforcement mode. No spoofed message is quarantined or rejected under this policy.

How do I check my own DMARC policy right now?

Go to dns.google, query TXT records for _dmarc.yourdomain.com, and read the p= tag in the result. If it says p=none, enforcement is off. If it says p=quarantine or p=reject, check the pct= value to see what percentage of failing mail the policy currently covers.

Why does my email header say dmarc=pass if my policy is p=none?

The pass result means the message’s authenticated identity matched the From: domain — that is a separate question from what the policy does with failures. A domain at p=none can produce dmarc=pass on legitimate mail and still apply zero enforcement to spoofed mail. Both are simultaneously true.

How do I know if my DKIM key is 1024-bit or 2048-bit?

Send a message to yourself and read the raw headers. Find the DKIM-Signature header and note the selector value (e.g., s=google). Then query that selector at dns.google — for example, google._domainkey.yourdomain.com — and read the DER public key. A header starting with MIGfMA0G indicates 1024-bit; MIIBIjAN indicates 2048-bit.

What is the safe order to upgrade DMARC policy?

Start at p=none with a monitored rua address and read aggregate reports for at least two weeks to identify all legitimate sending sources. Once SPF covers all of them, move to p=quarantine at pct=5, raise pct gradually to 100 as no legitimate mail fails, then advance to p=reject. Rotate the DKIM key to 2048-bit as a separate parallel task.

Disclosure: As an affiliate, this post may earn a commission from qualifying purchases at no extra cost to you.