Green Checkmarks on Every Auth Test — Your Cold Email Still Vanished

Email authentication is a three-layer protocol stack — SPF (sender IP permission), DKIM (cryptographic signature), and DMARC (policy enforcement) — designed to prove a message is legitimately from the domain it claims, but passing all three does not guarantee inbox placement.

The moment the checkmarks lied

On 2026-09-04, a live email sent from jknam@savyx.kr to a Gmail address produced a raw header that read: dkim=pass, spf=pass, dmarc=pass. Every authentication layer cleared. By the logic most deliverability guides sell, that email should have had a clean path to the inbox.

It didn’t — because passing authentication and earning inbox trust are two different problems.

The header data is exact: Authentication-Results: mx.google.com; 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. Three green lights. One fragile foundation underneath.

What the DNS records actually said

A direct dns.google query on the same date exposed two structural weaknesses invisible from the surface.

Weakness one: the DKIM key is 1024 bits. The DER-encoded public key retrieved was 162 bytes, beginning with MIGfMA0GCSqGSIb3DQEBAQUA — the signature of a 1024-bit RSA key. A 2048-bit key, which is Google’s current recommendation and default for new setups, begins with MIIBIjANBgkq… and produces a 294-byte DER. The gap matters: 1024-bit keys sit inside the range cryptographic research increasingly treats as marginal. Spam filters weigh key strength; a shorter key is a quiet trust signal moving in the wrong direction.

Weakness two: DMARC policy is p=none. The live record read: v=DMARC1; p=none; rua=mailto:jknam@savyx.kr. A p=none policy instructs every receiving mail server to do exactly nothing when a DMARC check fails. It collects reports — the rua address — but it does not quarantine, it does not reject. The policy is monitoring mode, not enforcement mode. The dmarc=pass in the authentication header showed the check ran; the p=none meant the policy produced no protective action regardless of outcome.

The SPF record was clean: v=spf1 ip4:119.205.197.74 include:_spf.google.com ~all. MX pointed to SMTP.GOOGLE.COM. The sending infrastructure was properly set up. The vulnerabilities were in configuration choices, not in the infrastructure itself.

Why this gap exists — and who it costs most

The authentication protocol stack was designed to answer one question: is this message really from this domain? It was never designed to answer: is this sender trustworthy? Those are related questions, not the same one.

Spam filters — Gmail’s included — run dozens of signals in parallel. Authentication is an entry fee, not a ranking factor. A domain that passes all three checks but carries a short DKIM key, a non-enforcing DMARC policy, a young sending history, or a low engagement rate on previous sends will score lower than a domain whose authentication is weaker on paper but whose reputation signals are strong.

The cost lands hardest on cold email senders. Transactional email — receipts, password resets, notifications — goes to people who expect it, open it, and don’t mark it as spam. Cold outreach goes to people who didn’t ask for it, may not recognize the sender, and have the marking option one click away. For cold email, reputation is built slowly from zero, and every technical shortcut accelerates the trip to the spam folder.

The decision sequence that fixes this

Authentication problems have a repair order. Work through it once, then leave it.

Step 1: Rotate the DKIM key to 2048 bits. Generate a new key pair, publish the 2048-bit public key in DNS under the selector, update your sending provider to sign with the new private key, and after propagation confirm with a dns.google lookup that the DER is approximately 294 bytes and starts with MIIBIjANBgkq. The 1024-bit key continues working until you deactivate it — there is no breakage during the transition window.

Step 2: Move DMARC to p=quarantine, then p=reject. Start with p=none only if the domain has no sending history and you need to observe the rua reports for two to four weeks to confirm no legitimate sources are failing. For a domain with established sending infrastructure — where SPF and DKIM are already passing — there is no reason to stay in monitoring mode. Move to p=quarantine immediately, watch for report anomalies for one to two weeks, then advance to p=reject. p=reject tells every receiving server to drop messages that fail, which converts DMARC from a passive observer into an active reputation signal.

Step 3: Audit engagement before scaling volume. Authentication repairs are infrastructure; reputation is behavioral. If previous sends accumulated low open rates or spam marks, warming a new sending subdomain — separate from the root domain — isolates that history. Cold outreach from a subdomain (mail.savyx.kr, not savyx.kr) keeps the root domain’s reputation clean even if a campaign performs poorly.

The scorecard

The broader pattern

Cold email deliverability discussions tend to collapse into two camps: “authentication is everything” and “content is everything.” The header data from this capture makes the more useful point — authentication is the floor, not the ceiling. You can pass every formal check and still carry signals that route you to spam.

For anyone who depends on outbound email to generate income or client contact, this is a cost worth measuring precisely. The repair sequence above takes under an hour. The alternative is a technically perfect email that a filter quietly reclassifies before anyone reads it.

One line in a header — p=none — is doing more damage to cold email deliverability than most senders realize, because it never shows up as a failure. It shows up as silence.

Looking for more on ai & digital income? Visit SAVYX

Frequently Asked Questions

Can an email pass DKIM, SPF, and DMARC and still go to spam?

Yes. Authentication confirms the message is legitimately from the claimed domain — it does not determine inbox placement. Spam filters weigh dozens of additional signals including sending reputation, engagement history, and key strength. A live header capture on 2026-09-04 confirmed exactly this scenario.

What is wrong with a 1024-bit DKIM key?

A 1024-bit RSA key falls below Google’s current recommended and default key length of 2048 bits. Cryptographic research treats 1024-bit keys as increasingly marginal, and some receiving mail servers factor key strength into trust scoring. Rotating to 2048 bits is a one-time infrastructure fix with no sending downtime.

What does DMARC p=none actually do?

It instructs every receiving mail server to take no action when a message fails a DMARC check. The policy collects reports to the rua address but neither quarantines nor rejects failing messages. A p=none record means DMARC is in monitoring mode only, providing no active protection and no enforcement signal to receiving servers.

How do I check my own DKIM key length?

Query dns.google for your DKIM selector record (for example, google._domainkey.yourdomain.com) and examine the DER-encoded public key. A 2048-bit key produces approximately 294 bytes and begins with MIIBIjANBgkq. A 1024-bit key produces approximately 162 bytes and begins with MIGfMA0GCSqG.

Should cold email use a subdomain instead of the root domain?

Sending cold outreach from a subdomain (such as mail.yourdomain.com) isolates that campaign’s reputation from the root domain. If a cold campaign generates spam complaints or low engagement, the root domain’s sending reputation remains unaffected — which matters most for transactional and high-value email that must reach the inbox.

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