Common IDN/Punycode mistakes in SPF, DKIM, and DMARC records

tutorialdmarc

Internationalized domain names are where otherwise careful email-auth setups get tripped by representation details.

The domain is valid. The DNS zone exists. The sender can even be signing and publishing the right policy. But one system is handling the domain as Unicode, another expects the ASCII A-label form, and a third silently normalizes or rejects it. The result is often confusing: SPF looks missing, DKIM keys seem unpublished, or DMARC alignment fails even though the team is sure it used the same domain everywhere.

The short version is simple: DNS still stores the relevant email-auth data in ASCII, and the ASCII form for an internationalized label is the A-label, such as xn--bcher-kva.example.

The human-readable Unicode form, such as bücher.example, is the U-label. Both refer to the same IDN, but they are not interchangeable in every step of SPF, DKIM, and DMARC handling.

What changes and what does not

RFC 5890 defines the key IDNA terms:

  • a U-label is the Unicode form shown to people
  • an A-label is the ASCII-compatible encoded form beginning with xn--

For email authentication, the practical rule comes from RFC 8616:

  • strings stored in DNS records remain ASCII
  • when a mail header or SMTP command contains U-labels, implementations convert them to A-labels before DNS lookups for SPF or DMARC
  • DKIM key records in DNS still use ASCII owner names as well

That means the place administrators make mistakes is usually not the existence of the IDN itself. It is which representation they used at each step.

Mistake 1: Publishing the DNS owner name in Unicode where the DNS tool expects ASCII

This is the most common one.

Suppose the visible domain is bücher.example. The DNS owner names involved in email auth are still the ASCII A-label forms:

  • SPF at xn--bcher-kva.example
  • DMARC at _dmarc.xn--bcher-kva.example
  • DKIM key at selector1._domainkey.xn--bcher-kva.example

Some DNS providers accept the Unicode form in their UI and convert it correctly. Some require the ASCII form. Some accept Unicode in one field but not another. If the portal does not convert consistently, you can end up publishing the record under the wrong owner name or failing to publish it at all.

Bad mental model:

Publish DMARC at: _dmarc.bücher.example

Safer mental model:

Actual DNS owner name looked up by receivers:
_dmarc.xn--bcher-kva.example

If a validation tool says your DMARC record is missing, check the exact queried owner name before assuming the TXT content is wrong.

Mistake 2: Mixing U-labels and A-labels across different SPF references

SPF records themselves are ASCII TXT data. RFC 7208 already requires the character content of SPF records to be US-ASCII, and RFC 8616 keeps that rule.

So if an SPF record references another domain using include:, redirect=, a:, mx:, or exists:, the domain that ends up in DNS lookups must ultimately be an A-label form.

Typical failure patterns are:

  • copying include:bücher.example from a dashboard that displays Unicode
  • hand-editing an SPF record with Unicode labels that the DNS host stores literally or rejects
  • validating one representation in a UI while the receiving system queries the other

Safer example:

v=spf1 include:xn--bcher-kva.example -all

The same caution applies to the envelope sender domain used for SPF evaluation. In internationalized mail, MAIL FROM can contain U-labels, but RFC 8616 says those labels must be converted to A-labels before SPF validation.

If one component logs bücher.example and another logs xn--bcher-kva.example, that is not automatically a mismatch. It may be the same domain shown at two different stages.

Mistake 3: Using Unicode directly in DKIM DNS owner names or key records

DKIM creates two separate places where teams get confused:

  1. the DNS owner name for the key record
  2. the d= value in the signature header

For the DNS record, the lookup target is still ASCII in DNS:

selector1._domainkey.xn--bcher-kva.example

For the signature itself, RFC 6376 originally required IDNs in d=, i=, and s= to use A-labels. RFC 8616 relaxes that for internationalized message headers, where U-labels are preferred and A-labels remain valid.

That means modern internationalized mail can legitimately show a Unicode domain in DKIM-related header values, while the DNS key lookup still resolves against the ASCII owner name.

The operational mistake is assuming that because the header showed Unicode, the DNS zone should also be published in Unicode.

It should not. The DNS lookup path still needs the A-label form.

Mistake 4: Expecting DMARC policy discovery to use the Unicode From: domain literally in DNS

DMARC is tied to the visible RFC 5322 From: domain. That part is familiar.

What trips people up with IDNs is the discovery step. If a message shows:

From: alerts@bücher.example

the DMARC policy lookup is not literally a Unicode DNS query for _dmarc.bücher.example. Per RFC 8616, U-labels are converted to A-labels before further DMARC processing.

So the relevant policy record is looked up at:

_dmarc.xn--bcher-kva.example

This matters for two reasons:

  • your DNS publication has to be under the A-label owner name
  • your validation tooling has to show which exact owner name was queried

If a DMARC checker says "record not found", but the provider UI shows one present, compare the precise DNS name queried by the checker with the owner name actually published.

That same exactness matters when debugging common DMARC record mistakes that silently break enforcement. With IDNs, the owner name is often the hidden source of the problem rather than the DMARC tags themselves.

Mistake 5: Forgetting that rua and ruf style destinations in DMARC records are still conventional ASCII mailboxes

This corner case gets overlooked during multilingual rollouts.

