Your team recognizes its domain in Japanese, Arabic, or German. Then an email authentication report shows a name beginning with xn--, and someone flags it as an unfamiliar sender. Before changing any settings, check whether you’re looking at another representation of a domain you already own.
DMARC supports internationalized domain names, or IDNs. A domain appearing in Unicode in one place and Punycode in another doesn’t automatically break authentication or alignment because correctly implemented systems account for those equivalent forms. The work is making sure your DNS records, sending services, and reporting tools handle the domain correctly.
Unicode and Punycode can represent the same domain
Internationalized domain names let organizations use domain labels containing characters beyond the familiar ASCII letters, digits, and hyphens. The IDNA standards, short for Internationalized Domain Names in Applications, define how applications handle those labels.
Two terms help explain what your tools display. A U-label is the valid Unicode form of an internationalized label. An A-label is its ASCII-compatible form, beginning with xn-- and using Punycode encoding. These are equivalent representations when they refer to the same valid IDN label.
For example, the illustrative domain münchen.example has the ASCII form xn--mnchen-3ya.example. The different strings identify the same domain. A visually similar name containing different characters, however, may identify something else entirely.
Keep both verified forms in your domain inventory. Use an IDNA-aware tool or library to compare them, and record the exact domain registered to your organization. Don’t infer equivalence from appearance or assume that every unfamiliar xn-- name belongs to your organization.
DMARC checks the authenticated domain behind the display
DMARC alignment connects an authenticated domain to the domain in a message’s visible From address. A message passes DMARC when at least one of two methods passes with alignment: SPF, which checks an authorized sending source, or DKIM, which verifies a message signature.
SPF normally evaluates the domain in the envelope sender address, often reflected in the delivered message’s Return-Path. DKIM identifies its signing domain in the d= field of the signature. Neither domain automatically matches the address recipients see, which is why alignment needs its own check.
The current DMARC standard requires receivers to convert Unicode labels in the From domain to their A-label form before further processing. A properly handled Unicode From domain and its equivalent Punycode representation therefore don’t become different identities merely because they look different in a dashboard.
The alignment mode still matters. Relaxed alignment requires the domains to share the same DMARC organizational domain while strict alignment requires the same domain, so a parent domain and subdomain won’t qualify as an exact match. Converting an IDN between equivalent forms doesn’t remove that distinction. Check the domain relationship and the configured alignment mode before changing policy.
Publish each authentication record where receivers look for it
An IDN doesn’t change the basic location rules for email authentication records. DMARC, SPF, and DKIM use different inputs to locate their DNS information, so publishing everything at your main domain can leave a sending service unconfigured.
The examples below use münchen.example, represented in DNS lookups as xn--mnchen-3ya.example.
| Record | What determines its location | Illustrative DNS name |
| DMARC | Policy discovery starts with _dmarc followed by the From domain | _dmarc.xn--mnchen-3ya.example |
| SPF | The domain SPF evaluates, such as the envelope sender’s bounce subdomain | bounce.xn--mnchen-3ya.example |
| DKIM | The selector, followed by _domainkey and the signing domain | s1._domainkey.xn--mnchen-3ya.example |
If the From address uses a subdomain, the initial DMARC lookup uses that subdomain. Policy discovery can then identify an applicable parent policy when needed. For DKIM, the table assumes a selector of s1 and a signing domain matching the main example domain—your provider may supply different values or an alias to a hosted key.
Follow your DNS provider’s instructions for entering record names. Some interfaces accept Unicode and convert it; others expect the A-label or a name relative to the zone. Domain references inside an SPF record must use A-labels, as specified in the SPF standard. Verify the published result through a DNS lookup instead of relying only on the control panel’s display.
Check email address support separately from domain support
A provider accepting an internationalized domain doesn’t necessarily support every form of internationalized email address. The domain after the @ sign and the mailbox name before it have different requirements.
The SMTPUTF8 extension enables non-ASCII addresses and internationalized message headers during email transport. A domain written entirely in its ASCII form, paired with an ASCII mailbox name, doesn’t by itself require SMTPUTF8. Transmitting the domain as Unicode in an address or using a non-ASCII mailbox name introduces additional compatibility requirements. Punycode conversion applies to domain labels, not the mailbox name before @.
DKIM also has rules for internationalized headers. The internationalized email authentication specification allows Unicode domain labels in that context, while retaining support for A-labels. A blanket instruction to force every field into Punycode misses those distinctions.
Ask your sending provider which address and header formats it supports. Test the actual message it produces, including replies and bounce handling, before launching a campaign. A successful website lookup doesn’t establish that the email path supports the address you intend to use.
Diagnose the failure before changing the spelling
Suppose a retailer sends from münchen.example through a marketing platform. The platform uses its own unrelated domain for the envelope sender and signs with that same vendor domain. SPF and DKIM may both pass, but neither result aligns with the retailer’s From domain. DMARC fails because the authenticated identity belongs to the vendor.
Changing how a dashboard displays münchen.example won’t resolve that failure. The retailer needs an aligned authentication method, such as provider-supported DKIM signing with its domain. Valimail’s guide to SPF and DKIM alignment explains this distinction between passing authentication and passing DMARC.
A different failure calls for a different fix. If the signature names the correct domain but the public key isn’t available at the expected selector, check the DNS publication and provider setup. If DNS and authentication check out but a reporting tool separates equivalent domain forms, investigate the tool’s handling of IDNs.
Keep an original test message and the receiver’s authentication results for the investigation. Compare converted copies of domain names for analysis. Don’t rewrite a signed message’s headers to make the strings look consistent, because changing signed content can invalidate DKIM.
Read xn-- domains in reports without losing the context
DMARC aggregate reports contain information about message volumes, authentication results, and policy handling. IDN domain fields may appear in ASCII form, and reporting interfaces may present them differently from your domain inventory.
Before labeling an entry unfamiliar, compare its domain with your inventory using equivalent IDNA forms. Keep the original value available alongside the readable version so another administrator can reproduce the check. This also helps you spot an actual different domain that happens to resemble yours.
Then examine the result in context: which source sent the messages, which domain SPF checked, which domain DKIM authenticated, and whether either aligned. Recognizing your domain doesn’t establish that the sending source was authorized. Likewise, an xn-- prefix doesn’t establish that a source was malicious.
If your reporting tool groups equivalent forms separately, confirm how it calculates totals before drawing conclusions about pass rates. Investigate the underlying records and message counts rather than assuming that two displayed names mean two independent mail streams.
Test the full sending workflow before enforcing policy
An IDN rollout needs checks across the services the business actually uses. A correctly published record is useful evidence, but it doesn’t prove that every campaign, invoice, or support reply uses the expected authentication settings.
Work through these checks with each service owner:
- Confirm the domain and supported formats. Record the verified Unicode and A-label forms, relevant subdomains, and provider requirements for domain entry and internationalized addresses.
- Verify published DNS records. Check the DMARC lookup location, the domain used for SPF, and the public key location identified by each DKIM selector.
- Send representative messages. Include marketing, transactional, and support mail. Use receiving systems that reflect your audience and inspect their authentication results, including the domains they evaluated.
- Investigate failures by cause. Separate missing or invalid records, unaligned vendor domains, address compatibility problems, and reporting display differences. Assign the fix to the team that controls the affected setting.
- Review enforcement readiness. Include infrequent senders before moving toward quarantine or reject. Continue checking results after provider changes, new campaigns, and DKIM key updates.
Avoid using a single overall pass rate as your approval criterion—keep in mind that something like a low-volume billing service can matter more to the business than its share of total email suggests. Confirm the important sending paths individually and document who will maintain them.
Lookalike domains need separate attention
Internationalized domains can create a visual deception risk when different characters look alike. In an IDN homograph attack, an attacker uses that resemblance to make a separate domain look familiar. Valimail’s guidance on URL phishing and homograph attacks explains how deceptive domains can mislead recipients.
DMARC evaluates domain identity, not visual resemblance. A lookalike can publish its own authentication records and send mail that passes DMARC for that lookalike domain. Your policy doesn’t control a separately registered domain, even when a recipient struggles to tell the two apart.
Keep your legitimate IDNs authenticated and review confusing registrations separately. For sensitive activities such as payment changes, use verification procedures that don’t rely solely on a familiar-looking sender name or address. Treat exact domain comparison as part of the investigation whenever appearance creates uncertainty.
Check your IDN’s published configuration with Valimail
Valimail’s free DMARC checker supports internationalized domain names and converts them to Punycode for DNS lookups. It provides a useful starting point for checking what your domain publishes before you investigate individual sending services.
Use the results alongside test messages and authentication reports. A record check can’t establish that every sender aligns or that every receiver supports your address format. Check your domain with Valimail to review the published configuration, then resolve any sender-specific issues before strengthening your policy.
FAQs
Does DMARC support internationalized domain names?
Yes. DMARC supports IDNs and requires Unicode labels in the From domain to be converted to A-labels before further processing. A message still needs a passing, aligned SPF or DKIM result. Equivalent Unicode and Punycode forms don’t inherently cause an alignment failure.
Should I use Unicode or Punycode in DNS settings?
Follow your DNS provider’s input requirements and verify the published records using the domain’s A-label form. Some interfaces convert Unicode automatically. Domain references inside SPF records must use A-labels. Apply the documented requirements for each field instead of assuming every interface accepts the same input.
Why does my domain appear as xn-- in a DMARC report?
The prefix identifies an ASCII-compatible IDN label. It may be the encoded form of a domain you recognize in Unicode. Compare the complete domain with your verified inventory before deciding whether it belongs to your organization. The prefix alone doesn’t establish ownership or sender legitimacy.
Can a Unicode From domain align with a Punycode DKIM domain?
Yes. Equivalent Unicode and A-label representations can align when the DKIM signature verifies and the domains satisfy the configured alignment mode. Strict mode requires the same domain; relaxed mode requires the same DMARC organizational domain. A genuinely different vendor domain won’t align merely because its signature passes.
Does DMARC stop attackers from using lookalike IDNs?
DMARC doesn’t prevent an attacker from using a separately registered domain that resembles yours. That domain can authenticate its own mail successfully. Enforce authentication on domains you control, and address lookalike abuse through additional detection, reporting, and verification practices.
