Email Reputation Explained: What MX, SPF and DMARC Reveal About Any Address
· 7 min read
A syntactically valid email address tells you almost nothing. j.smith@example.com and j.smith@xk3v9.top both pass every regex ever written. The difference between them lives in DNS: one domain has been set up by people who intend to send and receive mail for years, and the other was registered last Tuesday and will be gone by Friday. This guide explains the handful of DNS records that reveal which is which, how they combine into an email reputation score, and what to do with the result.
Two kinds of "email reputation"
The phrase is used for two different things. Sender reputation is what Gmail or Microsoft think of your outgoing mail server — complaint rates, spam-trap hits, bounce history. It is invisible to outsiders and takes months to build. Domain reputation, the subject here, is what anyone can learn about an address from public DNS records in under a second, without sending a single message. It answers a simpler question: does this domain look like it belongs to a real, maintained mail system?
Signal 1: MX records — can the domain receive mail at all?
A mail exchanger (MX) record names the servers that accept incoming mail for a domain. It is the single most important check. A domain with no MX records is, for practical purposes, undeliverable: your confirmation email, receipt and password reset will all bounce. (Technically, a sending server may fall back to the domain's A record, but almost no legitimate organization relies on that, and treating it as a weak partial credit is the right call.)
The MX record also tells you who handles the mail. aspmx.l.google.com means Google Workspace; *.mail.protection.outlook.com means Microsoft 365. Both imply a paying organization behind the domain. Conversely, disposable-email providers often route hundreds of throwaway domains to the same one or two mail servers, so a shared MX is a strong tell even for a domain too new to appear on any blocklist.
Signal 2: SPF — has anyone declared who may send?
Sender Policy Framework is a TXT record at the domain root that lists the servers authorized to send mail on its behalf:
v=spf1 include:_spf.google.com -all
SPF was designed to stop forgery, but as a reputation signal it means something else: someone took the time to configure outbound authentication. A domain with working MX and no SPF record is either very carelessly run or was never meant to send mail — both common among throwaway and fraud domains. The strictness matters slightly too: -all (hard fail) shows more intent than ~all (soft fail) or the meaningless +all.
Signal 3: DMARC — the maturity indicator
Domain-based Message Authentication, Reporting and Conformance is a TXT record at _dmarc.example.com that tells receivers what to do when SPF or DKIM checks fail, and where to send reports:
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
DMARC is the strongest maturity signal of the three because it is the one most organizations skip. Publishing it requires understanding SPF and DKIM alignment, and moving from p=none to p=quarantine or p=reject requires actually monitoring the reports. A domain that has done this work is overwhelmingly likely to be a real business. A domain registered for one signup campaign never will.
You may wonder why DKIM itself isn't on this list. DKIM public keys live under a selector chosen by the sender (selector1._domainkey.example.com), and without seeing a message you cannot know the selector name. DMARC presence is the practical proxy: nobody publishes a DMARC policy without DKIM behind it.
Signal 4: Disposable-provider lists
Community-maintained lists track hundreds of thousands of domains belonging to temporary-inbox services. They are indispensable and they are never finished — providers rotate domains weekly precisely because businesses block them, so a list that isn't refreshed continuously decays fast. We covered the mechanics in how to spot disposable email addresses. For reputation purposes, a disposable match is close to decisive: whatever else the domain has configured, the address will not be read tomorrow.
Signal 5: The local part and the provider type
Everything above concerns the domain. Two facts about the part before the @ also matter:
- Role-based addresses (
info@,admin@,sales@,noreply@) belong to a function, not a person. They are perfectly legitimate for a B2B contact form and a poor fit for a personal account signup, so they deserve a modest penalty rather than a block. - Free providers (Gmail, Outlook, Yahoo, Proton and the like) are fully authenticated and highly trusted at the domain level, but the domain says nothing about the individual — anyone can register one in a minute. Worth flagging as informational so downstream logic can ask for more if the action is sensitive.
Putting it together: how the score is built
Our email checker resolves all of these live and combines them into a 0–100 trust score, higher meaning more trustworthy. The weighting reflects how much each signal actually says:
- Deliverability (up to 40): working MX records earn the bulk of it; an A/AAAA record on the bare domain adds a small amount.
- Authentication (up to 40): a valid SPF record and a published DMARC policy, with DMARC weighted a little more heavily for the reasons above.
- Reputation (up to 20): not appearing on the disposable-domain list.
Then come the modifiers that a simple sum would get wrong. A disposable match caps the score at 18 regardless of how good the DNS looks — some temporary-mail services do publish SPF, and it changes nothing about the address's lifespan. No MX caps the score at 30, because authentication records on an undeliverable domain are irrelevant. A role-based local part subtracts 10.
The result maps to four ratings:
- Trusted (80–100): MX, SPF and DMARC all present, not disposable. Major providers and well-run business domains.
- Good (55–79): deliverable and partly authenticated — typically a real organization that has SPF but never got around to DMARC, or a role address at an otherwise trusted domain.
- Questionable (30–54): deliverable but unauthenticated, or a well-configured domain with a role account. Treat with caution.
- High-risk (0–29): disposable, undeliverable, or both.
Three worked examples
- A Gmail address: MX at Google, SPF and DMARC published, not disposable. Trusted, with a free-provider note. The domain is impeccable; the person is unknown.
- A small business domain: MX at Microsoft 365, SPF present, no DMARC record. Lands in the good band. Real company, imperfect mail hygiene — extremely common.
- A temporary-inbox domain: MX shared with two hundred sibling domains, maybe even an SPF record, listed as disposable. Capped in the high-risk band no matter what else it has.
What to do with each rating
The right response is graded, not binary. Accept trusted and good addresses without friction. For questionable ones, require the confirmation email to be clicked before unlocking anything valuable, and consider pairing the email signal with the IP fraud score of the signup connection: an unauthenticated domain from a residential connection is probably a small business; the same domain from a datacenter proxy probably isn't. For high-risk addresses, either reject at signup with a clear message or allow the account but withhold trials, credits, referral payouts and publishing rights until a reachable address is on file.
Turn it on yourself first
The same checks are a two-second audit of your own domain, and the findings cut both ways. If your domain scores "good" instead of "trusted" because DMARC is missing, that gap is also hurting your deliverability to Gmail and Yahoo, both of which now require DMARC from bulk senders. The fix is incremental: publish v=DMARC1; p=none; rua=mailto:you@yourdomain, watch the aggregate reports for a few weeks to catch legitimate senders you forgot about, then move to p=quarantine and finally p=reject. You can confirm each record change has propagated using the DNS lookup tool, which queries TXT records from resolvers around the world.
What domain reputation cannot tell you
Be honest about the limits. None of these checks prove that a specific mailbox exists — that requires an SMTP-level verification, and many domains are configured as catch-alls that accept everything anyway. They say nothing about whether the human is who they claim to be. And a trusted domain can host a compromised account. Domain reputation is the fast, free, first filter, and it is very good at that job; it is not the last word.
Try it with any address or bare domain in the email checker, or call the same check from your own signup flow through the API. The response includes the score, the rating, the per-category breakdown and each individual check, so your code can act on the reason and not just the number.