2026년 설정 후 메일이 스팸으로 이동함: SPF, DKIM, DMARC 정렬 디버그

Short answer: inspect one received message and find which authenticated domain aligns with the visible From domain; DMARC passes when an aligned SPF result or an aligned DKIM result passes, but that pass does not guarantee inbox placement.

For a media company moving zones away from a registrar-specific API, I would freeze the intended DNS records, query what is actually published, and test a message from every real sending path before changing enforcement. The deciding constraint is drift between intent and published records. A dashboard that says “SPF, DKIM, and DMARC configured” cannot prove what a recipient evaluated.

Keep those two questions separate: did DMARC pass, and did the mailbox provider place the message in spam? Authentication answers the first. It supplies evidence for the second, not a promise.

What actually aligns when SPF, DKIM, and DMARC are set up?

DMARC does not ask whether three unrelated DNS lookups are green. It compares identifiers from the message and its authentication results. The reference identity is the domain in the RFC5322 From header, the address a reader normally sees. SPF contributes the domain used by its authenticated identifier, commonly visible in received diagnostics as the envelope-from or return-path domain. DKIM contributes the signing domain in the signature's d= tag.

At least one path must both authenticate and align with the visible From domain. An aligned SPF pass is enough for DMARC to pass even if DKIM does not. An aligned DKIM pass is also enough even if SPF does not. Two authentication passes using unrelated domains still fail DMARC alignment.

That last case causes a lot of confusion. Suppose a newsletter visibly comes from editorial.example, the bounce domain is bounce.mailer.example.net, and a valid DKIM signature uses d=mailer.example.net. SPF and DKIM can each pass for example.net, yet neither identifier aligns with editorial.example. The correct repair is to make at least one authenticated path use an organizationally related domain under the sender's control, then publish and test the corresponding record. Adding another unrelated SPF mechanism doesn't solve the comparison.

Alignment can be relaxed or strict. In relaxed mode, DMARC compares organizational domains; strict mode requires an exact domain match. The DMARC record's aspf and adkim tags select those modes, and RFC 7489 defines relaxed alignment as the default. That distinction matters during a zone move because a subdomain may work under relaxed alignment and fail after a strict policy is introduced.

The rule is compact:

Observed result Aligned with visible From? DMARC outcome SPF passes; DKIM fails SPF yes Pass SPF fails; DKIM passes DKIM yes Pass SPF and DKIM pass Neither Fail SPF and DKIM fail No passing path Fail

Read the received message before editing DNS

Start with a message delivered to a mailbox you control. Preserve its full headers and locate the receiver's Authentication-Results field. Record the visible From, the SPF result and identity, every DKIM result and header.d value, and the DMARC result. Do this per receiving system because the result is produced at the receiver, not by the sending dashboard.

Don't start by copying a record from a setup screen.

Headers establish what happened to this message. DNS then explains why. Query the authoritative view of _dmarc.<from-domain>, the DKIM selector at <selector>._domainkey.<signing-domain>, and the relevant SPF domain. During the migration, query through more than one recursive resolver and compare the returned value with the versioned intent in your repository. A stale management UI, a record published in the old zone, or a selector copied beneath the wrong origin can all look correct in configuration while being absent from the public answer. The operational lesson is broader than email: treat the zone file as deployed state, not as a form submission receipt.

This small Python tool turns copied headers into a triage summary. It deliberately does not implement DMARC or parse every Authentication-Results extension; the receiving system already performed that evaluation. Its job is to expose the identifiers worth checking without sending mail or calling a vendor API.

from email import policy from email.parser import BytesParser import re import sys raw_message = sys.stdin.buffer.read() message = BytesParser(policy=policy.default).parsebytes(raw_message) print(f"From: {message.get('From', '<missing>')}") for index, value in enumerate(message.get_all("Authentication-Results", []), start=1): compact = " ".join(str(value).split()) results = re.findall(r"\b(spf|dkim|dmarc)=([a-zA-Z0-9_-]+)", compact) identities = re.findall( r"\b(?:smtp\.mailfrom|header\.d|header\.from)=([^;\s]+)", compact ) print(f"Authentication-Results #{index}") print(" results:", results) print(" identities:", identities) 

