Synthetic example: a monthly form delivery matrix with one late message and one sender-check failure

The invented set-up

The three forms below belong to an imaginary site: a contact form, a quote request and a callback request. Times, results and the sender domain are invented. Before the first test the site owner confirmed in writing that each form only sends its notification to one mailbox and triggers nothing else: no list sign-up, text or chat alert, lead routing, webhook or conversion tag. Each test uses the same marked made-up identity, so the entry can be recognised and deleted: a name starting "ZZ SI Test", an address at a domain the testers control, a telephone number from the range reserved for drama and a message saying it is a test. The expected receiving address is a mailbox the site owner controls, and the owner saved the original of each received message and sent it on, rather than forwarding it.

• Contact form: should reach the front-desk mailbox.
• Quote request: should reach the sales mailbox.
• Callback request: should reach the front-desk mailbox; the fictional telephone number means nobody can be called back by mistake.

The matrix

One row per form. "Window" is the agreed time within which a message should arrive. The sender checks are read from the headers of the original message that arrived, not from a forwarded copy: a normal forward is a new message, so its checks would describe the forward and not the receipt.

• Columns: form, sent, received, delay, window, SPF, DKIM, placement, result.

If the matrix is wider than the box, scroll horizontally to read every column. Keyboard: focus the matrix and use Left/Right.

form             | sent  | received | delay | window | SPF  | DKIM | placement | result
contact          | 09:00 | 09:01    | 1m    | 10m    | pass | pass | inbox     | OK
quote request    | 09:02 | 09:47    | 45m   | 10m    | pass | pass | inbox     | LATE: queue or service delay suspected
callback request | 09:04 | 09:05    | 1m    | 10m    | pass | FAIL | junk      | SENDER CHECK FAILED: DKIM

Reading each row

The contact form passed everything. The quote request arrived but 45 minutes after it was sent, well past its 10 minute window, with all sender checks passing. That points to a delay in a queue or a sending service, not to authentication, and the report says "suspected" because the matrix alone cannot separate the form plugin's queue from the mail service or the receiving system. The callback request arrived in junk with a DKIM failure, which points to the signing setup for that sending route, not to the form itself. Comparing last month's row for the same form would show whether this is new.

• Late with passing checks: check queue settings and the service's delivery log.
• Failing check: involve whoever controls the domain's DNS and the sending service.
• A form missing from the matrix entirely: the entry may not have been saved at all.

What the matrix cannot tell you

It shows the state of three forms on one test day. It does not watch the forms between tests, does not prove that every real enquiry arrives, and cannot say why a message was junked by a receiver whose rules are private. It also does not include any form that triggers a payment, a newsletter or other list sign-up, a text or chat alert, lead routing, a webhook or a customer system, because a monthly marked test should not do that unless a safe route has been agreed in writing.

• A pass is a pass on the test day only.
• Do not read the invented times as typical.

Use it to specify an enquiry

To get a monthly report like this, send the form addresses, the mailboxes that receive them and who should be told of a failure. The standing form check has a published test price of GBP 95 a month for up to five forms. A failed row can lead to the one-off sending job, with a published test price of GBP 175 for up to three forms on one single site. Both are untested proposals and payment follows the agreed terms.

• Send names and addresses of forms, not passwords or keys.