THE EMAIL HEALTH LIBRARY
Less mystery.
A better next step.
104 focused playbooks for the questions between “something is wrong” and “here’s how we fix it.” Start with a symptom, follow the evidence, and check your work.
New to email authentication? Start with the foundations → Set up your provider →
104 playbooks to help you investigate
SPF TempError: investigate a temporary DNS failure
An SPF TempError means evaluation could not finish because of a temporary problem, often a DNS lookup failure.
Read the playbook →SPF diagnosticsSPF neutral: why the sender is neither approved nor denied
An SPF neutral result means the policy makes no assertion about the sending host.
Read the playbook →SPF diagnosticsSPF none: find which domain was actually checked
SPF none means no applicable SPF policy was found, or no suitable domain identity was available for the check.
Read the playbook →SPF diagnosticsSPF include target has no SPF record
An include mechanism depends on an SPF policy at its target domain.
Read the playbook →SPF diagnosticsCircular SPF includes: trace and break the loop
A circular include or redirect causes SPF evaluation to revisit a dependency instead of reaching a useful authorization decision.
Read the playbook →SPF diagnosticsSPF fails only over IPv6
An IPv6 delivery path can fail SPF even when messages sent over IPv4 pass.
Read the playbook →SPF diagnosticsSPF void lookups: empty DNS answers in the evaluation chain
Void lookups are DNS queries that return no applicable answer or a name error during SPF evaluation.
Read the playbook →SPF diagnosticsWhy an SPF redirect is never used
An SPF redirect applies only after mechanisms fail to match.
Read the playbook →SPF diagnosticsSPF macros: inspect the name that gets queried
SPF macros construct domain names from evaluation inputs such as the sender or IP address.
Read the playbook →SPF diagnosticsSPF and empty return paths: check the HELO identity
Mail with an empty reverse path, such as a delivery status notification, needs different SPF context from an ordinary message.
Read the playbook →SPF diagnosticsSplit SPF TXT strings: one record or two records?
DNS can store multiple character strings inside one TXT record.
Read the playbook →SPF diagnosticsA flattened SPF record is stale: recover provider coverage
A flattened SPF record can keep authorizing old IP addresses after a sending provider changes its infrastructure.
Read the playbook →SPF diagnosticsSPF on a delegated subdomain: find the right DNS owner
A delegated subdomain can have its own authoritative DNS service.
Read the playbook →DKIM diagnosticsDKIM key exists, but messages are not signed
Publishing a DKIM key does not activate signing inside your mail service.
Read the playbook →DKIM diagnosticsDKIM selector returns NXDOMAIN
A selector lookup returning NXDOMAIN means the exact queried DNS name does not exist at that resolver.
Read the playbook →DKIM diagnosticsDKIM CNAME exists but its target is missing
A DKIM CNAME is only a pointer to the public key.
Read the playbook →DKIM diagnosticsDKIM public key does not match the signer
A mismatched public and private key can make DKIM verification fail even when DNS is valid and a signature is present.
Read the playbook →DKIM diagnosticsDKIM key revoked: an empty p value
An empty p value in a DKIM key record indicates revocation.
Read the playbook →DKIM diagnosticsDKIM signature expired: inspect x and the delivery timeline
A DKIM signature can include an expiration time in its x tag.
Read the playbook →DKIM diagnosticsDKIM passes but the subject is not signed
A DKIM pass only protects the fields covered by that signature and its signed body scope.
Read the playbook →DKIM diagnosticsDKIM l tag: when only part of the body is signed
The DKIM l tag limits the body bytes covered by a signature after canonicalization.
Read the playbook →DKIM diagnosticsDKIM canonicalization: which whitespace changes survive?
DKIM canonicalization defines how headers and body content are normalized before hashing.
Read the playbook →DKIM diagnosticsTwo DKIM signatures: one passes and one fails
A message can carry multiple DKIM signatures with different domains, selectors and results.
Read the playbook →DKIM diagnosticsRotate DKIM keys without breaking queued mail
A DKIM rotation needs to account for messages signed with the old key but verified later.
Read the playbook →DKIM diagnosticsDKIM fails intermittently across sending nodes
Intermittent DKIM failures can reflect different signer configurations behind the same mail service.
Read the playbook →DKIM diagnosticsA DKIM key is too weak: plan a supported replacement
A published DKIM key can be syntactically valid yet fail modern cryptographic requirements.
Read the playbook →DMARC investigationsDMARC passes while SPF fails: follow the DKIM result
DMARC can pass when SPF fails if a valid DKIM signature aligns with the visible From domain.
Read the playbook →DMARC investigationsSPF passes but DMARC fails: inspect the return-path domain
SPF can pass for a vendor-controlled return-path domain without aligning with your visible From domain.
Read the playbook →DMARC investigationsExternal DMARC reports: verify destination authorization
Sending DMARC aggregate reports to another domain can require DNS authorization by the report destination.
Read the playbook →DMARC investigationsDMARC reports stopped arriving: separate delay from breakage
Missing DMARC reports can result from delivery delays, changed reporting configuration or a lack of reportable traffic.
Read the playbook →DMARC investigationsDuplicate DMARC reports: avoid counting traffic twice
Aggregate reports can be resent or ingested more than once.
Read the playbook →DMARC investigationsAn unfamiliar IP in DMARC reports: identify the service
An unfamiliar source IP in a DMARC report is an investigation lead, not automatic proof of spoofing.
Read the playbook →DMARC investigationsA subdomain behaves differently under DMARC
A subdomain may publish its own DMARC policy rather than using the organizational domain's applicable fallback.
Read the playbook →DMARC investigationsStrict DMARC alignment breaks a subdomain sender
Strict alignment requires an exact domain match for the relevant mechanism.
Read the playbook →DMARC investigationsWhy a reject policy can show disposition none
The policy requested by a domain and the disposition reported for a message are separate fields.
Read the playbook →DMARC investigationsDMARC reports show raw pass and policy failure
DMARC aggregate reports separate raw authentication results from policy-level aligned results.
Read the playbook →DMARC investigationsWhy DMARC forensic reports may never arrive
A ruf address does not guarantee message-level failure reports.
Read the playbook →DMARC investigationsProtect a domain that should never send email
A non-sending domain still benefits from an explicit email policy, but first verify that no application or vendor uses it.
Read the playbook →DMARC investigationsForwarded mail and DMARC: investigate receiver overrides
Forwarding can break SPF and sometimes DKIM, leaving receivers to apply additional local evidence.
Read the playbook →DNS & mail routingMX hostname has no A or AAAA record
An MX record needs a destination hostname that resolves to a usable address.
Read the playbook →DNS & mail routingMX points to a CNAME: correct the destination
An MX target should be a hostname with address records rather than a CNAME alias.
Read the playbook →DNS & mail routingEqual-priority MX servers receive different messages
MX servers with equal preferences may both receive traffic.
Read the playbook →DNS & mail routingBackup MX rejects recipients that the primary accepts
A backup MX must be configured to accept and route the domain's legitimate recipients.
Read the playbook →DNS & mail routingA new email record is still missing: check negative caching
Resolvers can cache an earlier missing-record answer.
Read the playbook →DNS & mail routingEmail DNS returns SERVFAIL: isolate the resolver failure
SERVFAIL indicates that a resolver could not complete the query successfully.
Read the playbook →DNS & mail routingAuthoritative nameservers disagree on email records
Different authoritative answers can make email checks appear inconsistent without any cache issue.
Read the playbook →DNS & mail routingEmail records were edited at the wrong DNS provider
A registrar account and the authoritative DNS service are not always the same place.
Read the playbook →DNS & mail routingIncoming email fails over the MX server's IPv6 address
An MX destination with an AAAA record advertises an IPv6 route that must be operational.
Read the playbook →DNS & mail routingNull MX mixed with ordinary MX records
A null MX explicitly states that a domain accepts no mail and is intended as the domain's only MX record.
Read the playbook →DNS & mail routingNo MX record: why delivery may still be attempted
The absence of MX records does not always mean senders immediately stop delivery attempts.
Read the playbook →DNS & mail routingLowering DNS TTL during an email incident
Reducing a record's TTL does not retroactively shorten copies already cached with the old value.
Read the playbook →DNS & mail routingInternal DNS passes but public email checks fail
Split-horizon DNS can return different answers inside and outside an organization.
Read the playbook →Transport securityMTA-STS TXT exists but the policy file is missing
MTA-STS needs a discoverable TXT record and an HTTPS policy file at the expected host and path.
Read the playbook →Transport securityMTA-STS policy does not cover the current MX servers
An enforcing MTA-STS policy can prevent supporting senders from delivering to an MX hostname that is not covered by the policy.
Read the playbook →Transport securityMTA-STS testing mode reports failures: what to check
MTA-STS testing mode is intended to surface policy problems without requiring enforcement of those failures.
Read the playbook →Transport securityMTA-STS changes are not immediate: understand policy caching
Supporting senders can cache an MTA-STS policy for its max_age period.
Read the playbook →Transport securityChanged an MTA-STS file? Update its discovery identifier
The MTA-STS DNS identifier signals that the policy has changed.
Read the playbook →Transport securityThe MTA-STS HTTPS certificate is invalid
The policy host's HTTPS certificate must validate independently of the mail server's SMTP certificate.
Read the playbook →Transport securitySMTP TLS certificate does not match the MX hostname
A mail server can negotiate TLS while presenting a certificate for a different name.
Read the playbook →Transport securityExpired SMTP certificate: confirm every receiving endpoint
An expired SMTP certificate can disrupt mail from senders that enforce certificate validation.
Read the playbook →Transport securityA receiving server no longer advertises STARTTLS
A server that does not advertise STARTTLS cannot upgrade that SMTP session using the extension.
Read the playbook →Transport securityTLS-RPT reports are missing: inspect discovery and delivery
A TLS-RPT record requests transport reports but does not guarantee every sender will produce them.
Read the playbook →Transport securityTLS-RPT certificate failures and policy failures need different fixes
TLS reports distinguish failure categories that can arise at different parts of delivery.
Read the playbook →Transport securityDANE TLSA exists but DNSSEC validation fails
DANE for SMTP relies on DNSSEC-authenticated TLSA information.
Read the playbook →Transport securityTLS passes but DKIM fails: separate the security layers
TLS and DKIM protect different parts of email delivery.
Read the playbook →Message forensicsWhich Authentication-Results header should you trust?
Authentication-Results headers are assertions by the system that added them.
Read the playbook →Message forensicsFind an email delay using Received headers
Received timestamps can help locate the interval where a message waited, provided the relevant hops and clocks are trustworthy.
Read the playbook →Message forensicsFrom, Reply-To and Return-Path point to different places
These headers serve different purposes: visible authorship, reply destination and bounce routing.
Read the playbook →Message forensicsUse Message-ID to trace an email across systems
Message-ID can help correlate a message across logs, but it is not a cryptographic proof of origin or a guarantee of uniqueness.
Read the playbook →Message forensicsARC pass does not automatically mean DMARC pass
ARC preserves authentication assessments across intermediaries, but its chain result is separate from a current DMARC result.
Read the playbook →Message forensicsA mailing list changed the subject and broke DKIM
Mailing lists can alter signed fields or body content when adding subject tags and footers.
Read the playbook →Message forensicsA mail gateway footer changes the signed message
A disclaimer or security footer inserted after DKIM signing can invalidate the original body signature.
Read the playbook →Message forensicsOne-click unsubscribe header is missing
An ordinary unsubscribe link and RFC 8058 one-click headers are different mechanisms.
Read the playbook →Message forensicsOne-click unsubscribe headers need DKIM protection
RFC 8058 requires the one-click unsubscribe headers to be covered by a valid DKIM signature.
Read the playbook →Message forensicsOne-click unsubscribe endpoint: GET is not the action
The one-click mechanism uses a defined POST request rather than an ordinary link visit.
Read the playbook →Message forensicsA bounce names a different recipient than the one you sent to
A delivery status notification can report a final recipient that differs from the original address because of aliases or forwarding.
Read the playbook →Message forensicsResent-From is not the same as the DMARC From domain
Resent fields describe reintroduction of a message into transport and do not simply replace the ordinary From identity for DMARC.
Read the playbook →Message forensicsCopying a message can change DKIM verification results
Copying rendered email into a text editor can change line endings, encoding or MIME structure.
Read the playbook →Delivery investigationsSMTP accepted does not prove inbox placement
A successful SMTP acceptance means the receiving system accepted responsibility for the message at that stage.
Read the playbook →Delivery investigationsTemporary deferrals after a sending-volume spike
A volume spike can coincide with temporary deferrals, but the response text and provider context determine what to investigate.
Read the playbook →Delivery investigationsMailbox full: when to retry and when to review
A mailbox-capacity response points to a recipient-side condition, but the exact SMTP class determines how the sending system should treat the attempt.
Read the playbook →Delivery investigationsA recipient domain typo causes delivery failure
A typo after the at sign can route mail to an unintended domain or no usable mail service.
Read the playbook →Delivery investigationsRelay access denied: inspect the submission route
A relay-denied response often means the contacted server will not forward the requested message under the current session or destination policy.
Read the playbook →Delivery investigationsA receiver rejects your sending IP's reverse DNS
Some receivers require consistent reverse DNS for sending infrastructure.
Read the playbook →Delivery investigationsShared sending IP reputation: identify what you control
A shared IP carries traffic from multiple accounts, so its reputation is not a measurement of your domain alone.
Read the playbook →Delivery investigationsNo blocklist listing, but email is still rejected
A clean public blocklist check does not establish that every receiver trusts the sender.
Read the playbook →Delivery investigationsSpam complaint rates: check the denominator before comparing
Complaint rates from different reports can use different denominators and coverage.
Read the playbook →Delivery investigationsPassword reset emails arrive too late
A delayed password reset may spend time in your application, sending queue or receiving system.
Read the playbook →Delivery investigationsEmail was never sent because the address is suppressed
A suppression rule can stop submission before a receiving server is contacted.
Read the playbook →Delivery investigationsEmail rejected for message size: inspect encoded size
Message-size limits apply to the transmitted message, including encoding and MIME overhead.
Read the playbook →Delivery investigationsEmail fails at one provider but works elsewhere
Provider-specific delivery failures need a segmented investigation.
Read the playbook →Monitoring workflowsBuild an email sender inventory before changing policy
A sender inventory connects each legitimate mail stream to an owner, platform and authenticated identity.
Read the playbook →Monitoring workflowsReview an email DNS change before publishing it
A DNS review should establish the intended behavior, affected senders and rollback path.
Read the playbook →Monitoring workflowsPrepare an email DNS rollback plan
A useful rollback plan includes the previous configuration and the services needed to make it work again.
Read the playbook →Monitoring workflowsPreflight a new email sending platform
A new sending platform needs identity verification and a real message test before production volume.
Read the playbook →Monitoring workflowsPlan an email provider migration with parallel verification
A mail-provider migration affects inbound routing and outbound identity through separate mechanisms.
Read the playbook →Monitoring workflowsOnboard a client domain into email monitoring
Client onboarding needs technical baseline data and a clear division of responsibility.
Read the playbook →Monitoring workflowsRun a weekly email health review
A weekly review should focus on changes and unresolved findings rather than repeatedly reading the same green checks.
Read the playbook →Monitoring workflowsTriage an email health alert without making blind changes
An alert identifies a change or failed check, but the first response should verify scope and impact.
Read the playbook →Monitoring workflowsCreate an evidence pack for an email incident
An evidence pack helps a mail provider investigate without a long sequence of vague requests.
Read the playbook →Monitoring workflowsRetire an email vendor without leaving stale authorization
Retiring a vendor means confirming that no live mail stream still depends on its credentials or DNS records.
Read the playbook →Monitoring workflowsCheck a seasonal email sender before it becomes active
An infrequent sender can drift unnoticed between campaigns.
Read the playbook →Monitoring workflowsHand off email monitoring to another team
A monitoring handoff should transfer decisions and ownership, not just dashboard access.
Read the playbook →Monitoring workflowsVerify an email fix with a fresh end-to-end test
A successful configuration save is not the final verification of an email fix.
Read the playbook →