Guide

Email headers

The technical record at the top of every email: who it claims to be from, and a trail of stamps added by the servers that carried it.

Every email has two parts: the body you read, and a block of header fields above it. Some fields are written by the sender’s software (From, To, Subject, Date). Others are added along the way by mail servers — each server that accepts the message adds a Received field, and the recipient’s provider adds its authentication results.

Mail apps hide most of it. To see it, open the message’s “original” or “source” view — the Email Intelligence page explains how for Gmail, Outlook, Apple Mail and others.

Received fields and the trust boundary

Each mail server that accepts a message adds a Received field at the top. Only the ones added by the recipient’s own provider are its observations; earlier ones are the sender side’s claims.

Received fields stack up newest-first: the top one was written by the last server to touch the message, normally your own provider; the bottom one was written first. Reversed, they give the delivery route.

They are not equally trustworthy. Your provider recorded what it saw when it accepted the message from outside — that hand-off is the trust boundary, and the connecting server’s address there is the most reliable outside address in the headers. Every field below the boundary existed before your provider saw the message, so a forger can write anything there. This tool marks the boundary and labels everything beyond it as claimed.

SPF

Sender Policy Framework: a domain lists which servers may send its mail; the receiver checks the connecting server against that list.

SPF lets a domain publish, in DNS, the servers allowed to send mail for it. The receiving server checks the connecting server against the list for the envelope sender (the Return-Path / bounce address) — not the From address you see. That gap is why SPF alone does not stop spoofing.

Results: pass, fail (the domain asks for rejection), softfail (treat with suspicion), neutral, none (no policy), and temporary or permanent errors. Forwarding routinely breaks SPF, because the forwarder is not on the original sender’s list.

DKIM

DomainKeys Identified Mail: a cryptographic signature proving a domain’s owner sent the message and that the signed parts were not altered.

The sending system signs selected headers and the body with a private key; the receiver fetches the public key from DNS (at selector._domainkey.domain) and verifies. A pass shows the signing domain vouched for this exact content.

This tool does not re-verify signatures. Verification needs the exact bytes that were signed, and copying a message out of a mail app changes them, so a re-check here would “fail” honest mail. The verdict shown is the one the receiving server recorded at delivery.

DMARC

The check that ties SPF and DKIM to the From address you actually see — and the domain’s instruction for what to do when it fails.

DMARC passes when SPF or DKIM passes for a domain that matches (“aligns with”) the visible From domain. It is the strongest single sign that the From address was not forged. The domain also publishes a policy — none, quarantine or reject — telling receivers what to do on failure.

A DMARC pass proves who sent a message, not that it is safe: a lookalike domain, a compromised account or a legitimate service abused by a scammer all pass. A DMARC failure is strong evidence the From address is unverified, but mailing lists and forwarding cause honest failures too.

ARC

Authenticated Received Chain: a forwarder or mailing list records the authentication results it saw before it changed the message.

Forwarders and lists modify messages (a footer, a new envelope) and so break SPF and DKIM downstream. ARC lets each intermediary seal what it saw. An ARC pass alongside a DMARC failure usually points to forwarding rather than forgery — if the intermediary is one you trust.

Alignment

Whether the domain SPF or DKIM vouched for matches the From domain. Without alignment, a pass can belong to somebody else’s domain.

A message “From: bank.example” can pass SPF for the envelope domain bulk-sender.example and pass DKIM for bulk-sender.example — neither of which says anything about bank.example. DMARC requires alignment for exactly that reason. Where no DMARC result was recorded, this tool compares the domains itself and says it computed the answer.

Spoofing

Forging the sender: putting someone else’s address or name in the From line, or using a domain built to look like theirs.

Email’s original design lets any sender write any From line. Spoofing takes several forms: forging a real domain exactly (which DMARC with a reject or quarantine policy defeats), registering a lookalike domain (paypa1.example, a Cyrillic letter in place of a Latin one), putting a trusted name in the display name over an unrelated address, or setting a Reply-To so that answers go to the attacker.

Authentication catches the first. The others need a reader — or a tool — to compare names and domains carefully, which is what the sender checks here do.

Time zones and the sender’s clock

The Date line carries the offset the sender’s software was set to. An offset matches several real time zones at any moment, and +0000 usually means a server stamped it.

