Demo
Demo

Knowledge base

PMTA knowledge base›Accounting record§ 12.2

Delivered — the record everything is counted by

critical

d
The most numerous accounting record — and the basis of any volume figure

The record appears when the destination server accepted a message for a specific recipient. One per recipient — which makes this record the most numerous of all, and any sending volume figure is ultimately calculated from it.

The record type in the line is d. The first field of every accounting line names the type, and that is how records are parsed: d — delivered, b — bounced, t — temporary failure.

There are thirty-six fields, twenty-two written by default. The set is the same as for bounce and temporary failure records — which is convenient: a parser for all three types is written once.

What the record contains. The outcome and its code, the time of queuing and the time of the event, the sending address, the job, the size, transport security and proxy data, if there was one. That is, enough to answer “how much went out,” “from which address” and “was the transfer encrypted.”

What it does not contain. What happened to the message after the destination server accepted it: whether it landed in the inbox, whether the recipient opened it. The record speaks only about the transfer.

The main trap is treating delivery in this record as delivery to the recipient. It means the message was accepted by the destination server, and exactly that. After that the message may end up in spam, be dropped by the recipient’s filter or be silently deleted by a rule — and there will not be a single record about it. The figure “98% delivered” describes the transfer, not that the message was seen.
What the Hub does. It collects accounting records from the nodes and builds all its analytics on them: volumes, deliverability by provider, fleet corridors. This record is the source of the numerator in almost every formula.

It arrives as a stream through a webhook, not by reading a file: the node is configured to hand records to the Hub as they appear.

⚠️ That is exactly why we show deliverability, not the inbox rate — we have no data about the folder and cannot have any: the node does not know about it. Inbox monitoring would require seed mailboxes and IMAP polling, and that is a separate task.

Recommended values

What this record can and cannot measure:

Question Does the record answer it
how many messages the destination servers accepted yes, this is exactly it
from which address and for which job yes, the fields are there
whether the transfer was encrypted yes, transport security is recorded
whether the message landed in the inbox no — the node does not know this
whether the recipient opened it no — that is another source

Twenty-two fields out of thirty-six is the default, not the limit. The set of written fields is configurable; expanding it should be done deliberately: the record is the most numerous, and every extra field is multiplied by the sending volume.

Three record types share the same field set — delivery, bounce and temporary failure. A parser written for one type reads the other two as well.

The “what it measures and what it does not” separation is ours. From the manual here are the condition under which the record appears, the type letter, the number of fields and the fact that the set is shared with bounce and temporary failure records.
Example configuration
# a delivery accounting line: the type in the first field
d,2019-02-08 21:53:41+0000,2019-02-08 21:53:41+0000,CB-A=example.com@bounce.foo.com,#   A@example.com,,delivered,2.0.0,smtp;250 OK,mail.example.com (10.1.2.3),...
The highlighted line starts with the type letter — that is how the parser tells a delivery from a bounce. Next come the time of queuing and the time of the event, the return address, the recipient and the outcome.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
▲

Common mistakes and problems

what people get wrong and how it ends3 mistakes▶

Reading the record as delivery to the recipient

§ 12.2

What it costsThe record means acceptance by the destination server. What happened next — the spam folder, a filter, a recipient’s rule — accounting does not and cannot know. The delivered share describes the transfer, not landing in the mailbox.
How to spot itDeliverability in the report is high, recipient response is low.
How to do it rightCall this quantity deliverability, not inbox placement. Seed mailboxes answer about the folder, not the node’s accounting.

Expanding the field set without calculating the volume

§ 12

What it costsThe record is the most numerous: one added field is multiplied by the number of delivered recipients. Accounting grows faster than expected and runs into the partition’s space.
How to spot itAccounting files grow noticeably faster than before with the same sending volume.
How to do it rightAdd fields deliberately and have accounting rotation configured in advance.

Looking for missing records in the file instead of in the configuration

§ 3.3.10

What it costsIndividual record types are disabled by a directive, and then events happen but leave no trace. The absence of records is indistinguishable from the absence of events.
How to spot itAccounting has no records of one type, while sending is going on.
How to do it rightCheck whether this record type is disabled for the receiver or the sending address.
Compatibility
PowerMTA 6.0
described in the manual of this version · platform: any
The vendor does not state the first version for every directive — there is no note here. The name also appears in the 5.0 edition of the manual.
Inheritance
The record has no inheritance — it is a fact, not a setting. What is inherited is where it will go and which fields will be written: both the accounting destination and the field set are defined by accounting block directives, and individual record types can be disabled altogether with the disable-acct-records directive — then the events will still happen, but leave no trace.
⇄

Related entries

3 relations

Does not work without

Sending addressThe field with the sending address name — it shows which queue delivered the message. § 12.2.1Encryption versionThe field with the encryption version: whether the transfer was encrypted and how exactly. § 12.2.1How many attempts there wereThe field with the number of attempts: how many times it had to be retried before success. § 12.2.1

Referenced from

What the node tells about itself and through which channelsThe accounting record the answer to “what happened to the message” is made of. § 1.4pmc-acct-min-free-spaceGlobalThe same events that go to the node’s accounting are also written for the console — as separate CSV files. inferencedisable-acct-records<domain>The delivery record — the one written even for messages sent nowhere. § 3.3.10.8assume-delivery-upon-data-termination-timeout<domain>A delivery record made on an assumption is indistinguishable from a real one in accounting. § 3.3.10.102The telemetry contractThe most frequent record in the stream: a message was delivered to the recipient. § 3.3.11records<acct-file>The record type chosen most often: successful delivery to the recipient. § 3.3.11.11

How to check on the node
Check that records are being written and that they have the expected fields:
head -3 /var/log/pmta/acct-*.csv
cut -d, -f1 /var/log/pmta/acct-*.csv | sort | uniq -c
The first shows the header and the first lines — the header shows the field set. The second prints a summary by record type: if there are no deliveries at all while sending is going on, check whether this record type has been disabled.
◇

What else to read

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 telemetry contractOne block describes the accounting output in full: which record types, which fields, where they go, how files rotate and what gets anonymized.◇How an accounting record is structuredHow an accounting record is structured: the record type in the first column, then the fields, whose composition is configurable.

In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Troubleshoot deliverability · Collect telemetry
Priority
critical