How Temporary Email Works: MX Records, SMTP and Inbound Delivery Explained

Temporary email works by using ordinary internet mail infrastructure with one twist: the receiving side accepts mail for any username on its domains and keeps it only briefly. A sender's server looks up the domain's MX record in DNS, connects to the listed host over SMTP on port 25, and delivers the message. The temp mail system then parses the message, shows it in a live inbox, and deletes it automatically after a set time. On VookMail, the domains' MX records point to a mail delivery provider that receives the SMTP session and forwards each message to VookMail over HTTPS.

This article follows a single message from the moment someone clicks "send" to the moment it vanishes from a disposable inbox. It is written for curious users, developers testing email flows, and anyone who wants to understand why some messages arrive instantly while others never show up.

Key takeaways

• DNS decides where mail goes. The MX record of the recipient's domain names the server that accepts its mail.
• SMTP carries the message. Mail servers talk to each other over SMTP on TCP port 25, using commands such as EHLO, MAIL FROM, RCPT TO and DATA.
• Catch-all acceptance removes sign-up. A temp mail domain accepts every local part, so any username you type is instantly valid.
• Modern inbound delivery often ends in HTTPS. A receiving provider converts the SMTP delivery into an HTTPS request to the application, which is how VookMail receives messages.
• MIME parsing turns raw mail into something readable, separating plain text, HTML and attachments.
• Auto-deletion is a scheduled cleanup, not magic. VookMail removes messages and attachments after about one day.
• Most "missing email" problems are on the sending side: queues, retries, size limits, or senders that refuse disposable domains.

What happens when someone sends an email to a temporary address?

Here is the complete journey, condensed into steps. Each step is explained in detail later.

1. The sender writes a message or an application generates one, for example a sign-up confirmation.
2. The message is submitted to the sender's outgoing mail server, usually over port 587 with authentication, or handed to a sending API.
3. The outgoing server reads the recipient domain from the address, for example veylax.com in test123@veylax.com.
4. It queries DNS for the domain's MX records.
5. It picks the MX host with the lowest preference number and opens a TCP connection to it on port 25.
6. The two servers hold an SMTP conversation, usually upgraded to an encrypted channel with STARTTLS.
7. The receiving server accepts the message with a 250 reply code. Responsibility for the message now belongs to the receiver.
8. The receiver, in VookMail's case a mail delivery provider, forwards the message to the temp mail application over HTTPS.
9. The application parses the MIME structure, stores the message temporarily and associates it with the address.
10. The browser or mobile app showing that address displays the new message in the inbox.
11. After the retention period, a cleanup process deletes the message and its attachments.

What is an MX record and why does it matter?

An MX (mail exchanger) record is a DNS resource record that tells the world which server accepts email for a domain. Without it, other mail servers would not know where to deliver messages addressed to that domain.

An MX record has two parts: a preference (sometimes called priority) and a hostname. In zone-file notation it looks like this:

example-temp.com. 3600 IN MX 10 mx1.mail-provider.example.
example-temp.com. 3600 IN MX 20 mx2.mail-provider.example.

• 3600 is the TTL (time to live) in seconds: how long resolvers may cache the answer.
• 10 and 20 are preferences. Senders try the lowest number first. If mx1 is unreachable, they fall back to mx2.
• The hostname must itself resolve to an IP address through A (IPv4) or AAAA (IPv6) records. An MX record should point to a hostname, not directly to an IP address, and not to a CNAME.

What if a domain has no MX record?

The SMTP standard (RFC 5321) defines a fallback: if no MX record exists, the sender may treat the domain's own A or AAAA record as an implicit mail host. Conversely, a domain can publish a null MX (RFC 7505), an MX record with preference 0 and a single dot as the host, to declare explicitly that it accepts no email. Temp mail domains obviously publish real MX records, because receiving mail is their entire purpose.

How can you look up MX records yourself?

You can check any domain's mail routing from your own computer:

• Windows: nslookup -type=mx example.com
• macOS and Linux: dig MX example.com +short
• PowerShell: Resolve-DnsName example.com -Type MX

The output lists each mail host with its preference. Anti-abuse systems use exactly this lookup to identify domains that route mail to known disposable infrastructure, which is one reason some websites can recognise temp mail domains even when they are new.

Why DNS caching affects new domains

When a temp mail service adds a new domain, its MX record must propagate. Resolvers that previously cached a "no such record" answer may keep it until the negative cache time expires, which is controlled by the domain's SOA record. In practice this means a newly added domain can take a short while to receive mail reliably from every sender worldwide.

How does the SMTP conversation work?

SMTP (Simple Mail Transfer Protocol) is the text-based protocol mail servers use to hand messages to each other. It is a sequence of commands from the client (the sending server) and numeric replies from the server (the receiver). A simplified delivery to a temporary address looks like this, where S: is the receiver and C: is the sender:

