How to Diagnose Email Deliverability Problems

Start with the bounce or spam report

The fastest path to a diagnosis is the delivery status notification (DSN) or the full message headers from a message that landed in spam. Both contain machine-readable clues about exactly what failed.

A bounce message (NDR) includes an SMTP status code. The most important ones for authentication failures are:

• 550 5.7.1 — the receiving server refused the message, often due to SPF hardfail or DMARC reject policy
• 550 5.7.26 — Google's specific code for "does not meet DMARC requirements"
• 421 4.7.0 — temporary rejection, often rate limiting or reputation-based; the sending server will retry

For messages that arrived but went to spam, open the full headers. Look for three fields injected by the receiving server:

• Authentication-Results: — shows SPF, DKIM, and DMARC outcomes in a single header
• Received-SPF: — the SPF verdict with the specific IP and mechanism that matched (or failed)
• DKIM-Signature: — present if the sender signed; absence here means no DKIM signing is happening

A typical Authentication-Results header might read: spf=pass; dkim=fail (signature did not verify); dmarc=fail (p=reject). That tells you SPF passed but DKIM verification failed, causing DMARC to fail and the policy to be applied.

Check SPF first

SPF is the simplest mechanism to break and the most common culprit in deliverability incidents. Start here.

Query the TXT records on your root domain and look for the v=spf1 record. Common failure modes:

• Multiple SPF records: RFC 7208 requires exactly one. Two records cause a permerror, which many receivers treat identically to a hardfail.
• Too many DNS lookups: SPF evaluation is capped at 10 recursive DNS lookups. Each include:, a:, mx:, and redirect= mechanism counts toward the limit. Exceeding it produces a permerror. This is especially common for organizations using four or more SaaS senders (transactional, marketing, CRM, HR).
• Softfail vs hardfail: ~all (softfail) asks receivers to accept but mark the message; -all (hardfail) requests rejection. If you are using ?all (neutral), SPF is providing no protection at all.
• Sending from an IP not in SPF: A new sending service was added without updating the SPF record. Check the IP in the Received-SPF header against your current SPF record.

To verify your SPF record, query: example.com TXT and check that exactly one record starts with v=spf1.

Verify DKIM signing

DKIM failures are often invisible until DMARC is enforced, because many receivers accept DKIM-unsigned mail if SPF passes. Once you move DMARC to p=reject, a DKIM gap surfaces immediately.

To check DKIM, you need the selector your sending provider is using. Find it in the DKIM-Signature: header of a sent message — look for the s= tag. Then query the public key: <selector>._domainkey.example.com TXT.

If the DNS query returns NXDOMAIN, the key was never published or has been removed. If it returns a record but DKIM is still failing, check:

• The key length — 512-bit RSA keys are rejected by some receivers; use 2048-bit minimum
• Whether your sending platform is actually signing — some require explicit activation per domain
• Body canonicalization — if your mail gateway modifies the message body after signing (e.g., appending a disclaimer), the signature breaks

Inspect your DMARC policy

DMARC is the enforcement layer that ties SPF and DKIM together. A DMARC record at _dmarc.example.com with p=none is monitoring-only: it generates aggregate reports but does not protect your domain. Many organizations deploy DMARC and forget to graduate past p=none.

The two most common DMARC alignment failures are:

• SPF misalignment: SPF passes for the envelope sender (the Return-Path domain), but that domain does not align with the From: header. This happens when a third-party platform sends on your behalf using its own envelope domain.
• DKIM misalignment: The DKIM signature is valid but signed under a different domain (e.g., sendgrid.net instead of example.com). The platform must be configured to sign with your domain's key, not its own.

Read your aggregate reports (rua destination) to identify which sources are failing alignment. Tools that parse DMARC XML reports are available, but the raw structure is readable: look for <source_ip>, <count>, and <disposition>.

Check MTA-STS

MTA-STS does not affect whether your outbound mail is delivered, but it affects inbound delivery security and can cause receiving failures if misconfigured. If you publish an MTA-STS policy in enforce mode, sending MTAs must be able to establish a TLS connection with a valid certificate matching your MX hostnames. If your MX server's certificate is expired or mismatched, legitimate mail will be deferred or bounced by senders that honor MTA-STS.

Check: _mta-sts.example.com TXT for the policy record, then fetch https://mta-sts.example.com/.well-known/mta-sts.txt to confirm the policy file is reachable and the MX hostnames listed match your actual MX records.

IP reputation

Authentication passing does not guarantee deliverability if your sending IP has a poor reputation. Blacklisting is a separate layer from SPF/DKIM/DMARC.

Key things to check:

• DNS blocklists (DNSBLs): Spamhaus SBL/XBL/PBL are the most influential. An IP listed in the PBL is considered a residential or dynamic IP not meant for direct mail sending.
• Shared vs dedicated IP: Shared IPs on major ESPs accumulate reputation from all senders on the pool. A dedicated IP starts with no reputation — which can be worse than a good shared pool for low-volume senders.
• Cloud provider IPs: AWS, GCP, and Azure IP ranges are listed in the Spamhaus PBL and treated with elevated suspicion by many receivers. Sending transactional email directly from a cloud VM (rather than through an ESP or relay) is a common mistake that immediately triggers filters.

Common causes and fixes

How to check everything at once

Rather than querying each record individually, use the +check mode in the DNS inspector to run a full email authentication audit in one step. It queries SPF, DKIM (common selectors), DMARC, MX, MTA-STS, TLSRPT, and BIMI in parallel and applies lint rules to each result — flagging issues like the 10-lookup limit, missing alignment identifiers, and policy mode regressions.