Email tools
4 tools that run in your browser. Nothing to install, nothing uploaded.
Deliverability tools for the three failures that actually stop mail arriving: a record that does not say what its author intended, an SPF record that has quietly passed the ten-lookup limit and is therefore treated as permanently broken, and a bounce whose code decides whether the message will ever be retried. Each runs against public DNS or against text you paste, in your browser. They are also blunt about the one thing that cannot be checked from outside: DKIM verification needs the selector, which is published nowhere, so a domain’s signing setup can only be confirmed from a message it has actually sent.
- Email Bounce Code DecoderRead what a bounce message actually says, and whether it will retry.
- DMARC Record GeneratorBuild a DMARC record — starting where you should, not where you want to end.
- SPF Record GeneratorBuild an SPF record and count the lookups before it breaks.
- SPF Lookup CounterCount the DNS lookups your SPF record really costs — the limit is ten.
The ten-lookup limit that silently breaks SPF
An SPF record may trigger at most ten DNS lookups while it is being evaluated, counting every include, a, mx, ptr and redirect — and every lookup those nested records trigger in turn. Go over it and the result is not a partial pass but a permanent error, which strict receivers treat as a failure for all your mail. This is the most common way SPF breaks, because it happens gradually: each new SaaS product that asks you to add an include costs lookups, and the record that worked for years stops working the day a vendor adds a nested include of their own.
Where to start a DMARC rollout, and where not to
DMARC has three policies and only one of them is a sensible starting point. p=none asks receivers to report without changing delivery, which is what you want first: the aggregate reports tell you every source sending as your domain, including the ones nobody remembers — the invoicing system, the CRM, a marketing platform set up by someone who has left. Publishing p=reject before you have read those reports rejects your own legitimate mail. The usual path is none for a few weeks, then quarantine on a fraction of mail, then reject, with alignment confirmed at each step.
Why DKIM cannot be checked from the outside
SPF and DMARC live at predictable DNS names, so anyone can look them up for any domain. DKIM does not: the public key is published under a selector chosen by whoever configured it, at selector._domainkey.example.com, and there is no way to enumerate selectors. That is why a deliverability check that reports SPF and DMARC in full will say DKIM is unverifiable without one — and why any tool claiming a complete DKIM verdict from a domain name alone is either guessing at common selector names or overstating what it found. To confirm signing, read the selector out of the headers of a message the domain actually sent.
Reading a bounce before rewriting anything
Bounce codes carry more information than the message text around them. The first digit is the decision: a 4xx is temporary and the sending server will keep retrying for a day or more, while a 5xx is permanent and nothing will be retried. The extended status code that usually follows narrows the cause — mailbox does not exist, mailbox full, message too large, policy rejection, reputation block — and those call for completely different responses. Treating a soft bounce as a hard one removes addresses that were only temporarily unreachable, and treating a hard bounce as soft is how a sender damages its own reputation.
Frequently asked questions
Why is my SPF record failing when it looks correct?
Most often the ten-lookup limit. SPF permits at most ten DNS lookups during evaluation, counting every include, a, mx, ptr and redirect plus everything those nested records trigger. Exceeding it is a permanent error, which strict receivers treat as a failure for all your mail — and it happens gradually, as each new SaaS vendor asks you to add an include, or as a vendor quietly adds a nested include of their own.
Should I publish p=reject straight away?
No. Start at p=none, which asks receivers to report without changing delivery, and read the aggregate reports — they will list sources sending as your domain that nobody remembers, typically an invoicing system, a CRM and a marketing platform set up by someone who has since left. Publishing reject before those are aligned rejects your own legitimate mail. Move to quarantine on a fraction of traffic, then to reject, confirming alignment at each step.
Why can you check SPF and DMARC but not DKIM?
Because DKIM keys are published under a selector chosen at configuration time, at selector._domainkey.example.com, and there is no way to enumerate selectors from a domain name alone. SPF and DMARC live at fixed, predictable names, so anyone can look them up. Any tool claiming a complete DKIM verdict from a domain by itself is guessing at common selector names. To confirm signing, take the selector from the headers of a message the domain has actually sent.
What is the difference between a soft and a hard bounce?
The first digit of the code. A 4xx is temporary — the sending server keeps retrying, typically for a day or more, and the cause is often a full mailbox or a rate limit. A 5xx is permanent and nothing is retried, usually because the address does not exist or the message was rejected on policy. Removing addresses that soft-bounced discards recipients who were only briefly unreachable; ignoring hard bounces damages your sending reputation.