Many teams stay with rua aggregate reporting and skip ruf failure-report mail entirely. That keeps reporting more privacy-friendly and operationally simpler, which matches how most modern DMARC programs run.

RFC 8616 updates DMARC processing for internationalized domains, but it also states that addresses inside DMARC policy records, such as reporting addresses, still have to be conventional, not internationalized, addresses.

So a reporting destination should stay in an ASCII-address form such as:

rua=mailto:dmarc-reports@example.net

not an SMTPUTF8 mailbox local-part or an internationalized mailbox domain.

Even when the protected domain is internationalized, the DMARC record content remains conservative ASCII DNS data.

Mistake 6: Treating lookalike-domain risk as the same thing as IDN formatting correctness

These are related, but they are not the same problem.

An IDN can be perfectly valid and correctly punycoded while still being visually confusing to humans. Google explicitly tells senders to format several internationalized domains according to Section 5.2 of Unicode Technical Standard #39, including authenticating domains, envelope-from domains, payload domains, reply-to domains, and sender domains.

That is a sender-quality and anti-abuse concern, not just a DNS syntax concern.

So there are really two checks to perform:

  1. does the domain convert cleanly and consistently between U-label and A-label forms?
  2. is the chosen IDN safe and unsurprising enough for users and large receivers?

That second question overlaps with the issues covered in domain lookalike/homograph defense for email. Correct punycode does not eliminate homograph risk.

Mistake 7: Trusting only the DNS provider UI instead of the queried result

Provider dashboards often show the pretty form of the domain. Receivers and validators care about the queried result.

For IDN troubleshooting, the provider UI is not enough evidence. Always confirm the live DNS answer for the exact A-label owner name.

For example, validate these separately:

  • base domain TXT at xn--bcher-kva.example
  • DMARC TXT at _dmarc.xn--bcher-kva.example
  • DKIM TXT at selector1._domainkey.xn--bcher-kva.example

This is the same habit that helps with DKIM DNS gotchas: splitting long TXT records, quoting rules, and how to verify the published key. With IDNs, the verification target itself is easy to get wrong.

A practical validation workflow

Here is the most reliable way to validate an internationalized sending domain before blaming SPF, DKIM, or DMARC logic.

1. Start with both forms written down

Document both:

  • U-label: bücher.example
  • A-label: xn--bcher-kva.example

Do not rely on memory or on a portal's automatic display conversion.

Keep the Unicode form for human review and the A-label form for DNS verification notes. Most operational confusion happens when people mention only one form in tickets and screenshots.

2. Publish and verify owner names using the A-label form

Confirm that the live DNS owner names match these shapes:

  • SPF: xn--bcher-kva.example
  • DMARC: _dmarc.xn--bcher-kva.example
  • DKIM: <selector>._domainkey.xn--bcher-kva.example

If your provider UI displays Unicode, that is fine, but the queried name still needs to resolve correctly in ASCII form.

3. Verify record content is still ASCII-safe where required

Check that:

  • SPF TXT content is ASCII-only
  • DMARC TXT content is ASCII-only
  • reporting addresses inside DMARC are conventional ASCII addresses
  • DKIM DNS record content is valid ASCII TXT data

If a UI lets you paste Unicode into SPF or DMARC TXT content, that does not mean receivers will interpret it the way you expect.

4. Test mail flow with the exact header and envelope identities you plan to use

Internationalized mail can show Unicode in visible addresses and, in some cases, DKIM-related header values. The receiver-side authentication process may still normalize those domains to A-labels for lookups.

So the test should capture:

  • the displayed From: domain
  • the SMTP envelope sender domain
  • the DKIM d= domain
  • the exact DNS names queried during verification, if your tooling exposes them

5. Compare by equivalence, not by string appearance alone

bücher.example and xn--bcher-kva.example can represent the same domain.

What matters is whether the implementation converted them consistently at the right step. If one tool says SPF passed for the A-label while another shows the U-label in logs, the next question is whether those are equivalent forms of the same IDN, not whether the strings look identical.

A small checklist for each protocol

SPF

  • publish the SPF TXT record under the A-label owner name
  • keep SPF record content ASCII-only
  • convert any referenced IDN domains to their A-label forms before publishing
  • remember that internationalized MAIL FROM domains are converted to A-labels for SPF evaluation

DKIM

  • publish selector records under the ASCII owner name
  • verify the exact lookup target is <selector>._domainkey.<A-label domain>
  • do not assume a Unicode d= display means the DNS record should also be Unicode

DMARC

  • publish the policy at _dmarc.<A-label domain>
  • remember the visible From: domain may be shown as Unicode but converted to A-labels before policy discovery and alignment processing
  • keep DMARC record mailbox destinations conventional ASCII addresses

Bottom line

The most expensive IDN email-auth mistakes are usually not about misunderstanding SPF, DKIM, or DMARC themselves. They are about forgetting that the same domain may appear in Unicode for people and in A-label form for DNS-driven processing.

If an internationalized domain is involved, validate three things every time:

  1. the Unicode form is the intended domain
  2. the A-label form is the one actually published and queried in DNS
  3. the mail flow and validation tools treat those two forms as equivalent at the right stages

Once that discipline is in place, most "mysterious" IDN authentication failures stop looking mysterious and start looking like normal DNS hygiene.

Previous Post