If Your DMARC Starts with p=none, Spoofers Already Know You Won’t Stop Them

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS policy record that tells receiving mail servers what to do when an email fails SPF or DKIM checks — but only if the policy value is set to quarantine or reject; a p=none policy instructs receivers to do nothing, making the record cosmetically present and operationally inert.

Three records, one false sense of security

The DNS panel for savyx.kr showed three TXT records on a direct dns.google query run on September 4, 2026:

The panel reads as “complete.” Three records, all syntactically valid, MX resolving to SMTP.GOOGLE.COM. From a checklist perspective, every box has a tick. From a security perspective, one record does nothing and another is understrength. The distinction is invisible until you read the policy values.

What p=none actually instructs receivers to do

The DMARC spec has three enforcement options: p=none, p=quarantine, and p=reject. Each tells the receiving mail server what to do when an incoming message claims to be from your domain but fails authentication.

• p=reject — block the message entirely
• p=quarantine — route to spam
• p=none — deliver normally and send a report

A p=none policy is a logging statement, not a security control. The savyx.kr _dmarc record instructs every mail server in the world to deliver spoofed messages to recipients and optionally email a report to jknam@savyx.kr. The rua address receives the report. Recipients receive the spoofed mail. Nothing is blocked.

This is the gap that makes a “complete” DNS panel misleading. DMARC enforcement is not measured by record presence — it is measured by the policy value inside the record.

The 1024-bit DKIM problem sitting next to it

The google._domainkey record exists and is active. The measured DER encoding is 162 bytes, with a header beginning MIGfMA0GCSqGSIb3DQEBAQUA — the fingerprint of a 1024-bit RSA key.

Google’s current default and recommendation is 2048-bit. A 2048-bit key produces a DER header beginning MIIBIjANBgkq…. The difference is not cosmetic: 1024-bit RSA keys are within the documented reach of factoring attacks, and several certificate authorities no longer issue them for this reason.

The practical implication: even if DMARC were upgraded to p=reject, the DKIM signature it would validate is the weaker of the two key sizes Google itself supports. SPF, by contrast, passed cleanly — v=spf1 ip4:119.205.197.74 include:_spf.google.com ~all — and is not the vulnerability here.

Why this configuration pattern is common

p=none is the correct starting point for DMARC deployment. Google, Cloudflare, and DMARC specification documents all recommend beginning with p=none to collect aggregate reports (rua) for two to four weeks before tightening policy. The error is not starting at p=none — it is staying there.

The pattern emerges because the monitoring phase has no natural end state. There is no alert, no expiry, no automated escalation. Whoever set up the record moves on. The rua inbox fills with XML reports that few people read. Months or years later, the record still says p=none, the DNS panel still shows three records, and the domain looks protected to anyone who does not read policy values.

This is not a misconfiguration in the traditional sense — it is a completed step that was never followed through. The historical analogy is a smoke detector installed without a battery: the installation checklist is satisfied; the protection is not.

The enforcement sequence that actually closes the gap

Moving from a monitoring-only DMARC to an enforced one is a staged process with a specific success criterion at each step.

Step 1 — Read two to four weeks of rua reports. The aggregate reports identify every source sending mail as your domain. Legitimate senders that are not covered by SPF or DKIM will fail authentication and get blocked when policy tightens. Common sources: transactional email platforms, CRM tools, ticketing systems. Identify all of them before changing policy.

Step 2 — Add or authorize missing senders. Update SPF includes or rotate DKIM keys for any legitimate third-party sender that does not currently pass. Success criterion: rua reports show authentication pass rate above 95% for mail you recognize as legitimate.

Step 3 — Move to p=quarantine; pct=10. The pct tag applies the policy to a percentage of failing messages. Start at 10%, watch rua reports for the next week. Legitimate mail that breaks means a sender was missed in Step 1 — fix it before proceeding.

Step 4 — Escalate pct to 100, then move to p=reject. Increment pct in steps (25, 50, 100) with at least a week between each. Once pct=100 is stable at quarantine, move to p=reject.

Step 5 — Rotate the DKIM key to 2048-bit. In Google Workspace, this means generating a new key in the Admin Console under Apps → Google Workspace → Gmail → Authenticate email. The new key begins MIIBIjANBgkq…. DNS propagation takes up to 48 hours; run both keys in parallel if the panel supports it, then remove the 1024-bit record.

The quit criterion for this sequence: if rua reports show a legitimate sending source you cannot identify or authorize after two weeks of investigation, stop and audit outbound mail flows before tightening policy further.

What the DMARC record should look like at the end

The current savyx.kr _dmarc record:
v=DMARC1; p=none; rua=mailto:jknam@savyx.kr

A fully enforced record, after completing the staged sequence:
v=DMARC1; p=reject; rua=mailto:jknam@savyx.kr; adkim=s; aspf=s

The adkim=s and aspf=s tags set strict alignment, meaning the domain in the From header must exactly match the DKIM signing domain and SPF domain. Relaxed alignment (r, the default) permits subdomain matching, which widens the attack surface slightly.

The decision this knowledge enables

Three DNS records confirm the infrastructure is partially built. They do not confirm it is protecting anyone. The savyx.kr measurements show a domain where SPF is correctly configured, DKIM is present but undersized, and DMARC is collecting data it is not using to block anything.

For any domain in this state, the decision is binary: run the staged enforcement sequence, or accept that the domain can be spoofed without technical resistance. Monitoring-only DMARC produces reports that describe the spoofing after it reaches inboxes. The rua address receives the log; recipients receive the email. That is not a security posture — it is a paper trail.

Looking for more on ai & digital income? Visit SAVYX

Frequently Asked Questions

Does having a DMARC TXT record in DNS mean my domain is protected from spoofing?

Not automatically. A DMARC record with p=none monitors authentication failures and sends reports, but instructs mail servers to deliver failing messages normally. Protection only activates at p=quarantine or p=reject. A record’s presence in DNS does not indicate its enforcement level.

What is the difference between DMARC p=none, p=quarantine, and p=reject?

p=none delivers all mail and optionally sends aggregate reports to the rua address — no messages are blocked. p=quarantine routes failing messages to spam. p=reject instructs receivers to drop failing messages entirely. Each step increases enforcement; the common error is never advancing past p=none.

Is a 1024-bit DKIM key a security risk?

Google’s current default and recommendation is 2048-bit RSA for DKIM. A 1024-bit key is technically within the documented reach of modern factoring methods, and multiple certificate authorities have deprecated it. A DER header starting with MIGfMA0 indicates 1024-bit; MIIBIjAN indicates 2048-bit.

How long should I stay on p=none before tightening DMARC policy?

Two to four weeks is the standard guidance for reading aggregate rua reports and identifying all legitimate sending sources. The success criterion before moving to p=quarantine is an authentication pass rate above 95% for recognized legitimate mail. Staying on p=none beyond this window provides no additional safety and leaves the domain unprotected indefinitely.

Can SPF passing mean my domain is safe even if DMARC is set to p=none?

No. SPF confirms that a sending IP is authorized, but DMARC is what instructs receiving servers to act on an authentication failure. With p=none, even a message that fails both SPF and DKIM alignment is delivered to the recipient. DMARC enforcement is the mechanism that connects authentication results to delivery decisions.

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