Getting Started

Mailrecord checks the published DNS records for a domain and tells you what they declare. There is no account, no sign-up, and nothing to install.

  1. Go to the App page No login or account required. The tool is ready to use immediately.
  2. Type a domain name and press Check Enter any domain — yours, a service you use, or one you are investigating. Mailrecord looks up MX, SPF, and DMARC records in parallel.
  3. Read the structured report Each record type shows the raw DNS value, a plain-language explanation, and a status badge — present if a record was found, absent if no record exists for that type.
  4. Optionally check DKIM selectors Enter comma-separated selector names (e.g. google, selector1, 2024). DKIM selectors are not discoverable — only the selectors you provide are checked. The tool never reports "no DKIM" for selectors it did not look up.

Frequently Asked Questions

Does Mailrecord actually send or receive email?

No. Mailrecord never sends, receives, or tests mail delivery. It only reads published DNS records — MX (where mail should go), SPF (who is authorised to send), DMARC (what to do if authentication fails), and DKIM (cryptographic signing keys). A valid DNS record does not guarantee mail is accepted or delivered. Mailrecord reports what a domain has told the internet about its mail, not how mail actually flows.

My SPF record shows a lookup count near the limit — should I worry?

The SPF standard limits the number of DNS lookups a receiver must perform to 10. Every include:, a:, mx:, ptr:, and exists: mechanism counts toward this limit. a and mx count as one lookup each; include: counts as one lookup plus all lookups inside the included record. If the total exceeds 10, receiving mail servers may stop evaluating the SPF record — treating it as a permanent error (permerror) — which causes some receivers to reject mail and others to accept it without SPF authentication. Mailrecord counts these lookups and reports the number against the limit. If your count is 9 or 10, review whether every include: is still needed, and consider replacing redundant mechanisms.

My DMARC policy is p=none — is my domain protected?

No. A DMARC policy of p=none tells receiving servers to take no action when an email fails SPF and DKIM authentication. It is a monitoring-only mode. The domain publishes DMARC reports so the owner can see who is sending mail claiming to be from the domain, but it does not prevent unauthenticated mail from reaching inboxes. Real protection requires p=quarantine (send failures to spam) or p=reject (block failures outright). Most organisations start with p=none, monitor for a period, then tighten the policy once they are confident legitimate mail passes authentication. Mailrecord reads the published policy and tells you what it enforces — never reports the presence of a DMARC record as protection.

The tool says "lookup failed" or "no response" for SPF or DMARC — what happened?

Mailrecord reports what is published in DNS. When a lookup fails, the tool tells you which record could not be checked and that it is a resolver issue — not a finding about your domain. Possible causes: a temporary DNS outage at the authoritative nameserver, a network issue between the server and the resolver, or the resolver being unreachable. A lookup failure is different from "record not found" (NXDOMAIN). If a lookup fails, try again in a few minutes. If it persists, check that the domain's authoritative nameservers are responding correctly with a tool like dig from the command line.

How do I check DKIM selectors? I don't know my selector names.

DKIM selectors are not discoverable from DNS — there is no standard way to enumerate them. You need to know the selector names your mail provider or email-sending service uses. Common selectors: google (Google Workspace), selector1 / selector2 (Microsoft 365), s1 / s2 (many providers), or a year-based selector like 2024. Your provider's documentation should list the selectors they use. If you are not sure, ask your email provider or check their DKIM setup guide. Mailrecord checks only the selectors you enter and never guesses or enumerates — absence of a lookup is not absence of a key.

Can I buy the Pro plan now?

Not yet. The Pro plan — which will include batch domain checks (up to 10), programmatic API access, higher rate limits, and historical comparison of DNS results — is planned but not available. There is no payment processor, no account system, and no billing infrastructure in this fleet. See the Pricing page for details on what is planned. There is no timeline set for launch. When Pro becomes available, the site will be updated.

Known Limitations

Mailrecord is a straightforward DNS reading tool with honest constraints. The following are not bugs — they are deliberate design boundaries:

Contact Us

Help and support is maintained by the operator. At this time, support is not reachable by email — there is no mailbox configured for any domain in this fleet, and no contact form that would silently discard your message.

If you have found a bug, have a feature request, or need to ask a question:

Important: We do not have a working email address, contact form, or any way to receive messages from users today. This is documented as a known gap. If you attempt to send email to any address on this domain, it will not be received. We will update this section as soon as a support channel is available.