Source review dated 8 November 2026. This is documentary guidance; account, DNS and received-message acceptance tests below have not been executed.
Treat Postfix as the transport layer
Postfix is a mail transfer agent, not a hosted domain-verification service with a universal SPF include or account-generated DKIM wizard. Its documentation describes integration with external Milter applications, including signing software. This guide covers that integration boundary and route verification. Installing and operating a particular DKIM signer requires its own current documentation and deployment review; no signer-specific key-generation recipe is implied here. Postfix Milter support
Begin by drawing the actual message path. Does the application submit over SMTP, invoke the local sendmail interface, or hand mail to a remote service directly? Does Postfix deliver to recipient MX hosts or relay through a provider? Is there a content filter that reinjects mail? Write down the installed version, service configuration, signer, DNS owner, and responsible operator. The useful unit of acceptance is one complete route, not a server hostname.
Keep credentials and private keys out of the worksheet. Record only their managed locations and owners. Capture the existing configuration through approved administration methods, preserving a recovery copy before edits. This article proposes tests and review points; it does not authorize changing a production server or weakening relay restrictions.
Match the signer integration to the entry path
Postfix separates SMTP-arriving mail, controlled by smtpd_milters, from local sendmail and QMQP paths, controlled by non_smtpd_milters. One does not automatically cover the other. Socket syntax and chroot context also matter when the transport connects to a signer. Verify both the configured endpoint and whether the relevant Postfix process can reach it. Postfix SMTP and non-SMTP Milter sections
For each application, identify the service that accepts its message and the filters applied there. An administrator's test from a desktop client may exercise a different path from a scheduled job. Review service-specific overrides as well as the general configuration; a list in the main configuration is not evidence that every listener uses it. Correlate a harmless test's queue identifier with the operational logs available to the authorized administrator.
The signer must also decide which messages it is permitted to sign. Transport integration alone does not establish domain ownership or a safe signing policy. Follow the chosen signer's documentation for its domain mapping, key access, and trusted-submitter decisions. Do not make an untrusted inbound message appear authorized merely because it traverses the same server.
Inspect changes after the signing point
A signature verifies specific message content. A later transformation can invalidate it. Inventory footer insertion, header rewriting, mailing-list handling, and any filter or relay that changes the message after signing. Compare the final received signature result with the intended signing point rather than assuming a successful signer log guarantees validation downstream. DKIM RFC 6376
Postfix's after-queue filter example uses a dedicated reinjection listener and illustrates no_milters to avoid repeated filtering there. That is a property of the documented example, not a command to disable signing on every reinjection service. Review the actual listener and decide where the final authorized signature belongs, without creating a filter loop or broadening relay access. Postfix after-queue content filter
Agree the operational response to signer failure before rollout. Review the configured Milter error behavior, retry consequences, and business tolerance for unsigned mail versus delay. Postfix documents special restrictions for non-SMTP filters: a Milter must not REJECT or TEMPFAIL a simulated RCPT TO command, because the message remains queued. It also warns about internally generated bounces. Leave bounce signing outside the initial rollout unless an operator has explicitly reviewed those constraints. Postfix Milter error handling and bounce signing
Separate relay login from recipient authentication
SMTP AUTH authenticates a submission session. It does not by itself create an aligned DKIM signature or an SPF policy. In a relay deployment, confirm the actual selected relay and how it handles the sender and signature. Postfix documents relayhost and sender-dependent relay configuration, including matching the relay destination form and port with the credential-map lookup. Credentials remain private; only the route identity belongs in public troubleshooting. Postfix SASL Howto
For direct delivery, SPF must authorize the observed egress for the envelope domain. For provider relay delivery, use that provider's supported envelope and authentication configuration rather than assuming the local server IP is what the recipient evaluates. Preserve the existing legitimate sender inventory, one policy at each owner, and the standard's DNS lookup limits. SPF RFC 7208
At the receiver, compare From, the evaluated envelope identity, and each passing DKIM signing domain. DMARC needs a passing aligned mechanism. A relay accepting the connection, a TLS session completing, and a queue becoming empty establish different facts; none alone proves DMARC success. DMARC RFC 9989
Postfix route acceptance worksheet
Create a separate entry for each SMTP client, local application, and relay variation in scope.
- Route identity: application owner, entry protocol, Postfix service, version, queue identifier, and downstream relay or direct-delivery path.
- Signing boundary: signer product and version, relevant Milter parameter or relay responsibility, reachable endpoint, intended signing domain and selector.
- Transformation review: content filters, reinjection service, later modifications, and whether a final valid signature survives.
- DNS evidence: public-key owner and answer, envelope-domain SPF policy, authoritative server, collection time, and DMARC alignment settings.
- Receiver evidence: controlled-message timestamp, From, Return-Path, each DKIM d= and s= value, trusted Authentication-Results, and alignment conclusion.
- Operations: failure behavior, queue monitoring, rollback configuration, on-call owner, and acceptance sign-off. No live results are filled in by this draft.
Fictional diagnosis of an unsigned scheduled report
This scenario is fictional. An operations team enables a DKIM signer and sends a successful test through authenticated SMTP. The next morning, a scheduled report fails DMARC. Its queue entry shows local sendmail submission, and its received headers lack the expected signature. The SMTP test used one Milter path; the scheduled task used another.
The administrator's proposed repair is to review the local submission integration and the signer's authorization for that application, then test both routes again. A subsequent test should also verify the report after any content filter. The finding does not justify replacing SPF blindly or signing all inbound messages. Success remains an observed receiver result, not an outcome guaranteed by adding one configuration parameter.
Scope and release gates
No Postfix host, signer, relay account, live DNS, or received customer message was accessed. This manuscript is an integration and verification guide, not a complete installation guide for an unchosen DKIM signer. Current deployment-specific documentation, safe signing authorization, representative live tests, human SME review, and rendered presentation review remain pending. Keep broader claims about a fully authenticated Postfix estate on hold until the route worksheet is complete.