Vulnerability analysis · DMARC

The UTS-46 mapping RFC 7489 requires never runs in OpenDMARC, so one look-alike separator in the From domain leaves any ASCII victim's policy unenforced [OpenDMARC ≤ 1.4.2, latest release checked 2026-07-30]

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

1. Overview

RFC 7489 section 6.6.1 carries a MUST: “If the domain is encoded with UTF-8, the domain name MUST be converted to an A-label, as described in Section 2.3 of [IDNA], for further processing.” Inside ToASCII, UTS-46 compatibility and separator mapping run before anything is punycoded.

OpenDMARC runs none of it. Put a Unicode character in the From: domain that NFKC and UTS-46 fold onto the victim's ASCII organizational domain, and what OpenDMARC sees is a domain it has never heard of. The _dmarc lookup finds no record. The verdict is dmarc=none, the victim's p=reject never comes into play, and the forgery reaches the mailbox.

The set of exposed domains is wider than the mechanism suggests. Owners of internationalized domains are not the group at risk. The group at risk is every plain-ASCII DMARC-protected domain, because the crafted From folds down onto the ASCII organizational domain.

2. Analysis

In every row the victim is a plain-ASCII organization publishing p=reject, and the message is forged, unsigned, and out of alignment. The From domain is the only thing that changes.

In the U+FF0E row, the fullwidth bytes come straight back out in the Authentication-Results header OpenDMARC writes. Nothing mapped them at any stage.

Authentication-Results: receiver.test; dmarc=none (p=none dis=none)
    header.from=vic．example．com

Two controls shut off the competing explanations. Both verifiers fail an ASCII-dot From matching the victim organization, which shows the lookup works on both. Both return none for the same compatibility forms when the victim publishes no policy, which leaves the published p=reject as the sole variable the two diverge on. The run was repeated on two fresh random domain suffixes, so neither DNS nor policy caching accounts for the result.

3. Reproduction

1. Under a real registrable suffix, publish a policy for a victim organization.

_dmarc.vic.example.com.  IN  TXT  "v=DMARC1; p=reject; adkim=s; aspf=s"

1. From an unrelated host, send one unsigned message. Its envelope sender belongs to an

unrelated domain, and no DKIM signature aligns with the From domain.

MAIL FROM:<bounce@attacker.invalid>
RCPT TO:<user@receiver.test>
DATA
From: ceo@vic．example．com          <- U+FF0E instead of '.'
To: user@receiver.test
Subject: invoice

...
.

Expected under RFC 7489 section 6.6.1: ToASCII maps U+FF0E to ., the organizational domain comes out as vic.example.com, the policy is found, alignment fails, and the verdict is dmarc=fail with the reject disposition.

Observed on OpenDMARC: dmarc=none, and the message is delivered. Rspamd, given the identical message, returns dmarc=fail.

4. Assessment

The bypass is complete. The target can be any plain-ASCII domain publishing p=reject or p=quarantine, and the receiver can be any deployment running OpenDMARC. The attacker holds no DKIM key, no access to the victim's DNS, and no prior relationship with the victim. The one thing required is a way to send mail, which is no credential at all. On screen, the From: in the recipient's client shows the victim's domain, and the difference surfaces only for a reader who goes down to the individual code points.

Deploying DMARC is the whole of the victim-side precondition. That is what makes this the most broadly exploitable finding in the behavioral group.

5. Remediation

Put the extracted Author Domain through IDNA ToASCII with UTS-46 processing. It has to happen ahead of the _dmarc query and ahead of alignment, which is what RFC 7489 section 6.6.1 calls for.

Half a fix leaves the hole open. A conversion triggered only where a label holds non-ASCII letters covers the related U-label case and misses this one. The characters used here are separators and compatibility forms. They have to go through NFKC and UTS-46 mapping into ASCII before the registrable domain is recognizable at all.

6. Additional notes

opendmarc-ulabel-not-converted reaches the same missing conversion through a different equivalence class. It requires a victim who owns an internationalized domain, and this one requires nothing of the sort, which makes the victim population here strictly larger. A single change closes both.

One negative result belongs in the record. NFC against NFD produces consensus rather than a bug. Give an internationalized victim a policy at the NFC A-label node. Rspamd normalizes an NFD From to NFC and locates the policy, and OpenDMARC fails both forms in the same way. That is the U-label case over again, and it adds no asymmetry.

7. References

• RFC 7489 section 6.6.1 - Extract Author Domain
• RFC 5890 - Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework
• UTS #46: Unicode IDNA Compatibility Processing
• CWE-1289: Improper Validation of Unsafe Equivalence in Input
• OpenDMARC repository