How to troubleshoot email delivery issues

Email delivery fails in layers. DNS tells the world where your mail server is. Authentication records tell receiving servers your mail is legitimate. The network path has to actually be open. And your sending IP has to not be on a blocklist. A failure in any one layer produces the same symptom from the user's side: "my email didn't arrive."

The fix is to test each layer in order instead of guessing. This guide walks the layers from DNS outwards, which is the order in which problems are both most common and cheapest to check.

Step 1. Verify your MX records

MX records tell sending servers which host accepts mail for your domain. No valid MX, no inbound mail. Wrong MX, mail goes to the wrong place.

Open the DNS Lookup tool, enter your domain, and select the MX record type. You should see one or more entries like:

example.com.  3600  IN  MX  1 aspmx.l.google.com.
example.com.  3600  IN  MX  5 alt1.aspmx.l.google.com.

Check three things:

• The records exist. An empty MX result means inbound mail is broken outright (some servers fall back to the A record, but you should never rely on that).
• They point where you think. If you migrated from Google Workspace to Microsoft 365 last quarter and the MX still says aspmx.l.google.com, you found the problem.
• Priorities make sense. Lower number = tried first. Two records with the same priority are load-balanced; that's fine, just make sure both hosts actually accept your mail.

A common trap: the MX value must be a hostname, never an IP address, and that hostname should not be a CNAME.

Step 2. Check your SPF record

SPF is a TXT record on your domain that lists the servers allowed to send mail claiming to be from you. Receiving servers check the connecting IP against it.

In the DNS Lookup tool, query the TXT records for your apex domain. Look for the record starting v=spf1:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Failure modes, in rough order of frequency:

• A sending service isn't included. You added a transactional email provider but never added its include: to SPF. Their mail soft-fails or hard-fails at strict receivers.
• More than one SPF record. Two TXT records both starting v=spf1 is invalid per RFC 7208; receivers treat it as a permanent error. Merge them into one.
• Too many DNS lookups. SPF evaluation is capped at 10 DNS-querying mechanisms (include, a, mx, etc.). Stacks of nested includes from multiple SaaS vendors blow the limit and the record returns permerror. Flatten or prune.
• -all vs ~all. -all (hard fail) tells receivers to reject non-matching mail; ~all (soft fail) suggests marking it. Hard fail is fine if the record is complete. If you're mid-investigation, a hard fail with a missing include explains rejected mail neatly.

Step 3. Validate DKIM

DKIM signs each outgoing message with a private key; the public key lives in a TXT record at <selector>._domainkey.yourdomain.com. The selector is provider-specific: google for Workspace, selector1/selector2 for Microsoft 365, often s1/s2 for SendGrid. Check your provider's setup docs or a delivered message's DKIM-Signature: ... s=<selector> header.

Query the TXT record for the full selector hostname. You should get back something starting v=DKIM1; k=rsa; p=MIIB.... Common failures:

• Record missing entirely: DKIM was enabled in the provider but the DNS record never got published.
• Truncated key. RSA-2048 public keys exceed the 255-byte limit of a single TXT string and must be split into multiple quoted strings. Some DNS UIs mangle this on paste, cutting the key short. The signature then fails verification everywhere.
• CNAME chain broken. Providers like SendGrid have you CNAME the selector to a record they host. If the CNAME target changed or was deleted, DKIM silently dies.

Step 4. Check your DMARC policy

DMARC is a TXT record at _dmarc.yourdomain.com that tells receivers what to do when SPF and DKIM both fail alignment:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com

Two things matter for troubleshooting:

• Alignment, not just pass. DMARC requires the domain in the From: header to align with the domain that passed SPF or DKIM. A third-party sender can pass SPF on its own domain and still fail DMARC for yours. This is the classic "SPF passes but mail still goes to spam" case; the fix is configuring DKIM signing with your domain at the third party.
• The rua reports are your best diagnostic. Aggregate reports list every IP sending as your domain and whether it passed. If you're flying blind, set p=none with a rua address, collect a week of reports, and you'll know exactly which legitimate sender is failing.

Note that Gmail and Yahoo require DMARC (at minimum p=none) for bulk senders, so a missing record alone can tank delivery to consumer inboxes.

Step 5. Check blocklists and reverse DNS

If DNS and authentication are clean but mail is still rejected or junked, look at the sending IP's reputation.

• Blocklists. Check the sending IP against the major DNSBLs; Spamhaus ZEN is the one most receivers actually use. A listing usually comes with a reason and a delisting process. If you're on a shared IP (most SaaS senders), a listing may be a neighbour's fault; your options are the provider's support queue or a dedicated IP.
• Reverse DNS. The sending IP should have a PTR record, and that hostname should resolve back to the same IP (forward-confirmed reverse DNS). Many receivers refuse mail from IPs with no PTR or a generic ISP one (123-45-67-89.dynamic.isp.net).

Rejection messages in your mail server logs or bounce emails usually name the blocklist directly; read the bounce before guessing.

Step 6. Test port reachability

Self-hosting mail, or relaying through a smarthost? Verify the network path is actually open with the Port Checker:

• Port 25: server-to-server SMTP delivery. Many ISPs and cloud providers (AWS, Azure, GCP by default) block outbound 25 to fight spam; you may need to request an unblock or relay via a provider on 587.
• Port 587: authenticated submission from clients to your server, with STARTTLS. This is the one your laptops and apps should use.
• Port 465: implicit-TLS submission. Legacy but still widely supported.

Test inbound 25 against your MX host. If it's closed, no one can deliver to you, regardless of how perfect your DNS is. If basic reachability is in question, a ping test against the MX host confirms the box is up at all.

Step 7. Read the headers of a failed message

When a specific message went to spam, the receiving side often tells you why. Get the recipient to forward the message as an attachment (to preserve headers) and look for the Authentication-Results: header:

Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=example.com;
  dkim=fail header.d=example.com;
  dmarc=fail (p=quarantine)

That one header pinpoints which mechanism failed at the actual receiver, which beats any amount of speculation.

TL;DR

1. DNS lookup on MX: records exist, point at the right provider, hostname not IP.
2. TXT lookup for SPF: exactly one v=spf1 record, all senders included, under 10 lookups.
3. TXT lookup on <selector>._domainkey: DKIM key published and not truncated.
4. TXT lookup on _dmarc: policy exists, alignment understood, rua reports enabled.
5. Check the sending IP against blocklists; confirm forward-confirmed reverse DNS.
6. Port-check 25 inbound on the MX host, 587 for submission.
7. For a specific failure, read Authentication-Results in the received headers.

Related

• DNS Lookup tool: MX and TXT queries for every step above
• Port Checker: confirm 25/587/465 reachability
• How to monitor DNS records for drift: get alerted when someone changes your MX or SPF