Error reference

Your DMARC policy is `p=reject` and neither SPF nor DKIM alignment passed. Receivers are instructed to reject the message outright.

Your DMARC policy is `p=quarantine`. Unaligned mail is being sent to Junk/Spam folders.

Your domain has no DMARC record published. Receivers have no instructions on how to handle unauthenticated mail from your domain.

Your DMARC record contains a `pct=` value under 100, meaning your policy only applies to a fraction of mail.

Your DMARC policy is active, but you're not collecting aggregate reports. You have no visibility into who's failing alignment.

The DMARC record at the organizational domain omits the `sp=` tag, so subdomains fall back to the `p=` policy instead of a dedicated subdomain policy.

Mail passes DKIM but fails DMARC because the signing domain `d=` does not exactly match the `From:` header domain required by `adkim=s`.

Your DKIM signature is present but failed verification — the message was modified in transit or your signing config is broken.

Your email landed with no DKIM signature header at all. Your sending server isn't signing outbound mail.

The DKIM selector in your email's d= tag doesn't resolve to any DNS record. Receivers can't fetch the public key to verify your signature.

Your DKIM public key is shorter than 1024 bits. Modern receivers reject or ignore signatures below this threshold.

The DKIM body hash in your signature doesn't match the body as received. Something modified the message after signing.

Your DKIM signature contains an x= tag with a timestamp in the past. Receivers reject expired signatures.

The DKIM `d=` tag identifies a domain that does not align with the `From:` header domain, so DMARC cannot pass via DKIM even though the signature itself verifies.

The DKIM signature was generated with `simple` canonicalization, so any whitespace or header change by a relaying MTA invalidates the signature.

Your SPF record requires more than 10 DNS lookups to evaluate. The receiver stops processing and marks your mail as PermError.

The sending IP address is not listed in your SPF record. Receivers treat the message as unauthorized.

Your SPF record ends in `~all` (soft fail). The sender isn't authorized, but the receiver is being told to accept the mail anyway.

Your SPF record contains a redirect= chain that loops back to itself, directly or through nested includes.

Your SPF record ends in `?all`, which explicitly tells receivers 'no opinion' on unauthorized senders.

An SPF TXT record exists on the sending domain but contains no valid mechanisms, has syntax errors, or omits the required `v=spf1` version tag.

More than two DNS lookups during SPF evaluation returned NXDOMAIN or an empty answer, which RFC 7208 Section 4.6.4 permits receivers to treat as `PermError`.

The domain's SPF record contains the `ptr` mechanism, which RFC 7208 explicitly deprecates and instructs publishers not to use.

Your sending IP is on the Spamhaus Blocklist (SBL). Major mail receivers will reject your mail outright.

Your IP is on the SORBS Dynamic User and Host List (DUHL), which lists residential and dynamic IPs that shouldn't be sending direct mail.

Your sending IP is on the Barracuda Reputation Block List. Barracuda appliances will reject or quarantine your mail.

Your SMTP provider's shared IP pool is listed on Barracuda, affecting all customers on that IP — including you.

A domain referenced inside your message body is on URIBL (URI blocklist). Your IP may be clean, but the content is flagged.

The sending IP is listed on the Spamhaus Composite Blocking List (CBL), indicating active infection or exploitation emitting spam, malware, or botnet traffic.

Your sending IP is in the Spamhaus Policy Block List, which flags address space the operator has declared should not deliver SMTP traffic directly to the public internet.

Your sending IP is listed on the Spamhaus Exploits Block List because it is emitting traffic consistent with an open proxy, trojan, worm, or other compromised host.

Your sending IP is listed on the SORBS SMTP zone because it was observed operating as an open relay or otherwise misconfigured SMTP server.

The sending IP appears on one of Mailspike's reputation zones (bl.mailspike.net or z.mailspike.net), indicating observed behavior that scores poorly against its traffic model.

Your sending IP or netblock is listed on the TRUNCATE RBL (`truncate.gbudb.net`), which targets snowshoe operations and sources with no legitimate mail history.

Your sending server didn't use TLS when connecting to the receiving MTA. Mail was transmitted in plaintext.

Your mail server negotiated TLS 1.0, 1.1, or a weak cipher. Modern receivers accept the connection but downgrade trust.

The X.509 certificate presented by your SMTP server during `STARTTLS` is past its `notAfter` date, so receiving MTAs reject the handshake or fall back to cleartext.

The CN or SAN on the TLS certificate presented during STARTTLS does not match the hostname advertised in the SMTP `EHLO`/`HELO` command.

Your sending IP has no reverse-DNS (PTR) record, or the record doesn't match your HELO/EHLO hostname.

Your visible From: address differs from your envelope (Return-Path:) address in ways that look like spoofing to receivers.

SpamAssassin flagged your message because the ratio of images to text is too high — a classic spam signal.

Your bulk/newsletter email is missing List-Unsubscribe and List-ID headers. Receivers treat it as unsolicited bulk mail.

Your PTR record and your HELO/EHLO hostname don't match. Receivers flag this as either misconfiguration or spoofing.

Your IP has a PTR record, but it looks like a cloud provider default (ec2-X-X-X-X.compute.amazonaws.com). Receivers downgrade trust.

The receiving MTA rejected the message at the end-of-DATA stage because it violated a local policy covering sender reputation, authentication, or content.

The receiving MTA has temporarily deferred your message with a `421 4.7.0` policy response, usually because sending rate, connection count, or sender reputation crossed a throttling threshold.

The remote MTA rejected delivery with a `552` response because the recipient's mailbox is at or above its storage quota.

Your SMTP server accepts and forwards mail from unauthenticated external senders to arbitrary recipients.

The message lacks a `Message-ID` header or contains one that does not conform to RFC 5322 syntax.