How can I determine if a company's email is using Gmail or Yahoo under the hood?
Published 11 Jun 2025
Updated 7 Oct 2026
14 min read
Summarize with
Updated on 7 Oct 2026: We added Gmail and Yahoo header-viewing steps and clarified what DNS and authentication can prove about a company's email provider.
Start with the company's MX records. If the domain receives mail through Google Workspace, the MX targets usually include smtp.google.com or legacy hosts such as aspmx.l.google.com. If it receives mail through Yahoo-backed infrastructure, the MX targets often include Yahoo-related hostnames such as yahoodns.net. That answers the receiving side of the question quickly.
The caveat is important: receiving mail and sending mail are different paths. A company can receive mail in Gmail, send marketing mail through another system, and send transactional mail through a third system. To verify the outbound path, inspect SPF, DKIM, and the headers from a real message. Suped's email test workflow gives stronger evidence than DNS alone.
- Fast answer: Look up the MX records for the domain after the @ sign.
- Better answer: Check MX for receiving, then SPF authorization and validated DKIM signatures for sending clues.
- Best evidence: Inspect the trusted headers of a real email and compare them with DNS records.
- Limit: Gateways and white-labeled or self-hosted mail systems can hide the mailbox provider.
Start with the MX record
The MX record tells the internet where to deliver inbound mail for a domain. For example@tkcompany.com, the domain to check is tkcompany.com. Query the exact email domain, including any subdomain, rather than the company website address. If those MX hosts point at Google, Google is the public receiving provider; routing rules can still deliver mail elsewhere. Current setups commonly use smtp.google.com, while domains configured before 2023 can still use legacy aspmx hosts. If the MX hosts point at Yahoo-related mail infrastructure, Yahoo is involved in receiving. Sort the results by priority: a lower number has higher preference, although backup targets can still be part of the same provider. For a deeper MX-only walkthrough, use the MX record guide. Google confirms these current and legacy values in its MX setup instructions.
Basic MX lookupBASH
dig MX tkcompany.com +short host -t MX tkcompany.com nslookup -type=MX tkcompany.com
|
|
|
|
|
|---|---|---|---|---|
MX | Receiving | smtp.google.com or aspmx | yahoodns.net | High for the first inbound hop |
SPF | Allowed senders | include:_spf.google.com | Authorized Yahoo sending infrastructure | Supporting clue, not proof of use |
DKIM | Signing domain | Passing signature; google selector is only a hint | Passing signature checked against the Yahoo route | High for signer, limited for provider |
Headers | Observed SMTP hops | Google mail hosts | Yahoo mail hosts | High for trusted, recorded SMTP peers |
Use these signals as clues, then confirm with message headers when the answer matters.
Do not overread MX records
MX records identify the first public destination for inbound mail. They do not always expose the mailbox behind a gateway, and they do not prove where every outbound email was sent from. A domain can receive in Gmail and still send newsletters, invoices, support replies, and password resets through separate systems.
When MX points to a gateway
An inbound security or forwarding layer can own the public MX record while delivering accepted mail to a mailbox system such as Google Workspace or Yahoo-backed mail. In that setup, an MX lookup identifies the front door, not the final mailbox. Public DNS often cannot reveal the next hop. Split delivery can also route different recipients at the same domain to different mailbox systems, so a domain-wide label does not prove where one employee reads mail.
- Name the visible layer: Report the MX provider as the inbound gateway rather than the mailbox host.
- Check a sent message: Trusted Received fields can expose the system that submitted outbound mail. This identifies the sending route, not the final inbound mailbox.
- Use administrative evidence: If you control the domain, review the gateway's delivery route and mailbox configuration.
- Keep uncertainty explicit: Label the mailbox provider as unknown when the evidence stops at the gateway.
Avoid recipient probing
Testing whether a provider accepts a guessed recipient over SMTP is unreliable and can disclose account-enumeration behavior. Catch-all routing and delayed or directory-protected rejection can produce false results. Use a controlled mailbox you own if an SMTP acceptance test is operationally necessary.
Separate receiving mail from sending mail
Split the question of whether a company uses Gmail or Yahoo under the hood into two parts. First, where does the company receive mail? Second, where did a specific message come from? The first answer lives mostly in DNS. The second answer lives mostly in the message headers.
A custom company domain hosted by Google Workspace is business email, even though its inbox uses Gmail. An address ending in @gmail.com or @yahoo.com identifies the consumer email domain, not whether its owner uses it for work. The Gmail app also supports non-Gmail accounts, as Google's account setup documentation explains, so the app alone does not identify the email host. The website host and domain registrar do not establish who hosts its mail.
Receiving provider
This is the mail host that accepts inbound messages for the domain. It is usually visible in MX records, although a gateway can hide the mailbox behind it.
- Where to look: DNS MX records.
- Strong clue: Provider-owned MX hostnames.
- Common limit: Gateways and white-labeled hostnames hide the mailbox provider.
Sending provider
This is the system that transmitted a specific message. It is visible in trusted headers, SPF results, DKIM signatures, and sometimes reverse DNS.
- Where to look: Message headers and authentication results.
- Strong clue: Recipient-added Received lines and DKIM signing domains.
- Common limit: Multiple senders share the same domain.
Email provider lookup workflow using MX records, SPF, message headers, and reverse DNS.
Check SPF, DKIM, and message headers
SPF authorizes sending IP addresses for the envelope-sender domain, normally shown in Return-Path, rather than necessarily the visible From domain. If a company authorizes Google to send, the SPF record often contains include:_spf.google.com. Google's SPF documentation uses that include for Workspace sending. Yahoo-related authorization is another supporting clue. SPF is useful, but it is not a clean inventory. Old systems stay in SPF long after they stop sending, and broad includes do not prove current use. For a specific message, query the domain in the trusted smtp.mailfrom result; RFC 7208 defines this MAIL FROM identity.
A validated DKIM signature identifies the signing domain for a specific email. The domain in the d= tag and the selector in s= locate its public key at selector._domainkey.signing-domain. A Google Workspace message can have the company's own domain in d=, and any provider can use a selector named google. Neither value alone proves the sending provider. Check DKIM selectors using the actual signature values, then compare the recipient's DKIM result with the trusted Received fields. RFC 6376 defines the signing domain and selector lookup. For more header detail, use this header analysis guide.
Read the trace from the topmost Received field added by your receiving system and work downward only through servers you trust. A sender can insert fake lower Received or Authentication-Results fields before transmission. Give the recipient-generated Authentication-Results field more weight than sender-supplied copies. Forwarding can add hops or break authentication, so compare the trusted route with SPF and DKIM rather than relying on one line. Check the SMTP peer IP recorded by a trusted receiver against provider-owned networks; a claimed hostname alone is insufficient.
SPF and DKIM DNS lookupsBASH
dig TXT tkcompany.com +short host -t TXT tkcompany.com nslookup -type=TXT tkcompany.com # DKIM example: d=tkcompany.com and s=google dig TXT google._domainkey.tkcompany.com +short
Illustrative header clues, not a complete messageTEXT
Authentication-Results: mx.example; spf=pass smtp.mailfrom=tkcompany.com Authentication-Results: mx.example; dkim=pass header.d=tkcompany.com header.s=google Received: from mail-yb1-f170.google.com by mx.example DKIM-Signature: v=1; a=rsa-sha256; d=tkcompany.com; s=google;
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Trusted header evidence beats assumptions
For a real message, trust the recipient-added authentication results and Received fields more than a technology profile or an old SPF include. Those fields show the observed SMTP path for that message. DNS shows what the domain permits or where inbound mail is routed.
Find the full headers in Gmail or Yahoo Mail
Inspect a message received from the company, rather than a copy in its Sent folder. Use a desktop browser to open the full email headers; the normal sender details hide most routing information.
- In Gmail, open the message, select More beside Reply, then choose "Show original". Copy the full header text and review the SPF and DKIM results.
- In Yahoo Mail, open the message, select More options, then choose "View Raw Message". The header fields appear above the message body.
Google's header instructions cover both menus. Gmail's "mailed-by" and "signed-by" are SPF and DKIM domain clues, as its authentication guidance explains; they do not establish the final mailbox host. Google's DKIM instructions also explain checking the recipient's copy. Use trusted Received fields to identify the observed sending route.
Investigate custom or self-hosted MX targets
Some companies use custom MX hostnames, old on-premises servers, or white-labeled providers. In those cases, the first MX lookup gives a domain that looks like the company itself, not Google or Yahoo. Check the IP addresses behind those MX hosts, then inspect reverse DNS, network ownership, SMTP banners, and TLS certificate names. These are supporting clues, not proof, because hosted infrastructure can share IP ranges and generic certificates.
Deeper MX investigationBASH
dig MX tkcompany.com +short dig A mx1.tkcompany.com +short dig AAAA mx1.tkcompany.com +short dig -x 203.0.113.10 +short openssl s_client -connect mx1.tkcompany.com:25 -starttls smtp
Confidence levels for provider identification
Assess the receiving hop and sending route separately; confirming either does not prove the final mailbox host.
Confirmed
Strong agreement
Provider-owned routing evidence confirms the receiving hop or sending route being assessed; final mailbox claims need account or delivery-route evidence.
Likely
Multiple matches
Several independent clues point to the same route, but direct routing or account evidence is unavailable.
Unclear
Single weak clue
Only SPF, one hostname, or another indirect signal points to the provider.
Unknown
Conflicting evidence
A gateway hides the mailbox, or custom hosts and stale records conflict.
- Resolve hosts: Turn each MX hostname into A and AAAA addresses.
- Check rDNS: Reverse DNS often exposes the operating network or mail cluster name.
- Review banners: SMTP banners sometimes reveal hosted mail software or gateway branding.
- Check TLS: Certificate names can expose provider-owned infrastructure.
Common Google and Yahoo clues
Google Workspace is usually straightforward. Google's current setup uses the single MX target smtp.google.com. Domains that started using Workspace before 2023 can still have the legacy set containing aspmx.l.google.com and alternate Google MX hosts. Working legacy records do not need to be changed just for identification. Outbound messages sent through Google often include Google hostnames in trusted Received lines, and DKIM selectors commonly use names such as google when the default selector remains in place. Google's DKIM documentation identifies google as the default selector and allows a different selector, so its name is a clue rather than proof.
Yahoo clues need more context for a custom company domain. Yahoo-backed business mail can use a Yahoo Mail interface and endpoints such as smtp.bizmail.yahoo.com, while public MX records can contain mx-biz and yahoodns.net. The business account can be administered under a different customer-facing brand, so describe the evidence as Yahoo-backed infrastructure unless the account or routing configuration confirms who provides the mailbox service. Do not use the absence of custom-domain DKIM to rule out Yahoo-backed mail; available DKIM controls depend on the business-mail service. The presence or absence of an exportable private key does not establish whether a message has a valid DKIM signature.
Illustration of Google Admin console routing with legacy Google Workspace MX hostnames.
Google clues
- MX clue: The target is smtp.google.com or a legacy aspmx host.
- SPF clue: The domain authorizes Google sending hosts.
- Header clue: Trusted Received lines include Google mail hostnames.
Yahoo clues
- MX clue: The hostname contains mx-biz and yahoodns.net.
- SPF clue: The domain authorizes Yahoo-related sending hosts.
- Header clue: Trusted routing fields point at Yahoo mail systems.
Use Suped for your own domains
For a one-off lookup against someone else's domain, DNS and trusted headers are usually enough. For domains you control, Suped's product collects DMARC reports, maps reported sending sources, checks SPF and DKIM results, and alerts on configuration drift. That workflow shows which sources participating receivers report sending as your domain, including traffic that fails authentication. It complements the MX lookup rather than inferring a mailbox provider from DMARC data.
That matters when a domain uses several senders. Suped shows which sources pass authentication, which ones are failing authentication, and what to fix next. A domain health check is a useful first pass, then ongoing DMARC monitoring catches drift as teams add new senders.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Practical Suped workflow
- Add domain: Add the domain you control and configure the Suped reporting address in its DMARC rua tag.
- Review sources: Identify reported sources and confirm which senders your organization authorizes.
- Fix failures: Use issue detection and clear steps to resolve authentication gaps.
- Set alerts: Watch for a new sender that breaks SPF, DKIM, or DMARC.
Identify email providers in bulk
Manual DNS checks work for one domain. They become slow when you need to classify a list of accounts, leads, partners, or customer domains. Keep the logic simple: extract the domain, query MX, group obvious providers, then review the unknowns manually. Normalize domains to lowercase and record the lookup time so duplicate casing and later DNS changes do not distort the results.
Bulk MX lookup from email addressesBASH
awk -F@ 'NF == 2 {gsub(/^[[:space:]]+|[[:space:]]+$/, "", $2); print tolower($2)}' emails.txt | sort -u > domains.txt while IFS= read -r domain; do printf '%s ' "$domain" dig MX "$domain" +short | sort -n | tr '\n' ' ' printf '\n' done < domains.txt > mx-results.txt
For bulk work, do not treat every SPF include as proof. Use SPF to enrich the answer, not to replace the MX result or a real header sample. A stale SPF record can make a company look like it still uses a provider that has been gone for years. Keep gateway-only results separate from confirmed mailbox providers. The script assumes one plain email address per line. An empty result from dig +short does not distinguish missing MX records from a failed query; rerun without +short to inspect the DNS status before assigning a provider.
|
|
|
|
|---|---|---|---|
1 | Extract domain | Unique list | Aliases |
2 | Query and sort MX | First inbound hop | Gateway or white-label |
3 | Query SPF | Allowed senders | Stale data |
4 | Sample trusted headers | Observed route | No sample |
A compact workflow keeps bulk provider classification accurate enough for practical use.
Views from the trenches
Best practices
Check MX first, then use SPF and headers to confirm sender-specific routing evidence.
Resolve hidden MX hosts to IPs, then inspect rDNS, network owner, banner, and TLS names.
Use header samples for outbound claims because DNS alone cannot prove each message path.
Keep bulk lookups grouped by domain so duplicate addresses do not distort provider counts.
Common pitfalls
Treating SPF as a live sender inventory creates false positives when old includes remain.
Assuming custom MX names are self-hosted misses white-labeled providers behind the hosts.
Reading MX as outbound proof confuses receiving mail with campaign or transactional sending.
Stopping at the first hostname leaves inconclusive cases unresolved when routing is layered.
Expert tips
Classify certainty levels so reports separate confirmed providers from reasonable guesses.
For unknown hosts, connect to SMTP and compare banner text with the certificate subject.
Save the raw DNS and header evidence beside each provider label for later audit checks.
Refresh provider mappings because mail routing changes faster than most CRM records do.
Marketer view
Marketer from Email Geeks says MX records are the fastest first check for seeing where a company receives mail.
2024-06-12 - Email Geeks
Marketer view
Marketer from Email Geeks says SPF can show authorized sending systems, but stale records make it a weak source on its own.
2024-06-12 - Email Geeks
Record the provider and supporting evidence
Record the receiving provider, the sending provider observed in your sample, and the evidence for each. Save the MX results and lookup time alongside the trusted header fields. Label a gateway as a gateway and leave the final mailbox unknown until account settings or delivery routes confirm it. Refresh the lookup after a migration or DNS change; a previous Google or Yahoo result is not permanent.
