An internationalised sender can look different in a mail client, a raw header, a DNS tool and an authentication result. A correct investigation explains those representations before deciding that the identities differ.
Do not compare only the text rendered on screen. Keep the raw header and the extracted domain, identify the applicable internationalisation rules and record the DNS form used for policy discovery and identity comparison. A conversion used for evaluation is a different operation from rewriting a signed message.
Separate three parts of the address
A display name is the human-facing label. The mailbox local part is the portion before @. The domain is the portion after @. They have different rules and different roles in authentication.
Internationalised email standards allow supported systems to transport UTF-8 header content and mailbox names using SMTPUTF8. IDNA addresses internationalised domain labels; it does not turn a Unicode mailbox local part into a DNS name.
DMARC's central identity is the Author Domain extracted from From. Changing the spelling of a person's local part does not create a new DMARC alignment mode, and authenticating the domain does not certify the person or the meaning of the display name.
Keep the Unicode and DNS representations together
IDNA distinguishes Unicode U-labels from their ASCII A-label representation. A valid A-label can be recognised by its xn-- prefix, but a prefix alone does not prove that an arbitrary string is a valid encoding. Use an implementation of the applicable IDNA rules rather than a hand-edited substitution.
RFC 9989 Section 5.3.1 requires conversion of a U-label Author Domain to A-label form for further DMARC processing. That means a visually different header and DNS name may represent the same domain. It does not mean that similarly shaped Unicode characters in two unrelated names become equivalent.
The following example is synthetic and uses the reserved .example namespace. No DNS publication, message delivery or receiver result is claimed.
- Item: From mailbox with Unicode domain; Illustrative value: info@bücher.example; Purpose: Raw internationalised header identity
- Item: Corresponding A-label domain; Illustrative value: xn--bcher-kva.example; Purpose: Domain form for the DMARC processing described here
- Item: Direct DMARC lookup name; Illustrative value: _dmarc.xn--bcher-kva.example; Purpose: TXT query for that Author Domain
- Item: Equivalent ASCII-domain mailbox form; Illustrative value: info@xn--bcher-kva.example; Purpose: Same domain representation in ASCII form
- valid passing DKIM identity using that same A-label domain can be compared with the converted Author Domain. If they are identical, the domain comparison can meet strict alignment. A complete DMARC pass still requires a valid applicable policy and a passing aligned authentication path; the conversion itself is not authentication.
Do not apply domain encoding to the local part
Consider a hypothetical mailbox with a Unicode local part at the same internationalised domain. The domain can have an A-label representation, while the local part remains a mailbox identifier governed by internationalised email handling. Applying Punycode to the whole address is the wrong model.
Check SMTPUTF8 support for the actual transport path when the message requires it. A domain written entirely in ASCII A-label form does not, by itself, require SMTPUTF8; other address or header content may still do so. A UTF-8 raw header or non-ASCII mailbox local part introduces a separate transport and parser compatibility question.
Keep these outcomes separate: inability to transport an internationalised message, failure to parse its identity, failure to discover policy and failure of authentication are different stages. A change to a DMARC tag cannot solve all of them.
Preserve signed content during investigation
Retain the original message bytes and relevant signatures. Converting an extracted domain for a comparison does not require replacing the From header in the original message. Rewriting the header and then verifying the modified copy can produce a different signature question.
Record the library or product version performing IDNA and email parsing, its supported standards and the conversion result. Keep any controlled repair as a separate test fixture. Avoid promising that every provider, gateway and client supports the same internationalised workflow without testing that route.
DMARC tag names and defined values continue to follow their specified syntax. Do not translate v=DMARC1 or invent a Unicode-specific policy version. For internationalised report destinations or provider-generated settings, follow the applicable URI, DNS and provider rules rather than assuming that mailbox display support permits arbitrary Unicode in every configuration field.
Separate visual impersonation from alignment
A displayed name can resemble a familiar brand while representing a different underlying domain. IDNA conversion explains domain representation; it is not a judgment that the name is legitimate or that two visually similar names are the same identity.
When reviewing suspicious mail, compare the actual domains and their DNS forms with the approved identity register. Keep display-name and lookalike-domain findings alongside, but separate from, the DMARC result. The authentication-versus-authorisation guide explains why a valid domain result cannot approve message intent.
Keep a reproducible identity record
For a real investigation, retain the displayed sender, raw From field, extracted Unicode domain, validated A-label conversion, policy lookup names, SPF and DKIM identities, trusted receiver results and transport evidence. Redact personal data without destroying the domain representation needed to reproduce the decision.
A useful result can say that two representations mapped to the same domain, or that they were distinct, and show how that affected the actual evaluation. Preserve the conversion and the original message so another reviewer can reach the same conclusion.
Record the conversion without inventing authentication
Written case IDN-01 retains From info@bücher.example and its corresponding domain xn--bcher-kva.example. The mail administrator records the applicable IDNA library/version and preserves the raw message separately. SPF, DKIM verification, SMTPUTF8 negotiation and discovered policy remain unknown in this case. The next step is to collect those observations, not mark the message authenticated because the two domain representations agree. No message or DNS query was executed.