Email Authentication and Anti-Spam Concepts¶
Because SMTP was designed in an era with no concept of a hostile internet, it has essentially no built-in authentication: anyone can claim to be MAIL FROM:<[email protected]> and nothing in the base protocol stops them. Everything in this doc exists to bolt trust back onto that gap. None of it is Postfix-specific — Postfix just needs to be configured to check and/or publish it.
SPF (Sender Policy Framework)¶
An SPF record is a DNS TXT record published by a domain owner, listing which IP addresses/hosts are authorized to send mail claiming to be @yourdomain.com:
example.com. TXT "v=spf1 ip4:203.0.113.10 include:_spf.mailgun.org -all"
A receiving server checks the envelope sender's domain, looks up its SPF record, and verifies the connecting IP is in the authorized list. -all at the end means "hard fail anything not explicitly listed" (as opposed to ~all, a softer "mark as suspicious but don't necessarily reject").
This is directly relevant to every relay-through-a-smart-host setup in this guide: if you relay outbound mail through Mailgun or Gmail, your domain's SPF record needs to include: that provider, or your mail will fail SPF checks at every receiver that enforces it — even though Postfix itself is configured perfectly.
DKIM (DomainKeys Identified Mail)¶
DKIM cryptographically signs outgoing messages (a header like DKIM-Signature: is added, covering the body and selected headers) using a private key, and publishes the corresponding public key in DNS as a TXT record under a "selector":
mail._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0G..."
A receiver recomputes the signature using the published public key and confirms the message wasn't altered in transit and genuinely originated from a system holding the private key. Postfix itself doesn't implement DKIM signing natively — it's normally bolted on via a milter (mail filter) like OpenDKIM or rspamd, hooked into Postfix via smtpd_milters/non_smtpd_milters. (None of the personal notes here set this up, which tracks — DKIM/milter integration wasn't something covered historically, but it's worth calling out as a gap versus a modern baseline setup.)
DMARC (Domain-based Message Authentication, Reporting & Conformance)¶
DMARC ties SPF and DKIM together and tells receivers what to do when a message fails both, published as another DNS TXT record:
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"
p= is the policy: none (just report), quarantine (spam-folder it), or reject (bounce it outright). DMARC also requires alignment — the domain in the From: header has to match (or be a subdomain of) the domain that passed SPF or DKIM, which closes the loophole where SPF/DKIM pass for an unrelated domain while the visible From: header is forged.
RBLs / DNSBLs (real-time blackhole lists)¶
DNS-based blocklists that let a receiving server ask, essentially, "has anyone reported this IP for sending spam?" by making a specially-crafted DNS lookup against a list like zen.spamhaus.org or bl.spamcop.net. Postfix supports this natively via reject_rbl_client <list-domain> in smtpd_recipient_restrictions, which is exactly the pattern seen in the virtual-mailbox notes distilled into this guide.
Greylisting¶
Not a blocklist at all — a behavioral test. On first contact from a previously-unseen (sender IP, envelope sender, envelope recipient) triplet, the server temporarily rejects the message with a 4xx code and remembers the triplet. A well-behaved MTA will simply retry later (per the SMTP retry rules), at which point it's let through. Spam-sending software overwhelmingly does not implement retry logic, so it never gets past the initial rejection. This trades a delivery delay (typically a few minutes) for a large reduction in spam with almost no false-positive rate against legitimate mail. See the hardening doc for Postfix's postgrey integration.
Header/body/content filtering¶
The blunt-instrument approach: pattern-match on message headers or body content and reject or tag matches. Postfix's header_checks/body_checks/mime_header_checks do this directly with regex rules; heavier-weight content scanning (Bayesian filtering, etc.) is normally delegated to SpamAssassin or similar, hooked in as a content filter.
Open relay testing¶
Because being an open relay is both a self-inflicted deliverability disaster and a way to unknowingly participate in spam distribution, it's standard practice to actually test a newly configured server from outside your own network/trust boundary — testing from inside mynetworks will always succeed and tells you nothing. This is why the hardening notes distilled into this guide emphasize testing against a third-party relay-checking service rather than just trusting the configuration on paper.