A message lands in the inbox of someone at your company, claims to be from the CEO, and asks for a wire transfer. Before anyone decides whether it is real, someone has to read the headers. This post explains what SPF, DKIM and DMARC actually check, what their results do and do not prove, and how mailin surfaces those results from an exported message without sending anything off your Mac.
What SPF, DKIM and DMARC check
The three mechanisms answer three different questions.
SPF (Sender Policy Framework) is a DNS record in which a domain owner lists the servers allowed to send mail on that domain's behalf. When a receiving server gets a message, it looks at the domain in the envelope sender and checks whether the connecting server's IP address is on that list.
DKIM (DomainKeys Identified Mail) is a cryptographic signature. The sending system signs selected headers and the body with a private key and publishes the matching public key in DNS. The receiver fetches the key and checks that the signed content has not changed in transit.
DMARC ties the other two to the address a human actually sees. It asks whether SPF or DKIM passed for a domain that aligns with the visible From header, and it lets the domain owner publish a policy for what to do when neither aligns: do nothing, quarantine, or reject.
Where the results come from
This is the part that matters for after-the-fact analysis. The checks above are performed by the receiving mail server at the moment of delivery. That server writes its findings into an Authentication-Results header and passes the message along.
mailin reads those reported results. It does not perform live DNS lookups of its own, and a fresh lookup weeks later would be misleading anyway: SPF records and DKIM keys change over time and would not reproduce what the receiver saw. What you get in mailin is the receiving server's verdict, presented next to the rest of the headers so you can read it in context.
There is a second reason to treat the header as evidence rather than truth: it is just text, and a message that never passed through your mail server could carry a forged one. The header is most trustworthy when you know which server wrote it, which is where the routing chain comes in.
What a fail does not prove, and what a pass does not prove
A failed SPF or DKIM result is a signal, not a conviction. Legitimate mail fails these checks routinely: a message forwarded from another account arrives from an IP the original domain never listed, mailing lists rewrite subjects and footers in ways that break DKIM signatures, and plenty of real senders have their DNS misconfigured.
The reverse is just as important. A message can pass SPF, DKIM and DMARC and still be malicious. An attacker who registers a lookalike domain can set up perfect authentication for it, because they own it. A compromised account at a legitimate company sends mail that authenticates flawlessly. Authentication tells you the message came from where it says it came from; it says nothing about whether the person at that address meant you well.
Following the route the message took
Every server that handles a message prepends a Received header, so the chain reads bottom to top as a travel log. mailin's routing analysis lays out that chain so you can see which hops are yours, which belong to the claimed sender, and where something unexpected appears in between. This is also how you decide whether the Authentication-Results header was written by a server you trust.
mailin also shows the MIME tree of the message, every part and attachment rather than only what the mail client rendered, and computes attachment hashes so you can check integrity or match a file against a known-bad hash. IOC artifacts, meaning IP addresses, URLs and file hashes, are extracted automatically so you do not have to copy them out by hand. For a walkthrough aimed at a single message, see checking a suspicious email on your Mac.
Anomaly detection and auth-failure alerts
Reading one message is manageable. Reading months of mail for a possibly compromised account is not, so mailin also looks for patterns across an archive: unusual sending patterns, suspicious timing such as off-hours activity, and authentication failures. Smart Alerts let you set watches on senders, keywords, timing and thresholds, so a sudden run of DMARC failures from a domain you do business with shows up without a manual sweep.
Anomaly detection is a pointer, not a verdict: it tells you what is worth reading, not what to conclude.
Two guided workflows for this job
mailin 2.0 ships guided workflows for the IT and SOC role, modeled on NIST SP 800-61. Two are directly relevant here.
Email Authentication Audit reviews authentication results across a set of messages rather than one at a time, for working out whether a domain's mail is generally healthy or generally suspect.
Phishing Incident is the single-message case. Its steps are Intake, Analyze (headers and authentication, URLs, attachment hashes, IOC extraction), Verdict (Confirmed, Safe or Needs-info), Contain (export an IOC blocklist) and Close. Each run is saved as a numbered document you can reopen later. If you are dealing with many copies of the same lure, Phishing Campaign (Bulk) handles the set together, and Blocklist Export turns the collected IOCs into a blocklist file.
All of this happens on your Mac, iPhone or iPad; the message is never uploaded, and mailin has no account and no telemetry. These features are designed to support common records-integrity and eDiscovery workflows. Admissibility of digital evidence is jurisdiction-specific and depends on factors beyond any single software tool — consult qualified legal counsel for evidentiary use.
FAQ
Does mailin check SPF, DKIM and DMARC itself?
No. mailin reads the results the receiving mail server recorded in the Authentication-Results header. It does not perform its own DNS lookups; a later lookup would not reflect what the receiver saw.
If DMARC failed, is the message definitely phishing?
No. Forwarding, mailing lists and misconfigured senders all produce legitimate failures. Treat a failure as a reason to look harder at routing, links and attachments, not as proof on its own.
Can I get the message into mailin without forwarding it?
Yes, and you should avoid forwarding, since that rewrites the headers. Save the original as an .eml or .msg file, or drag the .emlx from Apple Mail, and open it directly in mailin.