Understand the terms in your logs,
and you’ll know what to check next.

Addresses and use cases

Temporary email / disposable email

An address that receives email for a limited time, often used for a one-off sign-up test or to check a verification code. “Temporary” refers to how long the address is kept; it doesn’t mean every third party will accept it, or that it’s suitable for sensitive information.

Forwarding alias

A unique address that forwards incoming messages to an email address you choose. You can assign aliases by sender and pause them, but pausing an alias won’t recall copies already delivered to your destination inbox. An alias is not a substitute for an inbox you control long term.

Email sandbox

A testing service that captures emails an application would otherwise send, so you can inspect templates and variables in a development environment. A successful handoff to a sandbox doesn’t prove the same email can reach a real user over the public internet.

MX record

A DNS record that identifies the mail servers responsible for receiving email for a domain. Correct MX records are one part of routing; on their own, they don’t prove that a recipient address exists, a server accepted a message, or a user can see it in their inbox.

Delivery and status

SMTP

A common protocol for sending email between mail servers and between an application and an outgoing mail server. A successful SMTP response usually means the server at that hop accepted the message—not that the email completed its entire journey.

Queued

The email task is waiting in a processing queue. It may not have connected to the receiving server yet. If it stays queued for a long time, check for a backlog, retry schedule and provider status instead of just refreshing the inbox.

Accepted

A service has received a request or email. Check which service accepted it: an application accepting a request, a sending platform accepting a task and a receiving server accepting an email are three different kinds of evidence.

Bounce

A notice or status indicating that delivery failed. It may be caused by a nonexistent address, a policy rejection or another issue. Check the error code and explanation, distinguish a permanent failure from a temporary one, then decide whether to retry.

Deferral

A server temporarily declines an email, for example because of limited resources or rate limits. SMTP 4xx responses are common in these cases. The sending service may retry according to its policy, but the receiving inbox doesn’t control the timing or number of attempts.

Message-ID and provider message ID

Identifiers used to match emails with logs. The Message-ID in an email header may differ from the task ID returned by a sending API. When reporting an issue, record both and note where each came from—don’t just say “sent successfully.”

Sender identity

SPF

SPF uses DNS to specify which servers are authorised to send email for an envelope sender domain. Passing SPF doesn’t mean the From address shown to users is a trustworthy sender, or guarantee that the email will reach the inbox.

DKIM

DKIM adds a domain-based signature to selected parts of an email, which the recipient verifies using a public key. A valid signature means the signed content passed verification; it doesn’t prove the email is safe or that the sender’s business claims are genuine.

DMARC

DMARC combines SPF or DKIM authentication results with alignment against the visible From domain, and specifies a handling policy. A reject policy doesn’t guarantee delivery. Forwarding and third-party sending still need to be configured correctly.

From and Return-Path

From is the sender address users typically see; Return-Path is generally related to where bounces are sent. A difference between them doesn’t automatically mean an email is fake, but check them separately when investigating sender identity and bounces.

Content and verification

OTP / one-time passcode

A code used to verify identity for a specific request within a limited time. Receiving an OTP only proves the email arrived. Whether the code still works depends on the request it’s linked to, its expiry and whether it’s already been used. Never paste an active code into a support ticket.

HTML and plain-text email bodies

An email may include both a formatted HTML version and a plain-text version. Check both: key links, verification codes and service information should match and shouldn’t appear only in an image.

CID-embedded image

An image referenced by a content ID within an email, often sent along with attachments. If a temporary email service doesn’t retain these images, the message may look incomplete. That doesn’t mean the sender omitted the body; check the original message structure.

Code expiry and mailbox expiry

The website that sends a verification code sets its validity period; the receiving service controls the mailbox countdown. Extending the mailbox won’t extend the code’s validity, and changing addresses won’t update an account you’ve already registered on a website.

When you see these terms, ask:

Different timers can’t extend one another