Do chase emails reach supplier inboxes, and how would you know?
Certly logs every chase email it sends to a supplier contact with the recipient, the time it went out, the delivery result and any opens, so whether a chase reached a supplier is a recorded status rather than a hopeful assumption. This page is about reading that evidence: what sent, opened and failed each prove, what to do when one fails, and where the record stops short of proof.
How much a chase email status actually proves
Every chase Certly sends is written against that supplier and certificate type with the recipient, the time it went out, the delivery result and any opens. By default a chase leaves through Amazon SES on the product's own sending role. You can instead connect your site's own sending account, a from address, mail server, sign-in name and mailbox password or API key, encrypted before it is stored, so the message arrives from a mailbox the supplier already recognises rather than from a stranger. How that history reads on a supplier record is covered on the chase log page; the question worth answering here is what each status is evidence of, because QA managers tend to credit it with more than it holds.
Sent
Sent means the message went to that address at that time and nothing has come back as a failure. It proves you asked, on a date you can name. It does not prove a person saw it.
Opened
An open is recorded when the route the mail took reports the message being rendered in a mail client, which is what a site sending through a connected Resend account gets back. It is the strongest of the three signals, and it is still a fact about a mailbox rather than about intent.
Failed
Failed means the send did not complete, and Certly writes that to the log with its own badge and a resend action beside it rather than recording the attempt as contact made. This is the status that earns the whole arrangement, because a dead address or an unfinished sending setup stops looking like a chase that landed.
The decision in front of you when a chase fails
Timing is what makes a failure recoverable. Expiry status is computed against alert thresholds at 90, 60 and 30 days before the date, configurable per certificate type, so a chase that fails at the first threshold still leaves you three months to fix the address and ask again. The same failure found in the week of an audit is a different problem with fewer options.
So the order is narrow: read the failed badge on the log entry, correct the contact details on the supplier record, resend from the log, and if the next scheduled threshold is weeks away, use chase now for an immediate send that is logged as a manual step. Each attempt stays on the record, so the trail shows what you tried rather than only what worked.
What none of that changes is the number an auditor reads. The dashboard's four states, current, expiring soon, expired and missing, describe whether a document is on file and in date. A tidy chase record with an expired certificate behind it is still an expired certificate, and Certly says so on the dashboard and the PDF export: it tracks and reminds, it does not verify a certificate's authenticity or guarantee regulatory compliance.
Questions
What happens when a chase email fails or bounces?
The log entry for that send carries a failed badge instead of a sent one, and a resend action sits next to it, so the failure stays visible in the supplier's history rather than being quietly replaced. Before you use resend, open the supplier record and check the contact email, because a resend to the same address produces the same result. Edit the contact there if it is wrong, then resend. The new attempt is logged as its own entry with its own status, and the failed one stays on the record as part of the trail.
Does opened mean the supplier read it and will act?
No. An open is reported back by the route the message took, and it tells you a message reached a mailbox and was rendered, not that the person read the request or will send a document. The absence of an open is weak evidence in the other direction too, because some mail clients block the tracking and some sending routes report no opens at all, so a message that was read can still look unopened. Treat opens as a signal about who to telephone next, not as proof of either delivery or intent.
Why would a chase email get filtered, and what reduces the odds?
No sender can promise inbox placement, but a chase has the shape of an ordinary transactional message: one named recipient, a plain subject naming your site and the certificate that is due, and a single-use expiring upload link rather than a shortened redirect. Certly shows a read-only preview of that exact template, subject line and body, in settings, so you can read what a supplier will read before anything goes out. Connecting your site's own sending account is the other lever, because the chase then leaves from an address your suppliers already correspond with. How your site's name appears in that subject is covered on the page about your plant's name on supplier reminder emails.
A chase shows sent and nothing has been uploaded. What then?
Sent with no upload is the ordinary case at the first threshold, and it is not a reason to do anything dramatic. The next configured threshold chases again, and each chase carries its own single-use expiring upload link, so the supplier does not need the earlier email any more. If the date is close and the row still reads expiring soon or expired on the dashboard, send an immediate chase and then telephone the contact. The log gives you the dates you asked on, which is the useful thing to have in that conversation.
Can I chase a supplier now rather than waiting for the next threshold?
Yes. Alongside the automated sequence that fires at your configured thresholds, 90, 60 and 30 days before expiry by default, there is a chase now action on the dashboard row and the supplier page. It sends a one-off chase using the same template and logs it as a manual step, so your history separates who was chased by hand from who was chased by the schedule. The delivery status is recorded the same way, so a manual chase that fails is just as visible as an automated one.
Who actually sends the emails, and where does the delivery result come from?
Chases and upload-link emails go out through Amazon SES on the product's own sending role unless your site connects its own sending account, in which case they leave from that mailbox instead. A site that connects a Resend account sends through Resend and has opens reported back. The application and its database run on Amazon Web Services. For each send Certly stores the recipient, the time it went out, the delivery result and opens, which is why the log can show a failure rather than an assumption.
How long is chase history kept, and can a supplier contact be erased?
Chase history is kept for as long as your account is open, because that trail is part of what an auditor asks for when they want evidence you pursued a lapsed certificate. A supplier contact's name and email address can be erased on their own from that supplier's page, behind a confirmation that explains what goes, the contact name and email, and what stays, the certificate records. Upload links expire on their own. Deleting the account removes suppliers, documents, chase history and settings together, and the same screen downloads a JSON file of your data first.
If every chase shows as delivered, does that mean we are covered for the audit?
No. A chase record is evidence that you asked a named person on a given date, which is worth having when a certificate is late and someone wants to see what you did about it. Whether the document is on file and in date is a separate question, answered by the four certificate states on the dashboard and its PDF export. Certly carries that distinction in the product: it tracks certificates and reminds the people who hold them, and it does not verify a certificate's authenticity or guarantee regulatory compliance.