MXMole
Comics Glossary

Free · No sign-up

Need a real answer?

Check a domain while you’re here.

MXMole will review the public DNS and email records that matter—no account needed.

MXMole glossary

What those mail DNS records actually do.

A practical guide for the person who owns the domain and the person who has to troubleshoot it. Start with the plain-English answer, then open the technical detail when you need it.

MXMole reads public DNS and registry data as it exists right now. That is useful evidence, not a promise that every message will be delivered or authenticated exactly as expected.

Where email goes

Routing and DNS

These records make a domain findable and tell other mail systems where to deliver its email.

NS

Nameservers

In plain English: Nameservers are the source of truth for a domain's public DNS. They are the address book other systems ask when they need to find the domain's email or website settings.

Why MXMole checks it: If the wrong nameservers are delegated, the right mail records may exist somewhere but the internet will never see them.

Technical detail

The parent zone delegates a domain to authoritative nameservers. Recursive resolvers follow that delegation to retrieve MX, TXT, and other records. Editing records at a provider that is not authoritative for the domain has no public effect. DNS caching and TTL values can delay when a legitimate change becomes visible.

MX

Mail exchanger records

In plain English: MX records tell the rest of the internet which mail servers accept email for the domain.

Why MXMole checks it: A missing, malformed, or unexpected MX record can send mail to the wrong place or prevent normal delivery.

Technical detail

Each MX record has a numeric preference; lower numbers are tried first. An MX record points to a hostname, which then resolves to an IP address. SMTP has an address-record fallback when no MX exists, but business domains normally publish explicit MX records. MXMole also uses recognizable MX patterns only as a provider hint, not proof of ownership or configuration.

Who is allowed to send

Email authentication

These controls help receiving providers decide whether a message claiming to be from a domain is legitimate.

SPF

Sender Policy Framework

In plain English: SPF is a public list of systems allowed to send email for a domain. It helps a recipient spot a mail server that should not be using that domain.

Why MXMole checks it: A duplicate, broken, or overgrown SPF policy can cause legitimate mail to fail authentication or leave an easy opening for spoofing.

Technical detail

An SPF policy is a TXT record beginning with v=spf1. The recipient compares the sending IP address against mechanisms such as ip4, include, a, and mx. SPF evaluation is limited to ten DNS-triggering terms; includes and redirects can add nested lookups. SPF evaluates the envelope sender or HELO identity, not automatically the address a person sees in the From line.

DKIM

DomainKeys Identified Mail

In plain English: DKIM adds a cryptographic signature to a sent message. The recipient can look up a public key in DNS to check that the message was signed by an authorized system and was not changed afterward.

Why MXMole checks it: DKIM is one of the main ways legitimate mail earns trust, but the public key must be published at the selector the sender actually uses.

Technical detail

DKIM keys live at hostnames such as selector._domainkey.example.com. The selector is chosen by the sending platform, so it cannot be discovered reliably from the domain alone. Many providers publish DKIM through CNAME records. Finding a key means DNS is ready for that selector; it does not prove every application signs mail, that the selected key is in current use, or that a selector MXMole did not probe is absent.

DMARC

Domain-based Message Authentication

In plain English: DMARC tells receiving providers how a domain wants suspicious mail using its visible From address handled. It also gives the domain a way to receive aggregate reports.

Why MXMole checks it: DMARC turns SPF and DKIM results into a policy tied to the brand a recipient sees. It is often the clearest anti-spoofing control a domain owner can publish.

Technical detail

DMARC is a TXT record at _dmarc.example.com. It passes when SPF or DKIM passes and aligns with the visible From domain. The p tag commonly uses none for monitoring, quarantine for suspicious handling, or reject for refusal. Reporting destinations are usually specified with rua. Receiving providers apply their own policy and fraud controls, so publishing DMARC does not guarantee identical handling everywhere.

BIMI

Brand Indicators for Message Identification

In plain English: BIMI lets a domain describe a brand logo that participating inboxes may show beside authenticated mail.

Why MXMole checks it: It is useful brand and authentication context, but it is optional. A missing BIMI record is not an email outage or a mail-security failure.

Technical detail

A BIMI TXT record is commonly published at default._bimi.example.com and can point to a logo and, where required, a verified mark certificate. Major mailbox providers set their own eligibility rules; many require an enforced DMARC policy and may require a certificate. Publishing a BIMI record does not guarantee a logo will appear in every inbox.

How mail travels

Optional transport protection

These records help participating mail servers use and report encrypted SMTP delivery. They are valuable, but optional.

MTA-STS

Mail Transfer Agent Strict Transport Security

In plain English: MTA-STS tells supporting senders to use a valid encrypted connection when they deliver mail to the domain, instead of quietly falling back to an insecure connection.

Why MXMole checks it: It adds a useful safeguard against TLS downgrade and certificate problems during server-to-server mail delivery, but its absence is informational rather than a failure.

Technical detail

The DNS record lives at _mta-sts.example.com; the policy itself is fetched over HTTPS from mta-sts.example.com. A policy can list accepted MX hosts and use modes such as testing or enforce. MXMole detects the published DNS signal; a full MTA-STS validation also involves the HTTPS policy and the sending provider's support for the standard.

TLS-RPT

SMTP TLS Reporting

In plain English: TLS-RPT asks participating mail providers to send reports when encrypted server-to-server delivery succeeds or runs into trouble.

Why MXMole checks it: It can reveal certificate, encryption, or policy issues that are otherwise hard to see. It does not itself encrypt email or block a message.

Technical detail

The DNS record is normally published at _smtp._tls.example.com and begins with v=TLSRPTv1. Its rua destination receives aggregate JSON reports. TLS-RPT is especially useful alongside MTA-STS or DANE, but it only produces information when the sending provider supports reporting and has something to report.

Helpful context, not a verdict

Provider and registration context

These details help with troubleshooting, but they are not part of MXMole's mail-posture decision.

HINT

Provider inference

In plain English: MXMole can sometimes recognize a mail or DNS provider from public record patterns, such as Microsoft 365, Google Workspace, Cloudflare, or Route 53.

Why it helps: Knowing who likely hosts a record makes it easier to find the right admin console and documentation.

Technical detail

This is pattern matching, not a definitive inventory. A company can use one provider for DNS, another for incoming mail, and several services for outbound mail. A recognized hostname is a useful lead, not proof that an organization owns an account with that provider or that the provider controls every related setting.

RDAP

Domain registration

In plain English: Registration details describe when a domain was created and, when the registry shares it, when it may expire.

Why MXMole checks it: An approaching expiration date can be a practical risk for a business domain, but it says nothing by itself about whether mail records are configured correctly.

Technical detail

MXMole uses public Registration Data Access Protocol (RDAP) services for available dates. Registries differ in what they publish, and missing dates are simply unavailable information. Registration expiration, transfer locks, nameserver delegation, and email authentication are related operational concerns, but they are separate systems.