Contact Temp Postal - San Francisco Support & Sales

What each contact route is for

Support handles anything about a live inbox: a verification code that has not arrived, an address that a website rejects, attachments that will not open, or a message that vanished before you read it. These are the fastest cases to resolve because the answer is usually visible in delivery telemetry once we know the address and rough timestamp.

Billing covers plan changes, invoices, VAT details, refunds and failed payments. Payments are processed by our merchant of record, so a refund request is confirmed by us and executed there - which is also why an invoice arrives from the payment processor rather than from Temp Postal directly.

Business and API enquiries cover volume pricing, custom domains, rate limits above the published tier and data-processing paperwork. Sending your expected message volume and the integration you are building saves a full round trip; those two facts determine the answer almost entirely.

Abuse and legal requests are separate. If an address on our infrastructure is being used to harass someone or to receive material connected to fraud, tell us the address and include headers where you have them. These are triaged ahead of ordinary support and do not require an account.

Details that turn a slow ticket into a fast one

The single most useful thing you can send is the full inbox address, exactly as generated. Disposable addresses are deliberately unguessable, and a partial address cannot be matched to a delivery record. If the inbox has already expired, say so - it changes what we can look for.

The second is timing. Mail delivery problems are almost always about a specific window: a sender's queue, a greylisting delay, or a rejection at our edge. Knowing that you expected a code at roughly 14:20 UTC narrows the search to a few seconds of log rather than a day of traffic.

The third is the sender. Some services refuse disposable domains outright, and the symptom on your side looks identical to a lost message: nothing arrives, no bounce. When we can see that the sender never attempted delivery, the answer is immediate - that provider blocks disposable addresses and you need a durable mailbox for it.

Screenshots help for interface questions and rarely help for delivery questions. A screenshot of an empty inbox does not tell us whether mail was rejected, delayed or never sent; the address and timestamp do.

Things support genuinely cannot do

We cannot restore messages from an expired inbox. Retention is enforced by deletion, not by hiding: once the window closes the message is gone from storage and there is no administrative copy to recover. This is the property that makes the service privacy-preserving, and it applies to us exactly as it applies to anyone else.

We cannot make a third-party website accept a disposable address. Blocklists are maintained by the receiving service, and asking for a specific domain to be allowed is a request only they can grant. Where the signup matters - banking, government, employment, anything with account recovery attached - use your permanent mailbox instead.

We cannot send mail on your behalf. Inboxes are receive-only, which is deliberate: an anonymous sending relay is an abuse magnet and would put the whole platform's deliverability at risk. If a service needs a reply-to that works, it needs a real mailbox.

And we cannot identify who owns an address. There is no account behind a free disposable inbox, so there is nothing to disclose. Law-enforcement requests are answered with what actually exists, which is generally very little.

Response times and how they are set

Free-tier questions are answered during business hours on a best-effort basis, typically within one working day. Premium raises priority in the same queue, and Business accounts have a documented target agreed at signup, along with a named contact for integration work.

Response times are set by triage rather than by arrival order. Anything affecting delivery for multiple users, any abuse report and any billing failure that blocks access is handled before general questions - so a routine 'how does retention work' reply may arrive after a live delivery issue reported later.

If you have not had a reply in two working days, resend on the same thread rather than opening a new one. Duplicate threads split the history and slow the answer down, and the original message is occasionally lost to an aggressive spam filter on the way in.