S: 220 mx1.mail-provider.example ESMTP ready
C: EHLO out.sender.example
S: 250-mx1.mail-provider.example
S: 250-STARTTLS
S: 250 SIZE 26214400
C: STARTTLS
S: 220 Ready to start TLS
(TLS handshake, then EHLO again)
C: MAIL FROM:<bounce@sender.example>
S: 250 OK
C: RCPT TO:<quietfox42@example-temp.com>
S: 250 OK
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: (headers, blank line, body, then a line with a single dot)
S: 250 Queued as 8F2A1C
C: QUIT
S: 221 Bye

What each command does

SMTP reply codes you should know

• 2xx (success): 250 means accepted. After the final 250, the receiver is responsible for the message.
• 3xx (intermediate): 354 tells the sender to transmit the message data.
• 4xx (temporary failure): for example 421 or 451. The sender should keep the message in its queue and retry later. Retries can stretch over hours, depending on the sender's schedule.
• 5xx (permanent failure): for example 550 (mailbox unavailable or rejected) or 552 (message too large). The sender gives up and usually generates a bounce message.

Understanding 4xx versus 5xx explains a lot of "slow" temp mail. A temporary refusal at any hop means the message is waiting in a queue somewhere, not lost, and it will appear only when the sender retries.

Envelope versus headers

SMTP has two layers of addressing. The envelope (MAIL FROM and RCPT TO) is what servers use for routing. The headers (From:, To:, Subject:) are part of the message content and are what you see in the inbox. They can differ. A newsletter might show To: subscribers in the header while the envelope recipient was your temporary address. A receiving system therefore files messages by the envelope recipient, which is the reliable value for routing. This is also why the Return-Path header, added by the final receiver, records the envelope sender rather than the visible From address.

How can a temp mail domain accept any username without sign-up?

Most mail servers validate the recipient during RCPT TO: if the mailbox does not exist, they reply 550. A temporary email domain is configured the other way around. It runs as a catch-all (also called wildcard) receiver: every local part at the domain is accepted. The local part is the portion before the @.

This one configuration choice is what makes instant addresses possible:

• When VookMail shows you a random address, nothing had to be created on the mail server.
• When you type your own username, it already "exists" because the domain accepts all usernames.
• The application simply needs to show you the messages whose envelope recipient matches the address on your screen.

Local part rules and normalisation

The local part of an email address may technically contain many characters, but in practice services stick to letters, digits, dots, hyphens and underscores. Two subtleties matter for temp mail:

• Case: the standard says the local part may be case-sensitive, but virtually all real systems treat Test@ and test@ as the same mailbox. A temp mail system should normalise to lower case so that a sender's capitalisation does not split one inbox into two.
• Length: the local part is limited to 64 octets and the full address to 254 characters in practice. Long generated usernames should stay well inside those limits.

How does inbound mail get from SMTP to the temp mail website?

Running a production mail server that faces the whole internet involves a lot of work: handling TLS, resisting connection floods, managing queues, scanning for malware, and keeping IP reputation healthy. Many modern applications therefore delegate the SMTP side to a specialised inbound mail delivery provider and receive messages as web requests. This pattern is often called an inbound parse webhook.

VookMail uses this model. Its domains' MX records point to a mail delivery provider that receives SMTP and forwards each message to VookMail over HTTPS. The flow looks like this:

1. SMTP reception: the provider's MX hosts accept the message from the sender's server.
2. Packaging: the provider wraps the message, either as the raw MIME source or as already-parsed fields (sender, recipients, subject, text, HTML, attachments), into an HTTP request.
3. HTTPS POST: the provider sends that request to an endpoint operated by the temp mail application. HTTPS encrypts the payload between the provider and the application.
4. Acknowledgement: the application responds with a success status. If the application is unreachable or returns an error, a well-behaved provider retries according to its own policy.
5. Processing: the application validates the request, matches the recipient to an address, stores the message temporarily and notifies any open inbox.

Why use HTTPS forwarding instead of running an SMTP server directly?

The trade-off in the last row is real. When an inbound provider has an outage or a configuration problem, delivery to every domain behind it can stop until the provider fixes it, even if the temp mail website itself is running normally. Messages refused with a temporary error during such a period may still be retried by the original senders afterwards, depending on how long their queues keep them.

Securing the HTTPS endpoint

An inbound webhook endpoint is a public URL, so a careful implementation protects it. Common techniques include:

• Signature verification: the provider signs each request with a shared secret or key, and the application rejects requests whose signature does not match.
• Secret path or token: an unguessable URL component or header value known only to the provider and the application.
• Source restrictions: accepting requests only from the provider's published address ranges where available.
• Size limits: rejecting oversized payloads early to protect memory and storage.
• Idempotency: because providers retry, the same message may arrive twice; using the Message-ID or a provider event ID avoids duplicate entries.

