Worked example 9 of 11
A look-alike domain with a Cyrillic letter
The attacker registered a domain that looks identical to the real one, with one Cyrillic 'а'. SPF, DKIM and DMARC all pass, for the wrong domain.
What to notice
On screen, the sender looks like billing@exаmplepay.example. In the raw headers it's billing@xn--exmplepay-1yh.example: the punycode form of a domain whose second letter is the Cyrillic а (U+0430), not the Latin a.
The attacker owns that look-alike domain and set it up properly, so SPF, DKIM and DMARC all pass. Authentication proves only that the mail came from the domain in the From address; it can't tell you that the domain is the one you think it is.
MailDingo decodes the punycode and checks every label for mixed scripts (Latin and Cyrillic in one name never happens in a legitimate domain), then reduces the name to its Unicode TR #39 "skeleton" (а → a) and compares it with the other domains in the message. Here the skeleton examplepay.example matches the domain the attacker put in Reply-To to look consistent.
Two smaller tells: the display name ExamplePay Billing was MIME-encoded (=?UTF-8?B?…?=) although it's plain ASCII, which legitimate mail software rarely bothers to do; and Reply-To points at a different organisation from the From address. The emoji in the encoded Subject is common in marketing too and isn't a red flag on its own.
The analysis
Produced by the same code that runs in the analyser.
Suspicious
Warning signs: treat this message as suspicious
MailDingo found 2 serious warning signs. Don't click links, open attachments or reply until you've checked with the sender another way.
- Fromexаmplepay.example
- Sent from192.0.2.230
- Hops2
- In transit1 s
- ViaGoogle
Red flags 4
- HighFrom domain mixes alphabets
The From domain exаmplepay.example mixes latin and cyrillic letters in one name. Real domains almost never do this; it's how look-alike domains imitate familiar ones. Learn more show in headers
- HighFrom domain imitates another domain in this message
The From domain exаmplepay.example looks like examplepay.example but is a different domain. Learn more show in headers
- MediumReplies go to a different domain
Reply-To is billing-support@examplepay.example, so hitting Reply sends your answer to examplepay.example, not to xn--exmplepay-1yh.example. That is normal for some newsletters and help desks, and a favourite trick in invoice and CEO fraud. Learn more show in headers
- LowFrom name is encoded for no reason
The display name was MIME-encoded even though it is plain ASCII text. Legitimate software rarely does this; filter-dodging spam often does. Learn more show in headers
Authentication
Checked by mx.google.com, the server that added the top Authentication-Results field: normally your own provider. show in headers
DMARC DMARC asks: did SPF or DKIM pass for a domain that matches the From address you see? That match is called alignment.
SPF or DKIM passed for a domain that aligns with the visible From domain: the From address is authentic.
domain policy p=none · applied: none
SPF SPF checks whether the server that delivered the message was allowed to send for the envelope (bounce) domain.
The sending server is on the envelope domain's list of permitted senders.
google.com: domain of bounce@xn--exmplepay-1yh.example designates 192.0.2.230 as permitted sender
DKIM DKIM checks a cryptographic signature that a domain (d=) put on the message, proving that domain handled it and the signed parts were not changed.
The signature verified: the signing domain really handled this message and the signed content is unchanged.
Alignment with the From address
- SPF exаmplepay.example passaligned (exact match)
- DKIM exаmplepay.example passaligned (exact match)
At least one passing check is aligned with the From domain, which is all DMARC needs. Alignment is shown in relaxed mode (same organisation); a domain can demand strict mode (exact match) in its DMARC record, which this tool can't look up.
DKIM signatures on the message
- xn--exmplepay-1yh.example selector k1 · rsa-sha256 · signed 2026-10-21 07:14:50 UTC · covers 6 header fields ↧
Who it claims to be from
- From
- ExamplePay Billing
billing@xn--exmplepay-1yh.example↧ - Reply-To
- ExamplePay Billing
billing-support@examplepay.exampledifferent organisation ↧ - Return-Path
bounce@xn--exmplepay-1yh.example↧- Subject
- ⚠️ Payment failed: update your card to keep your subscription (decoded from utf-8) ↧
- Date
- Wed, 21 Oct 2026 07:14:50 +0000 = 2026-10-21 07:14:50 UTC ↧
- Message-ID
<20261021071450.1f2e3d4c@xn--exmplepay-1yh.example>↧- Services seen
- Google (Gmail / Google Workspace) mailbox
Route 2 hops
Oldest first. Each server adds a Received line on top, so this is the header list read from the bottom up. Times are converted to UTC.
- Written Date header: 2026-10-21 07:14:50 UTC (sender's clock +0000)
- +4 smx.google.com Googlefrom mx.xn--exmplepay-1yh.example
192.0.2.2302026-10-21 07:14:54 UTC (−0700 local) ↧Probably where your provider took the message in from the outside world. The IP here was seen by the receiving server, so it is the most trustworthy origin address in the headers. - +1 s2001:db8:4a5:10::2e2026-10-21 07:14:55 UTC (−0700 local) ↧
First to last server: 1 s. Reading delays
The headers 15 fields
sender route authentication ARC
All names, domains and addresses on this page are fictional: domains under example.com/.net/.org and the reserved .example and .test names (RFC 2606, RFC 6761), IPv4 addresses from the documentation ranges in RFC 5737 and IPv6 from 2001:db8::/32 (RFC 3849). Signatures are placeholders and won't verify.