What a domain of your own actually changes
The public domains are printed on every page of this site. That is fine for what they are for — a code that expires in ten minutes, a download behind an email wall — but it has two consequences you feel quickly.
First, sign-up forms recognise them, and a growing number refuse them. Second, because the address is the only secret protecting a mailbox, and the domain half of that address is public knowledge, somebody trying likely names will eventually land on a live inbox.
A domain nobody has heard of fixes both. No blocklist carries it, and nobody is trying names against a domain they do not know exists.
| A public domain here | A domain you own | |
|---|---|---|
| Set-up | None | One DNS record |
| Addresses | Any name you invent | Any name you invent, on your own name |
| Listed on this site | Yes — that is the point of it | Never |
| Refused by sign-up forms | Sometimes, and increasingly | No reason for it to be |
| Readable by a stranger | If they guess the address | If they know the address |
| Retention | 5 days | 5 days — the same |
| Price | Free | Free |
The record
At your DNS provider, on the domain itself:
| Field | Value | Notes |
|---|---|---|
| Type | MX | |
| Name / Host | @ | The domain itself. Some providers want the bare domain here instead, and a few want it left empty — all three mean the same thing. |
| Priority | 10 | Any number works when it is the only record. Ten is the convention. |
| Value / Target | smtp.grabmail.io | A hostname, not an IP address. Some providers add the trailing dot themselves; both spellings are correct. |
| TTL | Default | One hour is typical. It only decides how long a stale answer lingers. |
The value to pastesmtp.grabmail.io
Check it before you wait for mail
$ dig +short MX yourdomain.comYou want exactly one line back, and it should read 10 smtp.grabmail.io. — one priority, one host, nothing else. If you see two, the second is the one eating your mail.
If dig is not to hand, nslookup -type=mx yourdomain.com says the same thing on Windows.
Why there is no second step
Most services would now ask you to create an account, paste a token into a TXT record and click a verification button. There is nothing like that here, and it is not laziness — it is that the MX record you just published is already a better proof than any of it.
If a domain’s mail is being handed to us, whoever set that up controls the domain. Nobody else can make that record exist. So the record is the verification, and it costs you one DNS edit you had to make anyway.
- No account
- Nothing to create, nothing to log into, nothing to lose the password for.
- No token
- No TXT record, no HTML file, no verification email that has to reach a mailbox that does not work yet.
- No waiting room
- That first message is delivered, not discarded. Test with something real and you get to keep it.
An address per service, and what that gets you
Nothing has to be created, so every name on the domain already works. That turns into a habit worth having: give every service its own address.
newsletter@yourdomain.com
shop-jan26@yourdomain.com
that-forum@yourdomain.com
receipts@yourdomain.com- You find out who leaked it. When mail you did not ask for starts arriving at the address you only ever gave to one shop, there is no doubt about which shop.
- You can burn one at a time. An address that has gone bad is one you simply stop reading — there is nothing to delete and nothing else affected.
- Filtering becomes trivial. The recipient address is the label; you never have to guess from the sender.
- Nothing is reserved. No quota, no limit on how many names you use, no list to maintain.
The same applies to a test suite: a fresh address per CI run costs nothing and is the single most useful habit in an end-to-end mail test.
Reading it
Exactly as you read any other mailbox here — the domain is the only thing that changed.
In a browser
Open the inbox athttps://grabmail.io/inbox/anything@yourdomain.com
Over the API
$ curl -sG https://grabmail.io/api/v1/mailbox \
--data-urlencode "address=anything@yourdomain.com"No key and no headers: a domain connected this way carries no key, so it reads exactly like a public one. If a domain has been given a key of its own, the API answers 401 with WWW-Authenticate: Bearer and the call needs an Authorization: Bearer header — everything else about it is identical.
The three endpoints, their parameters and every status code are in the API reference.
What it does not do
- It does not lock the mailbox
- Anyone who knows an address on your domain can read it, through the site or the API. The name being private is the whole of the protection.
- It does not let you send
- Nothing here sends mail, on any domain. Our SPF is
v=spf1 -alland our DMARC isp=reject, so anything claiming to come from us is forged and every receiving server is told to bin it. If you need to send from the domain as well, you need a real mail provider and you cannot point the MX here. - It does not extend retention
- Messages are deleted after 5 days on your domain exactly as on ours. There is no archive and no setting.
- It does not take subdomains
- Only a domain somebody registered —
example.com, orexample.co.uk.mail.example.comis refused, because whoever controls a domain controls every name beneath it, and letting the two be held separately would hand two parties overlapping keys to one namespace without telling either.
When mail does not arrive
| What you see | What is going on | What to do |
|---|---|---|
Nothing arrives, and dig shows no MX | The record has not been published, or it was added to the wrong zone. | Check you edited the zone for the domain itself, not a subdomain, and that you saved it. |
dig shows two or more MX records | A leftover from a previous provider. We refuse a domain that is not our single MX. | Delete the others. Registrars often add their own parking MX when you buy a name. |
dig shows the right record, still nothing | The old answer is still cached, or we remembered a refusal from a few minutes ago. | Give it fifteen minutes and send again. Refusals are remembered briefly so a flood aimed at domains we do not host is not one DNS lookup per message. |
| The record looks right but points at an IP | An MX record has to name a host, not an address. | Put smtp.grabmail.io in the value field, not an IP. |
| Mail arrives for some addresses and not others | Almost always a second MX still in the zone. | Same fix: one record, ours, and nothing else. |
The API answers 404 on your domain | It is not connected yet — no message has ever arrived, or the MX was wrong when one did. | Fix the record, send something, then call the API again. Adoption happens on delivery, not on the API call. |
| It worked, and stopped | The MX changed or disappeared. We re-check every domain about once a day and disconnect after three failures on separate days. | Put the record back. A domain that comes back is reconnected automatically, with its strikes cleared. |
A lookup that fails — a resolver that times out, a network that is down — is never counted as a strike. Only a clear answer counts, so a bad afternoon at your DNS provider cannot disconnect a domain that is fine.
What to read next
Give out the alias, not the address
Every mailbox has a second address that delivers to it and opens nothing. It works on your domain too.
Read it from a test suite
A fresh address per run, a deadline instead of a retry count, and working Playwright and pytest helpers.
The API reference
Three endpoints, every parameter, every status code, and the error shape.
Questions
Does it cost anything?
No. Connecting a domain is free, like the rest of the service. You pay whoever you bought the domain from, and nothing to us.
How long does it take to work?
As long as your DNS takes to publish the record — usually minutes, occasionally an hour if the old answer was cached with a long TTL. There is nothing to wait for on our side: the first message that arrives connects the domain.
Will my domain appear anywhere on your site?
No. Customer domains are never listed, never offered in the address picker on the front page, and never mentioned publicly. The domain picker only ever shows the public domains.
Can I still send mail from the domain?
Not through us — nothing here sends. And because the MX has to be ours alone, you cannot point it here and keep another provider for the same domain. If you need to send, use a domain you are not pointing at us.
Can I use a subdomain, like mail.example.com?
No. Only a registrable domain is accepted, because whoever controls the domain controls every name under it. Two parties holding overlapping halves of one namespace, with only one of them told about it, is a problem worth refusing outright.
What happens if I remove the MX record?
Mail stops arriving immediately, since senders follow the record rather than us. We re-check about once a day and disconnect the domain after three clear failures on separate days. Nothing is deleted, and putting the record back reconnects it automatically.
Is mail on my own domain private?
Private from the senders, yes — they never learn anything about you. Private from everyone else, no: there is no account here, so there is nothing a mailbox can be locked to, and anyone who knows an address can read it. What your own domain removes is the guessing, not the reading.