Mail apps on phones and computers write the Date line from the device’s own clock and time-zone setting, so “−0600” says the device was set six hours behind UTC when the message was written. On a given date that fits several places at once — in October, Alberta (on daylight time) and Saskatchewan (which never changes) are both at −06:00 — so the tool lists every zone that matched at that moment, using the runtime’s time-zone database, and narrows the list only when the header names the zone too (“MDT”).

Webmail and many servers stamp the Date in UTC (+0000) whoever the writer is, so that offset says little. Comparing the Date with the first server’s timestamp shows whether the sender’s clock was accurate, behind or ahead — or whether the message sat in an outbox before it was sent.

Device and software fingerprints

Mail software leaves recognisable traces — in X-Mailer, the Message-ID, the MIME boundary, the name it announces to the server, and default signatures. All of them can be edited or forged.

Apple’s mail apps introduce themselves to servers as “smtpclient.apple” and write “Mime-Version: 1.0 (1.0)” on iPhone; Gmail creates Message-IDs ending “@mail.gmail.com”; Outlook adds a Thread-Index; Thunderbird, Roundcube, PHPMailer and others each format the MIME boundary their own way; and phones often append “Sent from my iPhone”. X-Mailer or User-Agent, when present, names the program and sometimes the operating system version.

None of this is proof: the sender’s software writes all of it, and a forger who copies a real message copies its fingerprints too. The tool shows each clue with its confidence and names a device only when several independent clues agree.

Lookalike domains and punycode

Domains registered to resemble a familiar one — a swapped letter, a digit for a letter, or a character from another alphabet.

Internationalised domain names are stored in an ASCII form beginning “xn--” (punycode). That lets a domain mix in, say, a Cyrillic “а” that renders exactly like a Latin “a”. Other lookalikes swap “rn” for “m”, “1” for “l”, or bolt a brand onto another domain (brand-secure-login.example).

This tool compares domains against a short list of commonly imitated brands. A match is a heuristic: coincidental resemblance exists, and the list is not exhaustive.

Region clues

Hints at roughly where each end of a message is: time zones, language settings, a mail provider’s own note of a country, region codes in server names. Region-level only, and never a person.

Some clues are recorded by a third party and weigh more: Microsoft 365 notes the country of the server that connected to it (CTRY), Microsoft server names carry the region where an organisation’s mail is hosted (CANPRD = Canada), and Amazon’s sending hostnames name their AWS region. Others are conventions — an airport code in a hostname, a country domain — or settings the sender’s software chose: a time-zone offset, an “en-CA” language tag, a regional character set.

Each describes a device, a server or a network, not a person. The tool counts where the clues agree and says how many there are; it never draws a pin, because a region is all they can support. The network lookups add the registration country of the sending network, and — only if a provider is configured — an approximate location for it.

What an IP address can and cannot reveal

An IP address identifies a network connection at a moment in time — usually a mail server, provider, carrier or VPN — never a person or a street address.

From an address, public records can usually tell you the network it belongs to (its Autonomous System and registered organisation), the regional registry that allocated it, whether it has a reverse-DNS name, and whether it is a known Tor exit. A commercial geolocation database can estimate a country and often a region or city.

They cannot tell you who was using it. Mail servers, mobile carriers, offices and VPNs put thousands of people behind shared addresses, and allocations change hands. Only the network operator, under legal process, can link an address and a time to a subscriber. This tool never claims more.

Why the sender’s own IP is usually missing

Most large email providers deliberately leave the sender’s device address out of the message, so the headers show their servers instead.

When someone sends from webmail or a mail app, their provider receives the message from the device and relays it onward. Gmail and many other large providers do not record the device’s address in the message they send, to protect their users from exactly the kind of tracing a header analysis attempts. Some systems — older webmail, some corporate servers — still add an X-Originating-IP field.

So the sending server in the headers is usually the provider’s, and its location tells you where that provider’s data centre is — nothing about the person.

ASN and network registration

An Autonomous System Number identifies the network that announces an address on the internet; registries record who that block is allocated to.

Every routable address belongs to a block announced by an Autonomous System — an ISP, a cloud provider, a large company. Team Cymru publishes a free mapping from address to ASN and AS name, queried here over DNS. The five regional internet registries (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC) publish who each block is registered to, queried here with RDAP — the standard successor to WHOIS.

