MX Record Lookup
Look up mail servers, check SMTP reachability, and verify SPF, DMARC & DKIM authentication records for any domain — free and instant.
Why Email Authentication Is Critical
Email spoofing costs businesses billions annually. Without SPF, DMARC, and DKIM configured correctly, your domain can be impersonated in phishing attacks — damaging your reputation and putting your customers at risk.
The email authentication trio:
- SPF: Declares which servers are allowed to send on your behalf. Stops unauthorized senders at the source.
- DKIM: Cryptographically signs emails so recipients can verify authenticity and detect tampering.
- DMARC: Ties SPF and DKIM together with a policy (reject/quarantine) and provides reporting on who sends email using your domain.
All three must be properly configured for Google and Yahoo's bulk sender requirements (2024), which mandate SPF, DKIM, and DMARC for domains sending over 5,000 messages/day.
Reading the MX results
MX records are listed with a priority (lower = preferred) and a hostname. From that set you can usually infer the mail provider — for example, aspmx.l.google.com means Google Workspace, and *.mail.protection.outlook.com means Microsoft 365.
- Single MX, priority 10: typical minimal setup — fine but offers no fallback if the primary host goes down.
- Multiple MX with different priorities: redundancy — lower values are tried first.
- Null MX (
0 .): explicitly declares the domain does not accept mail; RFC 7505 compliant.
Common issues and fixes
- No MX records returned: check whether the domain uses a CNAME at the apex, which is invalid — MX must resolve to an A/AAAA record, not another CNAME.
- All priorities equal: defeats redundancy; clients will pick one at random. Use distinct values like 10, 20, 30.
- MX points to a non-existent host: delivery fails silently; verify every target resolves to a mail-capable A record.
- MX target uses a CNAME: RFC 2181 forbids it; some servers still work, many reject — replace with an A record.
- Provider lookup shows wrong vendor: old Google Apps or Office 365 records left after migration; remove stale entries to avoid split delivery.
What to do next
Pair the MX audit with SPF, DKIM, and DMARC checks — a healthy MX alone does not guarantee deliverability. Add a secondary MX with a higher priority for queueing during primary outages.
For continuous monitoring, FlashMon.app tracks changes automatically and alerts you the moment something breaks.
Monitor your email infrastructure
Get alerts when MX records change, SMTP goes down, or authentication records are misconfigured.
Frequently Asked Questions
An MX (Mail Exchanger) record is a DNS record that specifies which mail servers are responsible for accepting incoming email for a domain. When someone sends an email to [email protected], the sender's mail server queries the DNS for example.com's MX records to find out where to deliver the message. Each MX record has a priority number — lower numbers have higher priority. If the primary mail server is unreachable, the sending server tries the next one in ascending priority order.
SPF (Sender Policy Framework) is a DNS TXT record that lists which IP addresses and mail servers are authorized to send email on behalf of your domain. Without SPF, anyone can spoof your domain's "From" address and send phishing emails that appear to come from you. Receiving mail servers check the SPF record and can reject or mark as spam any email sent from an unauthorized server. A typical SPF record looks like: v=spf1 include:_spf.google.com ~all
DMARC (Domain-based Message Authentication, Reporting & Conformance) builds on SPF and DKIM to tell receiving servers what to do with emails that fail authentication. The policy field (p=) can be set to "none" (monitor only), "quarantine" (send to spam), or "reject" (block entirely). DMARC also provides a reporting mechanism (rua= and ruf= tags) so you receive aggregate and forensic reports about who is sending email using your domain — a critical tool for detecting spoofing attempts.
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing emails. The sending mail server signs each email with a private key, and the public key is published as a DNS TXT record under a "selector" subdomain (e.g., google._domainkey.example.com). Receiving servers verify the signature using the public key. Unlike SPF — which only checks the sending server's IP — DKIM proves the message content hasn't been tampered with in transit. Both are needed for strong email security.
Many hosting providers and ISPs block outbound port 25 to prevent spam from compromised servers. Mail servers that have port 25 closed in our check may still receive email if they accept connections from other mail servers via a different network path or if our probe is blocked by a firewall. A closed SMTP result from one origin doesn't necessarily mean the server is down — it means it's not reachable via port 25 from our infrastructure. Mail servers often also accept connections on port 587 (submission) or 465 (SMTPS).
MX records and email authentication configurations change less frequently than HTTP status, but when they do change unexpectedly — a misconfigured SPF after migrating email providers, an expired DKIM key, or MX records pointing to a decommissioned server — email delivery fails silently and the impact can last days before being noticed. FlashMon continuously monitors your MX records and alerts you immediately when they change or when SMTP becomes unreachable, preventing prolonged email outages.