Your DMARC Says Quarantine. The pct=5 Line Says 95% Still Gets Through.

DMARC (Domain-based Message Authentication, Reporting and Conformance) is an email authentication policy that tells receiving mail servers what to do with messages that fail SPF or DKIM checks — but only up to the percentage of traffic specified by the pct= tag, which most domain owners never review after initial setup.

The line almost nobody reads after setup

A domain that publishes p=quarantine looks protected. The policy name implies messages that fail authentication get flagged or held. What most administrators never check is the tag sitting right after that declaration: pct=.

The pct= tag controls what fraction of non-authenticating mail the policy actually applies to. At pct=100, every failing message hits the quarantine. At pct=5 — the value measured in savyx.kr’s live DNS record on 2026-09-09 via dns.google — only five messages in every hundred trigger the policy. The remaining 95 land in inboxes exactly as if no DMARC policy existed.

The policy name and the policy effect are two different things. Administrators who read “quarantine” and stop checking have, in practice, a near-open domain.

What the live records actually show

A direct DNS query of savyx.kr on 2026-09-09 returned the full DMARC record:

v=DMARC1; p=quarantine; pct=5; rua=mailto:jknam@savyx.kr

SPF was correctly configured:

v=spf1 ip4:119.205.197.74 include:_spf.google.com ~all

A real outbound send from jknam@savyx.kr to a Gmail address on 2026-09-04 confirmed all three checks pass in practice. The raw received header read: dkim=pass, spf=pass, dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE). So for legitimate mail, the stack works. The exposure is entirely on the spoofed-mail side — and pct=5 leaves that door 95% open.

The second gap: a 1024-bit DKIM key

Buried in the same DNS pull is a quieter problem. The google._domainkey record for savyx.kr returns a DER-encoded public key of 162 bytes, with a header prefix of MIGfMA0GCSqGSIb3DQEBAQUA. That header identifies a 1024-bit RSA key.

Google’s current default — and recommendation — for DKIM keys is 2048 bits, which produces a DER header beginning with MIIBIjANBgkq…. The 1024-bit standard was adequate before modern factoring compute existed; it is no longer the floor serious mail infrastructure uses.

A 1024-bit key does not fail authentication today — it passed the 2026-09-04 send test — but it represents a key-length risk that 2048 eliminates without any deliverability tradeoff. The cost of rotation is one DNS change; the cost of waiting is unknown.

Why pct= exists and when it is legitimately useful

The pct= tag was designed for safe policy rollout. The intended sequence is:

1. Start at p=none — observe, collect reports, fix alignment issues.
2. Move to p=quarantine; pct=5 or pct=10 — apply policy to a small slice while watching for false positives.
3. Ramp pct= to 100 as confidence grows.
4. Promote to p=reject; pct=100 for maximum protection.

pct=5 is a migration step, not a destination. Leaving it there indefinitely means the domain owner completed the first half of hardening and stopped. Receiving servers are told to quarantine failing mail — and then told to only act on that instruction 5% of the time.

Earlier DNS records for savyx.kr, captured on 2026-09-04, showed a prior state of p=none — a policy that intercepts nothing at all by design. The move to p=quarantine; pct=5 represents real forward progress. The remaining action is straightforward: increase pct= incrementally to 100, then evaluate whether p=reject is appropriate.

The three-number audit every domain needs

Most DMARC dashboards surface the policy label and the aggregate pass/fail rate. The numbers that actually define exposure are narrower:

SPF softfail (~all) is a separate debate — a ~all qualifier marks mismatched senders as suspicious rather than failing them outright, which some operators prefer for deliverability safety. That is a deliberate trade-off; the pct= and key-length gaps are not.

What this knowledge lets you decide

If you operate a domain: Pull your DMARC TXT record now. If pct= is below 100 and the setup has been stable for more than a few weeks, the rollout caution that justified a low pct= is over. Raise it to 100. Then check your DKIM key length using any public DER parser — if the header starts with MIGfMA0G, rotate to a 2048-bit key.

If you receive mail from a domain: A sender’s p=quarantine header in authentication results does not mean they are fully protected. The pct= value determines actual enforcement rate, and that value is publicly readable in DNS. For high-value senders — payroll systems, invoice platforms, financial institutions — a quick DNS check tells you whether their quarantine policy is nominal or real.

The structural principle: DMARC’s policy labels read like binary switches, but they are dials. The industry convention of announcing “we have DMARC” without specifying pct= creates a systematic gap between stated protection and actual protection. The gap is measurable, public, and fixable in under ten minutes.

Looking for more on ai & digital income? Visit SAVYX

Frequently Asked Questions

What does pct= mean in a DMARC record?

The pct= tag sets the percentage of non-authenticating mail that the DMARC policy actually applies to. At pct=5, the policy only acts on 5% of failing messages — the other 95% are delivered as if no policy existed. It was designed for gradual rollout and should be raised to 100 once alignment is confirmed.

Is p=quarantine the same as p=reject for email security?

No. p=quarantine tells receiving servers to flag or hold failing messages; p=reject tells them to refuse delivery outright. Neither provides full protection if pct= is below 100, because the policy only applies to the declared percentage of traffic.

How do I check my DKIM key length?

Query your DKIM selector record in DNS — typically something like google._domainkey.yourdomain.com — and decode the p= value from base64 to DER format. A 1024-bit key produces a DER header starting with MIGfMA0GCSqGSIb3DQEBAQUA; a 2048-bit key starts with MIIBIjANBgkq. Google’s current default and recommendation is 2048-bit.

Can a domain pass DKIM and SPF but still be spoofed?

Yes, in two ways. First, if pct= is below 100, DMARC will not act on most failing messages even when SPF and DKIM pass for legitimate mail. Second, a spoofed sender address in the From: header can pass SPF and DKIM checks on the sending infrastructure while misrepresenting the visible sender — exactly what DMARC at full enforcement is designed to catch.

What is the correct order to harden a DMARC policy?

Start at p=none to collect reporting data without affecting mail flow. Move to p=quarantine at a low pct= value to test for false positives, then increase pct= to 100 once delivery looks clean. Finally, promote to p=reject; pct=100 for maximum enforcement. Stopping at a low pct= mid-rollout leaves most spoofed mail unblocked.

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