Home
Features
Modules
Integrations
PowerMTA Docs
MailerQ Docs
Pricing
Blog
D
e
m
o
Home
Features
Modules
Integrations
PowerMTA Docs
MailerQ Docs
Pricing
Blog
D
e
m
o
Home
Features
Modules
Integrations
PowerMTA Docs
MailerQ Docs
Pricing
Blog
Home
Knowledge base
Knowledge base
PMTA knowledge base
›
Scenario
Address suppression
entries in this scenario: 20
hashed-address
<address-list>
Directive
The address is lowercased, hashed with SHA256 and encoded as BASE64URL; the engine hashes the address being checked and compares the hashes.
suppression-lists
<source>
Directive
Attaches one or more named address lists; a recipient on a list is rejected at submission or bounced later, depending on how invalid recipients are accepted.
suppression-lists
<virtual-mta>
Directive
The same line as in a source, but here there is no choice — the message is always accepted, queued and bounced.
address
<address-list>
set by the Hub
Directive
Accepts three forms — a full address, a bare local part or a regular expression in slashes.
address-file
<address-list>
Directive
Includes a file where each line holds a full address or a bare local part.
hashed-address-file
<address-list>
Directive
Includes a file where each line is the hash of a whole address; there is not a single readable address in the file.
Two attachment points — and two different behaviors
critical
Mechanism
A list attached to a source rejects the recipient at submission or bounces the message later; attached to a sending address or pool, it always accepts and then bounces.
The bounce category in accounting — configurable, not vendor-fixed
critical
Mechanism
The bounceCat string in every accounting record comes from a pattern list that can be extended with your own rules and your own category names.
Parsing bounces that arrive as messages
critical
Mechanism
Bounce reports that arrive as messages are parsed by a separate processor — and it runs before the complaint processor.
Configuration through the API and the file do not reconcile
critical
Mechanism
Objects created through the configuration interface cannot be edited in the file: two sources of truth about the configuration do not reconcile.
Complaints parsed by the node — and they are parsed second
critical
Mechanism
Mail that arrives at an address from the configured list is parsed as a complaint report; the parsing order matters — the complaint processor runs after the bounce processor.
Address lists — named and unnamed
Mechanism
A list of addresses, domains, patterns or hashes; a named one is attached by directives such as suppression, an unnamed one lives inside an inbound mail processor.
delete
critical
Command
Deletes recipients from the queue by selection; it does not run without
–queue
or
–jobId
.
digest
Command
Computes the hash of a given string with the chosen method.
list
Command
Lists recipients in queues by selection; with
–pause
it interrupts a recipient’s delivery to show it.
Address lists through the configuration API
critical
API endpoint
Creates, reads, extends and deletes address and domain lists — for suppression, for example — without editing files.
Permanently bounced
critical
Accounting record
The recipient permanently did not receive the message — either the receiving server refused for good, or the node itself bounced the message when the deadline expired.
Complaint
Accounting record
A complaint report was received and parsed by the configured processor.
Parsed bounce from outside
Accounting record
A bounce report email arrived at the configured processor and was parsed.
Spam traps
Monitor screen
The SparkPost Signals report on spam trap hits by day — as a count or as a share of the day’s volume.