Run it against the original message file, not text pasted through an editor that may remove folded headers. If it prints multiple Authentication-Results fields, read the trace carefully — a message can pass through several systems, and a field added by an untrusted hop is not equivalent to the final receiver's assessment.

Debug the branch that failed

If DMARC says fail, reduce the problem to two branches. For SPF, ask which domain the receiver authenticated, whether SPF passed for that identity, and whether that domain aligns with the visible From. For DKIM, ask which signatures survived transit, which d= domains passed, and whether any passing domain aligns. Do not average the results. One aligned passing branch closes the DMARC requirement; neither does not.

Then compare message paths, not just message templates. A media operation may send newsroom alerts, newsletters, account mail, and reporter replies through different infrastructure. One sample from the newsletter platform says nothing about a forwarding path or an application worker. Build a small evaluation corpus with one known message from each path, keep the raw headers, and label the expected visible domain, envelope domain, and signing domain. This is the email equivalent of moving a notebook check into a production eval harness: a repeatable fixture replaces a screenshot and catches drift on the next DNS deployment.

A useful migration gate checks the published DNS answer before a canary send, then checks the received authentication result after it. Record a timestamp, sending path, selector, visible domain, SPF identity, DKIM identity, and DMARC disposition. The harness should fail closed on missing evidence rather than guess. It should also retain the exact headers that produced the decision, because a bare green check is hard to debug after records or selectors change.

Be careful with DMARC policy while investigating. The p tag tells receivers the requested treatment for mail that fails DMARC; it does not make SPF or DKIM align. RFC 7489 defines none, quarantine, and reject, and it also defines aggregate reporting through rua. Reports can reveal which sources use the domain and how receivers evaluated them, but aggregate data is delayed evidence, not a substitute for inspecting a current test message.

No guesswork.

Why can aligned mail still go to spam?

DMARC is an authentication policy, not an inbox-placement standard. A DMARC pass establishes that at least one accepted authentication mechanism aligns with the author domain under the selected mode. It does not claim that the recipient requested the message, that the content is wanted, or that a receiver must put it in the inbox. So once the header shows an aligned pass, stop “fixing DMARC” and move the investigation to the evidence outside this RFC-defined decision.

The clean experiment changes one variable at a time. Send the same stream to controlled recipients, preserve the full received headers, and separate authentication outcome from placement outcome. Compare the affected path with a known-good path under the same domain policy. If both show aligned DMARC passes but placement differs, the DNS alignment hypothesis did not explain the observation. That result is useful; it prevents a team from repeatedly editing records that already satisfy the stated authentication rule.

I'm not sure which non-authentication signal explains a particular spam placement without receiver evidence, and neither a DNS checker nor a sending console can settle it from configuration alone. What would resolve the uncertainty is a controlled sample set, receiver feedback that is actually available to the sender, and a timeline joining DNS publication, message transmission, authentication results, and placement. Your mileage may vary across receiving systems because DMARC permits receivers to apply local policy when handling messages.

The catch is that this method is intentionally narrow. It is suitable for proving or disproving identifier-alignment drift. It is not suitable for declaring that a domain has “good deliverability,” and aggregate reports are not a real-time release signal. Keep a slower reporting loop for discovering unmodeled senders; use received canaries for the deployment gate.

Measure drift before copying the setup

Before adopting this workflow, measure whether it shortens the interval between a DNS change and a trustworthy received result. Track the share of known sending paths represented in the corpus, the share producing at least one aligned pass, the age of the last canary per path, and mismatches between intended and publicly resolved records. Those are operational measurements, not claims about inbox placement.

For the registrar API migration, make the rollback criterion explicit before changing delegation: if the public DMARC record, required SPF identity, or active DKIM selector differs from the reviewed intent, pause message cutover and restore the last known-good zone state. If public records match and canaries show aligned passes, the authentication portion of the move has evidence behind it. Spam placement remains a separate evaluation.

That boundary is the main result. Debug the identifiers the receiver saw, preserve evidence per sending path, and treat published DNS as deployed state. Then leave authentication alone when it has passed and investigate placement with a different experiment.

References

• https://datatracker.ietf.org/doc/html/rfc7489

For further actions, you may consider blocking this person and/or reporting abuse