DMARC vs phishing: knowing which one you're looking at

When you flag every failed authentication header as a security

alert, you don't protect the reader — you train them to ignore you.

Most email security tools, including the default settings in

enterprise gateways, treat DMARC failure and **lookalike domain

impersonation** as the same severity. The reader sees an inbox

where one urgent label out of three is real and the other two are

a misconfigured newsletter from an industry contact. After a few

weeks, all three get ignored. This is the alert fatigue

problem that phishing actually depends on.

DMARC, DKIM, and SPF are not attacks

Authentication headers fail for reasons that have nothing to do

with the sender being malicious:

• A small business sends email through a marketing platform that

signs with their own DKIM key, but the platform also runs a

newsletter sign-up flow that forgets to sign. DMARC fails

on the second flow, even though the sender is legitimate.

• A consultant forwards mail from their personal account to a

mailing list. The forwarding rewrites the headers and **SPF

fails**, even though the recipient is who they say they are.

• A subdomain is never used for outbound mail but is referenced

in a website `From:` address by mistake. **DKIM alignment is

absent**, but no impersonation is happening — the original email

is honest about who it's from.

These are configuration problems, not phishing. Flagging

them at the same level as a high-confidence lookalike domain

attack — the Paypa1 kind of substitution that costs mid-market

companies real money — trains the reader to file them all under

"noise."

What changes when the warning matches the risk

Nocturnal Post runs the morning

brief on every inbound mailbox and surfaces flagged threads at

the top. Two recent releases changed what those flags look like.

Threat tier (red SECURITY badge) is reserved for signals

that mean an attacker is trying to impersonate someone the

reader knows or trust:

• `lookalike_domain_high` — the sender's domain is **confusable

with one you already deal with** at high confidence (for

example `paypa1.com` vs `paypal.com`, or `stripe-invoice.com`

vs `stripe.com`).

• `bec_suspicious` — the message has the **shape of a business

email compromise** request: urgency, a wire transfer, an

unusual reply-to, a recently-registered sending domain.

• `dmarc_reject` — the sender's domain **explicitly tells

receivers to reject mail that fails authentication**. When

this flag fires, the sender is asking to be rejected for

that reason. Respect it.

• `confusable_chars` — the domain uses **Unicode look-alike

characters like Cyrillic а in place of Latin a**.

Auth tier (neutral AUTH badge) is for the configuration

problems. A misconfigured DKIM key on an otherwise-legitimate

newsletter still ends up here:

• `dkim_fail`
• `spf_fail`
• `no_auth`
• `unauthenticated`

A thread with both raises both badges. The red SECURITY

heading stays the headline; the gray AUTH badge sits beside

it as secondary context.

Releasing the false positive from the summary

Knowing which warnings to act on is half the job. The other half

is being able to act without leaving the email. Two weeks of

release feedback from operators running Nocturnal Post converged

on the same request:

> *"On my quarantine emails there are options to manage each

> email. Can we have those on the summary? It might just be

> links to the web app but it will allow it to happen faster."*

The morning brief already grouped flagged threads into a single

section. The 0.25.10 release added two inline actions under each

flagged thread:

• [Release] — the thread's been reviewed and the operator

decided it's safe. Records who marked it, when, and removes

the badges from future briefs. Not a delete — the

original mail stays in the mailbox. The flag set is preserved

for audit; the badge is just suppressed.

• [Review] — deep-link to the full findings view for the

thread, with the original sender domain, header analysis,

and authentication trace in one place.

Both actions are idempotent. Releasing a thread that's

already been released returns the original timestamp without

re-recording. Replay safety was the most-requested property

from early operators who needed to be able to forward the brief

to a colleague and have either of them act on it.

The landing page is the scan, not the work

The same release turned the post-login page into an Overview

view: hero card showing when each brief last fired, the top of

the Awaiting review queue (with one-click Release from the

landing itself), the open work items sorted by priority, and a

five-row recent-mail table for situational awareness.

Every widget deep-links into the page where the actual work

lives (`/briefings`, `/items`, `/messages`). Overview is the

scan. It's the place you open when you want to know whether

something needs your attention in the next ten minutes. If yes,

you act from there. If no, you close the tab.

What this is not

Nocturnal Post is not a mail gateway. It does not rewrite,

quarantine, or delete mail. It reads headers and body content

to classify, and it surfaces classification in a format you

control. If you want a gateway that drops mail at SMTP time,

this is not it, and we don't pretend to be.

It is a way to read what already exists in the inbox,

faster, with the false positives labeled as false positives

and the real threats labeled with the reasons they're real.

Try it

Nocturnal Post is FOSS, self-hostable, and free for the first

five mailboxes. The morning brief starts arriving within a

minute of connecting a Microsoft 365 or Gmail mailbox. The

security triage described above is on by default for accounts

that look like managed-services or healthcare practices — the

two verticals that see the highest volume of BEC attempts per

seat, per the FBI IC3 reports.

• Self-host with Docker
• Sign up for the hosted beta
• Read the security notes