One of your first customers signs up for your SaaS app. A moment later, they message you: “Hey, where's my email?” They need the verification code to get in, and nothing has appeared in their inbox.
Your app logged a successful send. You ask them to check spam and try again. Now they're waiting on a second message, and you still don't know what happened to the first.
At this stage, email delivery is part of the product experience. A missing code can stop someone from signing in. A missing invitation can keep their colleague from joining. You need evidence that lets you explain what happened and choose a useful next step.
Forte brings email delivery outcomes, recipient suppressions, and DMARC reports into the project console. Delivery records help you investigate one customer's message. DMARC reports help you spot authentication problems affecting your sending domain.
A successful send is only the first step
An email moves through several systems after your app asks to send it. The sending service accepts the request, attempts delivery to the recipient's mail server, and reports the outcome. The receiving system then decides how to handle the message.
Amazon SES, for example, distinguishes Send from Delivery. Send means SES accepted the request and will attempt delivery. Delivery means the recipient's mail server accepted the message. That still doesn't establish that it appeared in the inbox or that the customer read it. Amazon SES event definitions
So “the API returned success” isn't enough to answer the customer. You need the delivery outcome for the message they expected.
Find the customer's message in Forte
For email sent through your verified Forte sending domain, open the project's Overview and choose the Email deliverability card. In Deliveries, set the time range around the customer's attempt and filter by their exact recipient address. You can also filter by user or status.
Check the recipient, subject, and send time before opening the row. If the customer tried twice, those details help distinguish the original message from the retry. The detail view shows the message ID, last event time, and available bounce, complaint, or diagnostic information. When Forte can associate the recipient with a project user, it also links to that user.
Use the status to decide what to inspect next:
| Status | What to check next |
|---|---|
| Sent | Delivery has no later outcome recorded yet. Check again before treating it as delivered. |
| Delayed | Read the diagnostic for a temporary delivery problem. |
| Bounced | Inspect the bounce type and diagnostic, then confirm the address with the customer. |
| Rejected | Inspect why the sending service refused to deliver the message. |
| Rendering failed | Investigate the template or send path before asking the customer to retry. |
| Complaint | Review the complaint and suppression record before considering another send. |
| Delivered | The recipient's server accepted it. Ask the customer to check spam, quarantine, and mailbox rules. |
These outcomes reflect the underlying email delivery events. The SES event reference explains their meaning. Updates arrive asynchronously, so the console may not show a final outcome immediately.
If no record matches, first check the project, filters, recipient, and time window. Then inspect the app operation that should have sent the message. A missing row alone doesn't tell you whether the app attempted the send or failed before it reached the email service.
Check suppressions before sending again
A recipient suppression stops further sends to an address. Forte records suppressions for hard bounces, complaints, and addresses added manually. Open Suppressions when a customer keeps requesting mail without receiving it.
Confirm why the address was suppressed before changing it. An old address that permanently rejected mail needs a different response from a valid address whose owner reported an earlier message as spam. Removing the entry without resolving that cause can repeat the problem.
Suppressions apply across projects using the account's sending domain. A problem that began with another project can therefore affect this customer's next email. Delivery listings, by contrast, are scoped to the selected project.
For the customer waiting on a code, a useful reply might be: “The message bounced because the address was rejected. Can you confirm the address you used?” That gives them a concrete action. Keep the full diagnostic in your investigation rather than copying sensitive details into a public support exchange.
Use DMARC reports to find wider authentication problems
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It lets a domain publish how receiving servers should handle messages that fail its authentication checks and where to send reports.
It builds on SPF, which authorizes sending servers, and DKIM, which signs messages with a domain's key. DMARC also checks alignment: whether a passing SPF or DKIM domain matches the visible From domain under the published policy. A message needs a passing, aligned result from at least one of them to pass DMARC. Google's explanation of DMARC alignment
Aggregate DMARC reports summarize what participating receiving providers observed over a reporting period. They show sending sources, message counts, authentication results, and how the receiver handled the messages. They are usually sent daily, so they serve a different purpose from looking up the code a customer requested moments ago. Google's DMARC report guide
In Forte, open DMARC reports to inspect a provider's report. The detail view shows the reported domain, reporting window, published policy, and source rows with IP addresses, counts, disposition, DKIM, and SPF results. Reports need the domain's DMARC reporting address configured to route them to Forte, and providers need time to send them.
These reports are domain-wide. They can include other legitimate senders using the domain, as well as unauthorized traffic claiming to use it. Don't assume that every reported source belongs to this project or that a failing source caused one customer's missing message.
If a known sender is failing, review that sender's authentication and DNS configuration before changing the domain's policy. Passing DMARC also doesn't guarantee inbox placement. Delivery records, domain authentication, and the customer's mailbox observations answer different parts of the investigation.
Avoid building the investigation during the first complaint
With a self-managed SES setup, you configure event publishing, select which events to collect, and connect them to a destination. You also need a way to find the message behind a customer report. Separately, raw DMARC reports arrive as XML and need to be collected and interpreted. SES event publishing setup · Reading DMARC reports
Forte handles that collection and presents the delivery outcomes and domain reports in its console for supported sends. This view covers email sent through Forte's sending setup; it doesn't automatically import logs from a separate email provider your app calls directly.
Your own sending domain requires approved compliance registration and verified DNS records before its deliverability data becomes available. The Forte sandbox email sender is a separate testing option with its own limits. A successful sandbox test doesn't establish that your production domain is configured correctly.
Close the loop with the customer
After fixing the cause, ask the customer to trigger the intended flow again. Find the new message record, inspect its outcome, and confirm that the customer can complete the task. For a verification code, success means they can sign in.
Keep the recipient, message ID, approximate time, and a safe explanation of the result in your support notes. Avoid copying codes, reset links, or private message content into logs and tickets.
Before inviting more customers, test the email flows they depend on with mailboxes you control at the providers you expect them to use. Check both the delivery records and the actual mailbox. Review DMARC reports as they arrive to catch authentication issues beyond that initial test.
Set up Forte email templates for the messages your app sends, and use the deliverability view when a customer asks where one went. You can then respond with evidence while they are still trying to use your product.