Registration country is where the block is registered, not where a server sits.

Why geolocation is approximate

IP geolocation is a commercial database’s estimate. Country-level is usually right; city-level often is not; it never locates a person.

Geolocation providers build their databases from registry data, routing, latency measurements and data partners. Accuracy is good at country level, mixed at city level, and the coordinates they return are the centre of an area, not a place. Mobile carriers, VPNs and cloud networks are routinely placed far from the actual user.

This site shows a location only when a provider is configured (IPinfo, via IPINFO_TOKEN), labels it approximate, names the provider, and never draws a pin as if it were a building.

Reverse DNS (PTR)

The hostname an IP address’s owner publishes for it. Established mail servers almost always have one that points back to them.

A PTR record maps an address back to a name, set by whoever controls the address block. For mail servers it should exist and “forward-confirm” — the name should resolve back to the same address. Missing or mismatched reverse DNS is a weak warning sign on a sending server, and normal for home connections.

Tor exit nodes

The last relay of the Tor anonymity network. Traffic from one comes from a user somewhere else entirely.

The Tor Project publishes the list of exit relays. An address on it means the real origin is hidden behind the Tor network. Many people use Tor for legitimate privacy; so do senders who do not want to be traced. Here the whole list is downloaded and checked on our server, so the address you are investigating is not sent to the Tor Project.

Why AI detection is uncertain

No method can reliably tell from text alone whether a person or an AI system wrote it. Patterns can lean one way; they cannot prove authorship.

Language models are trained on human writing and can be prompted, edited or paraphrased into any style; people can write in a polished, formulaic register that resembles default model output. Published detectors misclassify real people’s writing — non-native writers’ most of all — and are easily evaded. Short texts are less informative still.

So the Writing Audit does not detect. It measures features that are really in the text, says which way each one leans, shows the arithmetic and the sentences behind it, and states its limits. No third-party detector is connected, and no number on the page is a probability.

The indicative index

A 5–95 summary of which way the observed features lean. Not a probability, not a percentage of AI-written text, and not calibrated.

Each indicator leans towards template-like (AI-consistent) or personal (human-consistent) writing with a strength from 0 to 1 and a fixed weight. The index is 50 + 45 × tanh((AI-leaning total − human-leaning total) ÷ 3), so it runs from 5 to 95 and never reaches either end — no reading of patterns is certain. It is shown so readers can see the balance of the evidence at a glance; the indicators and their measurements are the substance.

An index of 90 does not mean a 90% chance. It means the measured features lean strongly one way. When paragraphs lean in opposite directions, no index is shown at all, because one number would average two voices.

Sentence-length variation

How much sentence lengths vary. People tend to mix short and long sentences; default model output tends towards an even rhythm.

Measured as the coefficient of variation: the standard deviation of sentence lengths divided by their mean. Higher means more varied. It is one of the more robust single features, and still easily changed by editing, by house style, or by a prompt asking for varied rhythm.

Vocabulary diversity

How many different words the text uses relative to its length, measured over a moving 50-word window so long and short texts compare fairly.

The moving-average type–token ratio (MATTR) counts distinct words in every 50-word window and averages them. It describes the text; it is not used to lean the authorship reading either way, because both people and models span the whole range.

Readability scores

Flesch Reading Ease (0–100, higher is easier) and the Flesch–Kincaid grade, from sentence length and syllables per word.

Both formulas date from the 1940s–70s and measure surface difficulty only: long sentences and long words. They say nothing about clarity of argument, and syllables are estimated, so treat the numbers as a rough guide. They are computed by the same engine as the Programs Text Analyzer.

Interpreting findings responsibly

Every finding is labelled as a fact from your input, a server’s recorded verdict, an external lookup, an inference or model output — weigh them accordingly.

Facts from your input are accurate as written, but a sender can write most of an email. Receiving servers’ verdicts are strong evidence, reported as recorded. External lookups describe the internet as it is now, which may differ from the day the message was sent. Inferences are reasons to look closer, never conclusions. Model-generated text is a second opinion.

An overall assessment is arithmetic over those findings, shown with its rule. A clean result does not make a message safe, and a warning does not make it malicious. When in doubt, contact the supposed sender through a channel you already trust. And never treat a writing audit as proof that someone did or did not use AI: it cannot support an accusation.