How did he know my sign?
Published 11 Jun 2026
Updated 14 Aug 2026
11 min read
Summarize with
Updated on 14 Aug 2026: We expanded the DKIM verification steps, clarified alignment and multiple signatures, and tightened the troubleshooting advice.
He knew your sign because the clue was already visible. In a Slack thread, a single word such as Gemini can supply the joke before anyone asks the question. A birth date, public profile, or lucky guess can do the same. If this was email authentication, the answer is more literal: an email often carries a DKIM signature, and that signature exposes the signing domain, selector, and authentication result to anyone who can inspect the message headers.
That is the useful technical answer. A reader with access to the headers does not need secret access to identify the signing domain. The message itself contains the DKIM-Signature header. Mailbox providers also add authentication results that say whether DKIM, SPF, and DMARC passed. Suped's product uses the same kind of evidence in aggregate through DMARC monitoring, so teams can see which services are sending mail, which ones are signed correctly, and which ones need fixing.
The short version: he did not read your mind. He either inferred a zodiac sign from context, or he read the email's authentication signs from headers and DNS records.
What a sign means in email
In email, a sign is usually a DKIM signature. DKIM lets a domain attach a cryptographic signature to a message. The receiving server looks up the public key authorized under that signing domain and checks the signature against the signed headers and body hash. A pass means the message verified with that key and the signed content survived in a form allowed by the signature's canonicalization rules.
The signature is not meant to be hidden. It is there so receivers can verify it. Anyone with the raw message can see the signing domain, selector, algorithm, canonicalization mode, body hash, and list of signed headers. Those values do not reveal the private key or prove that the visible From address belongs to the signer.
Shortened DKIM-Signature headertext
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=mail; h=from:to:subject:date; bh=shortened-body-hash; b=shortened-signature;
- Signing domain: The d= tag names the domain responsible for the signature.
- Selector: The s= tag points to the public key location under that domain.
- Algorithm and canonicalization: The a= and c= tags identify the signing algorithm and normalization rules.
- Signed content: The h= tag lists signed headers, bh= holds the body hash, and b= holds the signature.
- DMARC check: DMARC passes when at least one SPF or DKIM result both passes and aligns with the visible From domain.
Four labeled parts showing how a message header connects DKIM, DNS, and DMARC results.
How the receiver verifies a DKIM signature
The receiver does more than confirm that a selector exists. It normalizes the message using the c= rules, hashes the body, and compares that value with bh=. It then retrieves the public key selected by s= and d= and verifies b= across the headers listed in h=.
- Normalize the content: Simple canonicalization tolerates very little change, while relaxed canonicalization tolerates defined whitespace and header formatting changes.
- Check the body hash: A mismatch usually means content changed after signing, including a footer, encoding change, or security-gateway rewrite.
- Retrieve the key: The receiver queries selector._domainkey.signing-domain and follows DNS delegation when the owner uses a CNAME.
- Verify the signature: Current RSA signatures use SHA-256. RSA keys must be at least 1024 bits, and 2048-bit keys are recommended.
One message can contain several DKIM signatures. Review each result separately. For DMARC, one valid signature with an aligned signing domain is enough for the DKIM path to pass, even if another signature fails.
Where the clue came from
The clue can come from the message, DNS, or a mailbox provider's authentication summary. The message header is the strongest starting point because it contains the selector and signing domain used for that specific message. DNS supplies the public key, while the receiver's authentication result records the verification outcome. DMARC reports then show the same patterns across real mail volume, which is more useful than checking one message at a time.
|
|
|
|---|---|---|
DKIM d= | Header | Signing domain |
DKIM s= | Header | Key selector |
SPF | Header and DNS | Envelope sender authentication |
DMARC | Header and DNS | Alignment result and policy |
Auth result | Header | Pass, fail, or error |
Common clues that reveal a sender's email authentication sign.
This is why a single forwarded message can answer a lot of questions. If the raw headers show d=send.example.com, the message claims a signature by that domain. A DKIM pass confirms that the receiver verified it. If DKIM passed but DMARC failed, that valid signing domain probably did not align with the visible From domain, and no aligned SPF result rescued DMARC.
A DKIM pass alone does not prove the visible sender is legitimate. DMARC adds the alignment check that connects a passing SPF or DKIM identity to the address people see in the inbox.
How to verify it yourself
To verify the sign, start with the actual email. Open the original message source, not a screenshot. Search for DKIM-Signature and Authentication-Results. If there are several DKIM signatures, pair each result with its signing domain and selector before comparing the result with DNS.
- Open headers: Use the mailbox's show original or view source option.
- Find DKIM: Copy the d= domain and s= selector for each signature.
- Check DNS: Look up the selector record and confirm that it resolves to the expected public key.
- Read the result: Separate a missing key, body-hash mismatch, unsupported algorithm, and ordinary signature failure.
- Check alignment: Confirm whether a passing d= domain aligns with the visible From domain under relaxed or strict DMARC mode.
For a focused DNS check, use the DKIM checker with the selector and domain from the header. This confirms whether the public key resolves and whether the returned record has valid DKIM syntax. It cannot verify the signature on a specific message or prove that every message from the domain passes DKIM.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
The lookup name follows a strict pattern. The selector comes first, then _domainkey, then the signing domain. If the selector is mail and the signing domain is example.com, the DNS record lives at the name below. Some services publish a CNAME there and host the final key at its target.
DKIM DNS lookup nametext
mail._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIIB..."
Basic DMARC recordtext
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:d@example.com"
Why a guess can look accurate
The phrase sounds like astrology, and that matters because people often blend social clues with technical evidence. If someone says Gemini, another person can call it a sign without knowing anything private. A birth date can support a sun-sign guess, while a Moon or rising sign needs more birth details. If an email header names a signing domain, another person can read it without knowing anything private. Both situations feel like hidden knowledge because the clue was not obvious to everyone watching.
Social clue
A zodiac sun sign can be guessed from a direct hint, a birth date, a public profile, or a comment someone already made. The person guessing still has uncertainty unless the relevant birth details are known.
- Gemini clue: The word itself can trigger the joke.
- Birth date: A public birthday makes the sun sign easy to infer.
Technical clue
A DKIM signature is structured data. The header exposes the signing domain and selector, and the receiver's authentication result records whether that signature passed.
- Header clue: The signing domain is written in the message.
- DNS clue: The public key lets a receiver verify the signature.
The difference is confidence. A zodiac guess can be wrong. A DKIM header directly shows that a message claims a signature by a domain, and the authentication result says whether the receiver verified that claim. DMARC then checks whether at least one passing SPF or DKIM identity aligns with the visible From domain.
What Suped adds to the investigation
Manual header checks work for a single message. An organization also needs to know which services send mail for the domain, whether they sign consistently, whether SPF or DKIM aligns with the visible From domain, and which failures need an owner.
Suped is our product for that workflow. It connects DMARC, SPF, DKIM, hosted SPF, hosted DMARC, hosted MTA-STS, blocklist monitoring (blacklist monitoring), and deliverability signals. Teams can use it to inventory sources, detect authentication issues, route fix steps to an owner, stage policy changes, and receive alerts when sending behavior changes.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For a quick first pass, Suped's public domain health checker checks DMARC, SPF, and DKIM signals together. For ongoing work, the platform connects those checks to real mail sources, so a team can move from p=none to enforcement after identifying legitimate senders and fixing alignment.
Start with source ownership. Each legitimate sender needs a verified owner, a known sending service, working authentication, and an aligned result that protects the visible From domain.
Limits and privacy
Knowing the sign does not mean knowing everything. A DKIM header identifies the signing domain and selector, but it does not expose the private key, the sender's account password, or the full sending system. Public DNS can confirm a specific selector record, but standard DNS does not provide a way to list every selector a domain has published.
Forwarding also changes the evidence. DKIM can survive forwarding when signed content remains compatible with its canonicalization rules. Mailing lists and security gateways sometimes change signed headers or the body, which can break the signature. SPF commonly loses alignment because the forwarder becomes the connecting system. ARC can preserve an intermediary's authenticated account of earlier results, but it does not repair DKIM or make DMARC pass automatically. The final receiver decides how much to trust the ARC chain under its local policy.
Do not treat a visible brand name, display name, or logo as proof. Spoofed mail can show a familiar From name while failing DMARC, or it can pass DKIM with a domain that does not align with the visible From domain.
Records that are public by designtext
example.com TXT "v=spf1 include:mail.example.net -all" _dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:d@example.com"
This boundary gives receivers the public data needed to verify mail while the private signing key stays with the sender. Domain owners receive aggregate authentication reports. The operational risk sits in weak keys, post-signing message changes, missing sender inventory, and records that pass one check without the alignment DMARC requires.
Views from the trenches
Best practices
Read the original headers before judging a sender, because summaries can hide key details.
Compare DKIM, SPF, and DMARC together before deciding that a message is authenticated.
Track jokes and odd reports as prompts to verify data, not as proof of hidden access.
Common pitfalls
Treating a DKIM pass as brand proof creates false confidence when domains do not match.
Checking one message and assuming all future mail uses the same sender path causes gaps.
Looking for DKIM selectors in public DNS without the header wastes time on guesswork.
Expert tips
Use the header for the selector, DNS for the key, and DMARC reports for repeat patterns.
Write down who owns each sender so authentication failures reach the right team quickly.
Use policy staging after inventory work, because enforcement exposes hidden senders fast.
Marketer from Email Geeks says a single word like Gemini can create a convincing sign joke because the context does most of the work.
2026-06-12 - Email Geeks
Marketer from Email Geeks says the question works because sign can mean a horoscope sign or a technical signature, and both depend on visible clues.
2026-06-13 - Email Geeks
The practical answer
He knew your sign because the sign was either part of the conversation or part of the email. In the casual reading, Gemini or a birth date is a sun-sign clue. In the technical reading, DKIM exposes a signing domain and selector in the message header, then DNS and the receiver's authentication results show whether the signature verified.
For one message, inspect the original headers and review every DKIM signature. For a domain, monitor DMARC reports and sending sources over time. Suped's product is built for that second job: finding real senders, explaining authentication failures, alerting on changes, and giving teams the steps to move toward enforcement with fewer surprises.
