Vulnerability analysis · DMARC

OpenDMARC queries DNS with the raw UTF-8 From domain instead of its A-label, so no internationalized domain gets a DMARC policy at all [OpenDMARC ≤ 1.4.2, latest release checked 2026-07-30]

Yongzhe Xu, Virginia Tech  ·  yongzhe@vt.edu  ·  2026-07-31

1. Overview

DNS carries no Unicode. A DMARC policy for an internationalized domain can live at one node only, the A-label node, such as _dmarc.xn--mnchen-3ya.example.com. RFC 7489 section 6.6.1 therefore tells the verifier to convert a UTF-8 From domain to its A-label before it queries.

OpenDMARC converts nothing. It sends the query with the raw UTF-8 bytes, gets no answer, and stamps dmarc=none. Any sender on an internationalized domain has its published p=reject or p=quarantine ignored on every OpenDMARC receiver.

2. Analysis

The victim publishes its policy at the only node it can occupy.

_dmarc.xn--mnchen-3ya.example.com.  IN  TXT  "v=DMARC1; p=reject"

Each test sends the same forged, unaligned message: no aligned DKIM, envelope sender bounce@attacker.invalid, SPF -all. Only the spelling of the From domain changes.

Both controls fail correctly, so the U-label spelling is the only variable that flips the verdict. The header OpenDMARC writes shows what happened.

Authentication-Results: receiver.test; dmarc=none (p=none dis=none)
    header.from=münchen.example.com

Two things are wrong in that one header. The policy was abandoned, and the recorded domain is not an A-label, which section 6.6 requires.

One more test locates the defect precisely. Publish the record a second time at the literal raw-UTF-8 node _dmarc.münchen.example.com. OpenDMARC still does not find it. The failure is therefore not a DNS mismatch. OpenDMARC gives up on DMARC for a non-ASCII From rather than normalizing it first.

3. Reproduction

1. Publish the victim's policy at the A-label node.

_dmarc.xn--mnchen-3ya.example.com.  IN  TXT  "v=DMARC1; p=reject"

1. Send one forged message, unsigned, with an unaligned envelope sender.

MAIL FROM:<bounce@attacker.invalid>
RCPT TO:<user@receiver.test>
DATA
From: ceo@münchen.example.com
To: user@receiver.test
Subject: payroll update

...
.

Expected: dmarc=fail, disposition reject.

Observed on OpenDMARC: dmarc=none. The message is delivered.

4. Assessment

One missing conversion produces three separate harms.

• Policy bypass. Any internationalized sending domain has its p=reject or p=quarantine bypassed on OpenDMARC receivers. The attacker pays nothing for it: one forged message, no interaction, no credentials.
• Homoglyph phishing. An attacker registers a look-alike internationalized domain and writes it in U-label form. The verdict is dmarc=none whatever policy that domain publishes.
• Denial of validation. The legitimate direction breaks too. An internationalized domain's own aligned, correctly signed mail is treated as policy-less. A U-label From with a valid A-label DKIM signature yields dmarc=none on OpenDMARC, where Rspamd returns dmarc=pass.

5. Remediation

Run IDNA ToASCII on the extracted Author Domain. Do it before the _dmarc query and before alignment, and write the A-label into the Authentication-Results header, as section 6.6.1 requires.

The conversion has to include UTS-46 mapping, not just punycoding of labels that hold non-ASCII letters. See opendmarc-unicode-dot-bypass for what the narrower version misses.

6. References

• RFC 7489 section 6.6.1 - Extract Author Domain
• RFC 5891 - Internationalized Domain Names in Applications (IDNA): Protocol
• CWE-172: Encoding Error
• OpenDMARC repository