AuthEmailTest.comEmail Delivery Diagnostics

It shows how this receiving server saw one message you sent: connecting IP, HELO name, envelope sender, From, Sender and Reply-To identities, RFC 5322 and MIME formatting, every DKIM signature, SPF, DMARC alignment, ARC when present, and spam filter analysis.

The message must include a subject and body. You can send a simple message for basic SPF, DKIM, and DMARC checks, or send the actual message you are sending for deeper spam filter analysis. Do not forward a message; it must be the actual message sent.

The address lets the report compare the visible header From and envelope sender with what you expected, and it lets the pre-check warn about obvious sender-domain DNS problems before you send.

A one-time address generated from the home page is valid for 15 minutes or until one valid message is accepted, whichever happens first. It cannot accept more mail after it is consumed or expires. Account test addresses are different: they remain active while enabled and can accept messages covered by their allocated credits.

The current limit is 1 MB including headers and body. The service is intended for diagnostic messages, not attachments or large content.

Yes. After the message is accepted, the service runs Rspamd and SpamAssassin scans and shows the scores, actions, and main rules on the report. These results are diagnostic only; other providers and gateways may score the same message differently.

Yes. The Message Format section checks raw line endings and lengths, required and duplicate headers, Date and Message-ID hygiene, MIME boundaries, transfer encodings, character sets, plain-text and HTML bodies, attachment metadata, SMTPUTF8 and 8BITMIME use, and one-click unsubscribe headers when present. It does not open attachments, fetch links, or render remote content.

It provides contextual suggestions about the message itself, such as reply handling, subject style, email-safe HTML, image alternatives, link consistency, bulk-mail unsubscribe signals, attachment compatibility, and unusually large content. The quick summary and detail card show green when no observations are identified and amber when suggestions need review. These advisories do not change authentication, format, spam-filter, or other technical results. AuthEmailTest.com inspects the received message only; it does not visit links, open attachments, or try to verify whether a sender mailbox accepts replies.

Not automatically. A no-reply address can be appropriate for a genuinely automated service, but recipients should have a clear monitored contact route when replies may be needed. The report treats this as an observation rather than a failure. It also cannot prove that any mailbox exists, and it deliberately avoids SMTP recipient callouts because many providers block or obscure them and repeated probes can look abusive.

No. It shows how this receiving server handled one message at one point in time. Reputation, consent, list quality, complaints, bounces, sending patterns, recipient engagement, and each provider's filtering still matter. Read Beyond the Test: Reputation and Inbox Placement, then use Outgoing.email for the broader operational checklist.

A different envelope sender can be legitimate. Mailing platforms commonly use dedicated bounce domains, VERP addresses, or rewritten SRS addresses while keeping your address in the visible header From. A different Reply-To is also valid and does not affect the sender comparison. Mailbox local-part casing is preserved because it is technically case-sensitive, even though most providers treat it case-insensitively. The report shows these identities separately because DMARC checks domain alignment rather than requiring every mailbox address to be identical.

DMARC needs one unambiguous RFC 5322 From identity. The report records every From and Sender header field instead of silently choosing the first address. Multiple From fields, multiple From mailboxes, or an ambiguous Sender field are shown explicitly because they can make the message malformed or prevent a reliable DMARC evaluation.

The pre-check only looks for obvious DNS issues on the sender domain. The live result depends on the actual sending IP, envelope sender, DKIM signature, and alignment used when the message is delivered.

Check the detailed SMTP, sender, Message Format, SPF, DKIM, DMARC, ARC, Rspamd, and SpamAssassin panels first. If the report still looks unexpected, please contact us with the result link and what you expected to see.

DMARC fails when neither SPF nor DKIM passes in alignment with the visible From domain. SPF or DKIM can appear to pass separately while still not aligning for DMARC. AuthEmailTest.com uses the current RFC 9989 DNS tree walk to discover the applicable policy and organisational domain.

Yes. The SMTP Session section shows the connecting IP, PTR names, forward-confirmed reverse DNS, whether the HELO identity resolves to the connecting IP, and whether delivery used STARTTLS, including the negotiated TLS version and cipher when available.

Each signature is checked for verification, alignment, selector and public-key strength. The report also warns about obsolete rsa-sha1 signatures, a missing signed From header, the DKIM body-length tag, future signing timestamps, and expired signatures.

Authenticated Received Chain can preserve authentication evidence when a message is forwarded or modified by an intermediary. When ARC headers are present, AuthEmailTest.com verifies the chain and reports each instance. ARC provides forwarding context; it does not replace this receiver's own SPF, DKIM, or DMARC checks.

Authentication-Results and Received-SPF headers already inside a received message may have been added before delivery or supplied by the sender. They are displayed for context but are not evidence for this test. AuthEmailTest.com uses the actual SMTP connection and performs its own SPF, DKIM, DMARC, and ARC checks.

No. You can run a one-time test from the home page without creating an account. A verified account adds reusable test addresses, monthly credits, saved report history, and plan-based report retention.

One credit represents one accepted email processed into one diagnostic report. Each account plan provides a monthly credit allowance and limits the number of active addresses and credits allocated to each address. You choose how many available credits to allocate to each address. Rejected, oversized, duplicate, or internally failed deliveries do not consume a credit. Disabling an address returns its unused current-month allocation. Credits reset at the start of each UTC calendar month and do not carry over; active addresses automatically receive their previous allocation, subject to the current plan limits.

Reports created through an account test address require a signed-in session for the owning account. Knowing the result URL is not enough, and another user or someone who is signed out cannot open it. Account reports do not offer Copy link; use Export when you deliberately want to create an HTML file for someone else, or Download .eml to save the original message while its raw content is retained. Downloaded files are outside the site's account protection, so review them and share them securely. One-time reports created from the public home page are different: their unguessable URLs can be opened by anyone who has the link until the report expires, so treat those links as confidential. Basic and one-time reports are retained for 7 days; Bronze, Silver, and Gold account reports are retained for 30 days. Raw message content may follow a shorter configured retention period.

No. One-time and Basic account reports are retained for 7 days; Bronze, Silver, and Gold account reports are retained for 30 days. Raw message content may have a shorter configured retention period. Cleanup jobs remove expired data automatically, so export any report you need to keep.