How is the raw email turned into something you can read?

An email message is plain text structured according to the Internet Message Format (RFC 5322) and MIME (Multipurpose Internet Mail Extensions). MIME allows one message to carry multiple parts in different formats and encodings.

The typical structure of a modern email

• Headers: From, To, Subject, Date, Message-ID, Content-Type and trace headers such as Received, which record every server the message passed through.
• multipart/mixed: the outer container when there are attachments.
• multipart/alternative: contains the same content in two forms, text/plain and text/html. The reader shows the richest format it supports.
• multipart/related: groups HTML with inline images referenced by cid: identifiers.
• Attachment parts: each with a Content-Disposition: attachment header and a filename.

Encodings the parser must handle

• Base64: used for binary attachments and sometimes for text. It inflates size by roughly a third, which is why a 10 MB file becomes roughly a 13 to 14 MB message.
• Quoted-printable: used for mostly-ASCII text, encoding special characters as =XX sequences.
• Character sets: declared in charset=, commonly UTF-8. A temp mail service with many interface languages must also display messages in many scripts correctly.
• Encoded headers: subjects and names containing non-ASCII characters use the =?UTF-8?B?...?= or =?UTF-8?Q?...?= syntax defined in RFC 2047.

Displaying HTML safely

Email HTML comes from untrusted senders, so a temp mail viewer must not let it run code in the context of the website. Responsible implementations typically:

• Remove scripts, event handler attributes and dangerous URL schemes.
• Render the message in an isolated frame with restrictive sandboxing so its styles and content cannot affect the surrounding page.
• Treat remote images with care, because loading them reveals to the sender that the message was opened (the classic tracking pixel).
• Offer the plain-text version when HTML is absent or broken.

Attachments

Attachments are decoded from base64 and stored temporarily so the user can download them. VookMail supports attachments and deletes them together with messages after about one day. Users should remember that a file's safety does not depend on where it is stored: an executable or macro-enabled document is just as dangerous when downloaded from a temporary inbox.

How does a real-time inbox update without reloading?

Once the message is stored, the inbox on your screen needs to learn about it. Web applications use a few standard techniques to show new data live:

Whatever the mechanism, the effect for users is the same: VookMail's inbox updates in real time, and the Refresh button gives a manual check whenever you want one, for example after your device has been asleep or your network dropped.

Opening the same inbox on another device

Because the address itself identifies the inbox, moving it to another device only requires passing the address or a link that encodes it. VookMail does this with a QR code: scan it on your phone and the same inbox opens there. This is convenient, and it also illustrates why disposable inboxes should be treated as low-privacy: the address is effectively the key.

How does automatic deletion work?

Retention in a temp mail system is usually implemented with a timestamp on every stored message and a scheduled job that removes everything older than the limit. Attachments stored as separate files are deleted alongside their messages. On VookMail, messages and attachments auto-delete after about one day.

Design choices around deletion include:

• Batch cleanup: a job runs at intervals and removes expired records. This is why expiry is described as "about" a day: the exact moment depends on when the job runs.
• Storage-level expiry: some databases support time-to-live indexes that delete documents automatically.
• User-initiated deletion: controls like VookMail's Delete button let users remove content before the automatic deadline.

Short retention is both a privacy feature and a capacity necessity. Disposable inboxes receive a lot of marketing mail, and keeping it indefinitely would serve no one. For details on data handling, read VookMail's privacy policy and methodology.

Why do temp mail services offer many domains?

VookMail lets you choose from around 31 domains. There are practical reasons for running many domains rather than one:

• Choice and organisation: testers can separate projects or test suites by domain.
• Resilience: if one domain has a DNS or delivery issue, others may still work.
• Reputation spread: sending systems evaluate recipient domains as well as senders; spreading legitimate traffic avoids over-reliance on one name.

Multiple domains are not a tool for getting around websites that deliberately refuse disposable addresses. If a service rejects one temp mail domain, it is signalling that it wants a permanent contact, and the right choice is your real address or a permanent alias for that service.

Where do SPF, DKIM and DMARC fit in?

These three standards are frequently mentioned in email discussions, so it is worth being precise about their role.

• SPF (Sender Policy Framework): a DNS TXT record listing which servers may send mail using a domain in the envelope sender. Receivers check the connecting IP against it.
• DKIM (DomainKeys Identified Mail): a cryptographic signature added by the sending domain to selected headers and the body. Receivers verify it using a public key published in DNS.
• DMARC: a policy record telling receivers what to do when a message fails SPF and DKIM alignment with the visible From domain, and where to send reports.

