Frequently asked questions
How mailampel works, what the rating means and where the limits are. We deliberately also say what the tool cannot do — an audit report is only worth as much as you can trust it.
How does the check work?
mailampel reads only information that is already published in DNS — the same place every mail server in the world consults before delivering to you. No mail is sent, nothing is sent to your systems, and no access is required.
Queries go over DNS-over-HTTPS to Cloudflare, with Google Public DNS as a fallback. Always the same route, so the result is reproducible. One single exception: if MTA-STS is configured, our server retrieves the policy file published there over HTTPS.
| Check | What is queried | What we look at |
|---|---|---|
| DMARC | TXT at _dmarc.your-domain | The policy (none / quarantine / reject), report address, partial enforcement, subdomain rule — and whether an external report address carries the required authorisation |
| SPF | TXT on the domain itself | The ending (-all / ~all / ?all / +all), number of records, and the count of DNS lookups triggered — recursively across every include |
| DKIM | TXT at <selector>._domainkey.your-domain | More than 25 common selectors, plus those of your detected mail provider. Key length and whether a key has been revoked |
| MX | MX records of the domain | Who accepts your mail. From that we derive which DKIM selectors are worth trying first |
| Mail server addresses | A, AAAA, CNAME and PTR of the MX targets | Whether every MX name really has an address behind it, whether an alias is in the way — and whether the addresses resolve back to the same name |
| MTA-STS | TXT at _mta-sts.your-domain plus the policy file | Whether the mode enforces or only tests — and whether the file is reachable and matches your MX records |
| TLS-RPT | TXT at _smtp._tls.your-domain | Whether and where encryption reports are sent |
| DNSSEC | DS record at the parent zone | Whether the zone is signed and the signature was validated on lookup |
| BIMI | TXT at default._bimi.your-domain | Only when DMARC is already enforced — otherwise every provider ignores the record anyway |
What the rating means
The five categories
Something is broken or missing, with real consequences — your mail arrives less reliably, or strangers can write in your name. These first.
It works, but it is weak or has no headroom. Typically: DMARC sits at p=none and only observes instead of protecting.
Nothing is broken, but there is something to gain. You will always find a concrete DNS record or instructions there — otherwise it would be a note.
That point is set up cleanly.
Pure information. Either there is nothing to do, or we cannot determine it from the outside.
The value from 0 to 100
The value is weighted, not counted. Only the checks that decide deliverability and protection against forgery contribute. One of them weighs in a single direction: broken mail server addresses pull the value down hard, sound ones do not lift it — otherwise an unenforced DMARC would look better simply because the basics are in place.
- DMARC4
Decides what happens to forged mail
- SPF3
Decides who is allowed to send at all
- Mail server addresses3
Only when broken: an MX with no address means nothing arrives at all. Addresses that are in order earn no points — reachable servers are a precondition, not an achievement
- DKIM2
Carries when SPF breaks — but only if we actually found a key
- MX, MTA-STS, TLS-RPT, DNSSEC, BIMI0
Optional extras. They do not drag the score down
What 100 out of 100 does not mean: that your mail is secure. It means the public records we checked are correct. The value says nothing about your mailboxes, passwords, malware protection or the actual encryption of your connections.
Where the limits are
“No DKIM found” does not mean “no DKIM”
DKIM keys live under a freely chosen name, the selector. Selectors cannot be enumerated from outside — they can only be guessed. We try the common ones.
If none turns up, we say so as a note, not as a problem: we simply do not know, and marking a domain down would be a claim we cannot support. Only a real message from you gives certainty — in the message header, the DKIM-Signature line contains s=, and that is your selector.
For PTR we only see the receiving side
What counts for deliverability is the PTR record of the server that SENDS your mail. From outside, however, only the addresses from your MX record are visible — that is, the receiving side.
With a self-hosted mail server that is the same machine and the finding applies. If you send by a different route than you receive — through a newsletter tool or a smarthost, say — then our finding says nothing about that route's PTR.
No live connection to your mail server
Whether your server actually accepts incoming connections encrypted, and whether its certificate is valid, is not currently checked. That would need a real SMTP connection on port 25, which is not possible from the platform mailampel runs on. It is planned for a later version.
The report is a snapshot
DNS answers are cached. After a change it takes anywhere from minutes to hours, depending on your zone's TTL, until servers worldwide see the new state. Our report shows what the resolver returns at that moment.
Individual questions
How long until a change shows up here?
Usually between five minutes and an hour, depending on the TTL of your DNS records. For freshly registered domains it can take longer. Just check again later.
Everything is green and my mail still lands in spam. How?
Because SPF, DKIM and DMARC only answer whether a message is genuine — not whether it is wanted.
Delivery also depends on the reputation of your sending IP address, how your recipients behave, the content, and whether you appear on a blocklist. Clean records are the entry ticket, not a guarantee.
May I check domains that are not mine?
Yes. Only public DNS records are read — the same ones every mail server queries anyway. That is neither an intrusion nor an access attempt.
Useful, for instance, to see how a prospective partner is set up before working with them.
Do you store what I check?
No. There is no history and no analysis. Once the report has been produced, the input no longer exists.
One single thing is counted: how many checks have been made in total. That is a bare number growing by one — no domain, no IP address, no timestamp. It shows that the tool is being used, and nothing else.
Details are in the privacy notice.
Can I pass the result on?
Yes, in three ways: as a PDF report with a cover header, an overview and page numbers, as a text file to attach — or simply pass on the address from your address bar. After a check it contains the domain, and whoever opens it sees the same report.
The PDF is produced in your browser, not on our server. The report about your domain never leaves your device in the first place.
What does it cost?
Nothing. There is no account, no registration and no paywall. We earn from those users who ask us to fix the findings for them — there is nothing more to it.
What is the AI prompt about?
Many people now have a language model explain the work to them and get general answers, because they supply neither their findings nor their environment. The generated brief contains both, together with the instruction to use the DNS values from the report unchanged rather than inventing its own.
Two cautions: never put passwords or keys into an AI tool, and check every DNS record it proposes against the values in this report before you publish it. Language models occasionally invent such values very convincingly.
Found a mistake? Something rated wrongly?
Then please write to us — reports like that are the most valuable thing we can receive: mailampel@mani-it.at
Helpful for us:
- The domain you checked and roughly when you checked it
- What the tool reported and what you would have expected instead
- Ideally the report as a text file — the button for that sits directly below the result
If you would like someone to fix the findings for you, write to office@mani-it.at or call +43 2742 26657.