critical
A receiving server checks the address a message came from against the sender domain’s SPF record. If they do not match, the message is rejected or goes to spam, and the address’s reputation suffers. This mechanism moves the same check to our side: the node checks itself before sending.
Three outcomes. Pass — we send. TempError — we retry later. Everything else — we bounce, and the message does not go out at all.
The check requires knowing the sending address. It is taken from smtp-source-host or smtp-proxy-source-host; without them the node cannot perform the check.
# the check is off for the bounce domain and on for everyone else <domain yourbouncedomain.com> check-spf-outbound no</domain> <domain *> check-spf-outbound yes</domain>
what people get wrong and how it ends2 mistakes▶
§ 10.2
§ 10.2
3 relations
pmta check spf 203.0.113.10 mail.example.com sender@example.com pmta show settings gmail.com/vmta1 | grep -i check-spf-outbound
3 articles
◇What the node tells about itself and through which channelsSeven observation surfaces: the web monitor, the console in four formats, the log, accounting, accounting search, metrics and export to external analytics.◇The watchdog that restarts the engineKeeps an eye on the engine and brings it back up after a crash by itself, sending a crash report to the postmaster address.◇How the policy for a receiver is assembledSettings are assembled from the most general pattern to the most precise; the order of blocks in the file means nothing.