All three are primarily about proving who sent a message. For a receive-focused temp mail service, they matter in two ways: the receiving provider can use the results to flag spoofed messages, and forwarding steps can preserve or break signatures. DKIM signatures survive forwarding if the message is not modified; SPF results relate to the last connecting server. When mail is relayed, the ARC (Authenticated Received Chain) standard can record earlier authentication results. None of these determine whether your temporary address can receive a message; the MX record and the receiver's acceptance do.

Why do some emails never reach a temporary inbox?

When a message does not arrive, the cause is usually one of the following. Working through them in order solves most cases.

1. Typo in the address. The message went somewhere else, or bounced. Always use the copy button rather than typing.
2. The sender has not sent yet. Many applications queue transactional emails and process them in batches. A delay of a minute or two is normal for some services.
3. Temporary failures and retries. A 4xx response anywhere in the chain causes the sender to retry later, sometimes after 15 to 30 minutes or more.
4. The sender refuses disposable domains. Some platforms check the domain at sign-up or at send time and silently skip delivery. No inbox change will fix that; use a permanent address there.
5. Size limits. Very large attachments can exceed the receiver's maximum message size, leading to a 552 rejection.
6. The address has expired. If the email arrives after the retention window or after you deleted the address, you will not see it.
7. Infrastructure issues. DNS problems or an outage at the inbound provider can interrupt delivery to all domains at once until resolved.

A troubleshooting checklist for developers testing their own app

• Check your application's mail logs or sending provider dashboard: was the message accepted by your provider, and what was the final delivery status?
• Look for bounce messages or webhook events reporting a 5xx code from the recipient side.
• Verify the recipient domain's MX records resolve correctly from your server's network.
• Confirm your own sending domain has SPF, DKIM and DMARC configured; some receivers treat unauthenticated mail with suspicion.
• Send a small plain-text message first to rule out size or content filtering.
• Use a distinct custom username per test so you know exactly which run produced which message.

The full pipeline at a glance

What security limits should users understand?

• Transport encryption is hop by hop. STARTTLS encrypts each server-to-server leg if both sides support it, and HTTPS protects the forwarding and viewing legs. That is not end-to-end encryption; the systems that handle the message can read it.
• The address is the key. Without a password, knowledge of the address is what grants access on many temp mail designs. Random addresses are much harder to guess than short custom names.
• Content is untrusted. Phishing and malware can arrive in any inbox. A temporary inbox protects your real address, not your device.
• Short retention limits damage but also means you cannot rely on the inbox as a record.
• Appropriate use only. Temporary email is for privacy, spam control and testing, not for important accounts or for abuse. See the terms and conditions.

How does this apply when you use VookMail?

Every time you open VookMail, the technical chain above is already in place. The page creates an address on one of the service's domains. You can type your own username, pick from about 31 domains, or press the yellow shuffle button for a random address. Because the domains accept any username, the address is valid instantly. When a sender delivers mail, the provider behind the MX records receives it over SMTP, forwards it over HTTPS, and the message appears in your real-time inbox with any attachments. You can copy the address, open the inbox on your phone with the QR code, keep several addresses in one browser, and use the Refresh, New and Delete controls. About a day later, the messages and attachments are gone.

The same service is available as an app on Google Play and Huawei AppGallery. For a non-technical introduction to disposable email, or for comparisons with aliases and plus addressing, browse the VookMail blog.

Frequently asked questions

How does a temp mail service receive emails without accounts?

The service publishes MX records for its domains and configures the receiving server to accept mail for any username at those domains. Because every local part is accepted, there is nothing to register; the address works the moment someone sends to it.

What is an MX record?

An MX (mail exchanger) record is a DNS entry that tells sending servers which host accepts email for a domain, along with a preference number. Lower numbers are tried first, and higher numbers act as backups.

Which port does inbound email use?

Server-to-server email delivery uses SMTP on TCP port 25. Ports 587 and 465 are used by email clients to submit outgoing mail to their own provider, not for delivery between mail servers.

How does VookMail get messages from the mail server?

VookMail's domains have MX records pointing to a mail delivery provider. That provider receives the message over SMTP and forwards it to VookMail over HTTPS, after which VookMail shows it in the real-time inbox.

Why does a confirmation email sometimes take minutes to arrive?

The sending system may queue messages, retry after a temporary failure such as greylisting, or apply its own rate limits. Some senders also deliberately refuse or slow delivery to domains they consider disposable.

Are temporary emails stored forever?

No. Temporary email services delete messages on a schedule. VookMail removes messages and attachments automatically after about one day.

Can I check a domain's MX records myself?

Yes. On Windows run nslookup -type=mx domain.com, and on macOS or Linux run dig MX domain.com. The output lists each mail host and its preference value.

Do SPF, DKIM and DMARC matter for temporary email?

They are mainly sender-side authentication standards. A receiving system can read their results to judge whether a message is spoofed, but they do not control whether a temporary inbox can receive mail.