SPF Is Not Enough

Archive note, April 2026: This post is based on a mail-posture review for Aztexsystems. Sensitive operational details have been omitted.

A suspicious email is not automatically evidence that your mail server was compromised.

That sounds obvious, but it is easy to skip the boring investigation step when the message looks alarming. A spoofed display name, a familiar sender address, and an unexpected recipient can make the situation feel worse than the evidence supports.

The mail-posture review started with a simple question: did this message indicate local mail-server compromise, or was it more likely ordinary inbound spam or account abuse elsewhere?

Start With Headers

The visible email fields are not enough.

The useful evidence is in the raw headers:

  • Received chain.
  • Authentication-Results.
  • Return-Path.
  • DKIM-Signature.
  • Delivered-To.

Those fields show where the message appears to have originated, which systems handled it, and whether authentication checks passed or failed.

If the local mail host appears only as a receiving hop, that points in a different direction than authenticated outbound submission from the local server.

SPF Helps, But It Is Not The Finish Line

SPF was present for the domain under review. That is better than nothing. It defines which hosts are allowed to send mail for the domain.

But SPF alone is not a complete anti-spoofing posture.

DMARC matters because it tells receiving mail systems what to do when authentication fails and provides a policy layer around SPF and DKIM alignment. Without DMARC, the domain has a weaker public posture than it should.

The practical recommendation was straightforward: review the evidence first, then add DMARC as part of tightening the domain’s mail posture.

Do Not Confuse Inbound Spam With Outbound Compromise

The initial evidence pointed more toward inbound spam or Gmail-side behavior than local mail-server abuse.

That distinction matters because the response paths differ.

For possible inbound spam:

  • Review raw headers.
  • Check whether the local host only received the message.
  • Confirm filtering behavior.

For possible account abuse:

  • Review Gmail account security.
  • Check sent mail.
  • Check forwarding.
  • Check filters.
  • Check delegated access.

For possible server compromise:

  • Review mail logs.
  • Look for authenticated SMTP submissions.
  • Inspect unexpected forwarding or alias behavior.
  • Check unusual IMAP or SMTP logins.

Skipping straight to the worst case wastes time and may miss the actual issue.

The Lesson

Mail security is not one record and one dashboard.

It is a posture: SPF, DKIM, DMARC, PTR behavior, server logs, account security, and header literacy. The work is not glamorous, but it keeps the investigation grounded.

The important habit is to separate what is known from what is suspected. A suspicious message deserves attention. It does not deserve a conclusion before the headers and logs have been read.