Recommended Free Tools
When a client says your email bounced, save the complete bounce notice before changing DNS. Its SMTP status and diagnostic text help identify whether the problem involves incoming-mail routing, sender authentication, or something else. Then compare the domain’s live records with the current instructions for the mail host and every service that sends mail for you.
Start with the bounce notice, not a DNS edit
Keep the full non-delivery report (NDR) or bounceback, including its SMTP status code and diagnostic text. Record the affected recipient, recipient’s mail provider, time, and the system that sent the message. These details help distinguish an authentication or DNS problem from a recipient policy rejection or another delivery failure. Google explains how to interpret common bounce messages in its bounce guidance; Microsoft’s authentication troubleshooting guide covers checks for Microsoft 365.
DNS can contribute to a rejection, but it is not the cause of every bounce. Recipient policy, sender reputation, message formatting, transport security, and sending-service configuration can also matter. A DNS checker may show a record problem; it cannot by itself explain every receiver-side rejection or guarantee inbox placement.
Identify which part of email delivery is failing
Incoming and outgoing mail use different DNS records and checks. Microsoft’s mail-flow overview describes MX, SPF, DKIM, and DMARC as important components of mail delivery and authentication.
Free tools Windows power users keep installed
One-click scans. No signup required.
#1 Best Overall
- MX: Directs incoming mail for a domain to its mail host. If people cannot send messages to your domain, verify MX against the current instructions from that host.
- SPF: Identifies sending sources authorized by a domain’s SPF policy. It is relevant when mail sent on your behalf is rejected or fails authentication.
- DKIM: Lets receiving systems check a signature on a message against a public key published in DNS. The sending platform must sign the message, and the relevant selector record must be available.
- DMARC: Tells receiving systems how to handle messages that fail its authentication requirements. It depends on a passing SPF or DKIM result aligned with the domain shown in the message’s visible From address.
For outbound problems, check the sending domain’s SPF, the DKIM selector used by the sending service, and DMARC. Exact record names and values depend on the provider and configuration; use that provider’s current setup instructions rather than copying a generic record.
Check SPF after adding or changing a sender
A newly adopted CRM, marketing platform, ticketing system, or website form can expose a missing sender in SPF. A message can also fail SPF checks if the record is malformed or the domain has multiple SPF records. Microsoft’s troubleshooting guide identifies missing authorized senders, multiple SPF records, and exceeding SPF’s 10-DNS-lookup limit as common issues.
Rank #2
- Look for one SPF record for the domain, not a separately added SPF record for each service.
- Compare the record with current instructions from every service authorized to send as the domain. Add a service only using its current SPF guidance.
- If an SPF result reports a lookup-limit error, review the record and its included mechanisms against Microsoft’s guidance; do not try to fix it by blindly appending another record.
“SPF check returns permerror” is useful wording to pass to your mail administrator or provider, but the exact cause needs to be read alongside the bounce and the live SPF record.
Check DKIM signing and DMARC alignment
Confirm DKIM is published and used
Check that the selector record required by the sending platform exists and that its published public key matches the service’s current instructions. Then confirm that the platform is signing the mail. If an intermediary alters signed message content, the signature may no longer validate.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Check the relationship between authentication and the From address
A passing SPF or DKIM result does not automatically mean DMARC passes. DMARC needs at least one of those mechanisms to pass with a domain aligned to the visible From domain. For example, a third-party sender may authenticate its own envelope domain successfully while that domain does not align with the address recipients see. When investigating a “DMARC fails due to domain misalignment” report, compare the authenticated domains in the message results with the visible From domain, not just whether SPF or DKIM shows pass.
Apply provider-specific requirements carefully
Requirements are not identical for every recipient provider. Google’s published sender guidelines apply to messages sent to personal Gmail accounts. For senders delivering more than 5,000 messages per day to Gmail, Google requires SPF, DKIM, and DMARC, with alignment requirements for direct mail among its other rules. That threshold is specific to Google’s Gmail guidance; it is not a universal sending limit for all providers.
Rank #4
The same Google guidance advises keeping spam rates below 0.10% and avoiding a rate of 0.30% or higher. Those figures are Gmail sender guidance, not DNS-record health thresholds. A technically correct DNS setup alone does not establish that messages will be accepted or placed in inboxes.
Use a diagnostic sequence that connects records to the actual rejection
- Save the evidence: Keep the full NDR, SMTP code, affected recipient, recipient provider, timestamp, and sending service.
- Classify the direction: For trouble receiving mail, check whether MX points to the current mail host. For rejected outgoing mail, inspect SPF, DKIM, and DMARC.
- Inventory senders: Compare live DNS with the current instructions for the email host and every service sending as the domain, including forms, CRM, ticketing, and marketing systems.
- Review SPF: Check for a missing sender, duplicate SPF records, syntax issues, or the 10-lookup-limit error. Make changes according to provider instructions.
- Review DKIM: Check the selector and public key, confirm the sending service signs mail, and consider whether an intermediary changes signed content.
- Review DMARC: Confirm a record is published and inspect whether a passing SPF or DKIM domain aligns with the visible From domain.
- Retest and monitor: After changes, check DNS and authentication results again, then observe actual delivery. If the rejection continues, give the mail host the original NDR and the tests you performed.
Choose checks that answer the right question
Google points senders to Admin Toolbox to review domain settings. Microsoft documents message-header analysis, message trace, and Remote Connectivity Analyzer in its authentication troubleshooting material. Use these alongside the provider’s setup instructions: they examine different signals and do not all answer whether a specific recipient accepted a specific message.
Quick Recap
- A DNS check can help inspect published records such as MX, SPF, DKIM, or DMARC, but it may not cover every sending service, subdomain, or receiver-side policy.
- Message headers can show authentication results for a particular delivered message; they are useful evidence, but are not a substitute for examining the bounce when delivery was rejected.
- Provider tools and traces can add context about service-specific mail flow. Interpret their results with the exact NDR and the sending system involved.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
