Home / About sender.report

About sender.report

sender.report is a self-hosted tool that analyses your email deliverability — no account, no tracking, no third parties.

Instant Analysis Results seconds after the mail arrives
No Account Needed No account, no email address required
Self-Destructing Mailboxes expire automatically
Open Source Self-hosted & fully transparent

Mail Simulator – Test Changes Live

Paste your RFC 2822 email source into the editor and see immediately how changes to headers, HTML or subject affect the score. Content checks run live (600 ms debounce), DNS checks available on demand with one click.

Open Simulator →
68 automated checks

What sender.report checks

Five dimensions of deliverability – fully automatic, no configuration needed.

Authentication

The most common reason for spam classification: misconfigured auth records.

  • SPF – Sending IP permitted by DNS?
  • DKIM – Signature valid?
  • DMARC – Policy alignment correct?
Server & Network

Technical configuration errors that silently sabotage deliverability.

  • PTR / rDNS – Reverse DNS correct?
  • HELO – Server identity consistent?
  • TLS – Transmitted encrypted?
Spam Filters

Content and IP reputation — what spam filters actually decide on.

  • SpamAssassin – Score & rule details
  • Rspamd – Symbol analysis (optional)
  • DNSBL / RBL – IP on blacklists?
Report & Score

All results at a glance — plus raw data for debugging.

  • Score 0–10 – Overall rating
  • Header Chain – Received path
  • JSON-Export – API access
Simulator & Re-Check

Test changes live without sending a new test email.

  • Live editor – Edit RFC 2822 source directly
  • Re-Check – re-run individual DNS checks
  • No sending – purely local in browser
Complete Reference

All checks in detail

What each check means, how important it is for your deliverability, and where to dig deeper.

CriticalWithout this you will almost certainly end up in spam ImportantSignificant impact on deliverability RecommendedImproves reputation & presentation OptionalBonus signal for advanced senders

By far the most important area. Gmail, Outlook & Yahoo have required valid authentication from all senders since 2024 — without it, mail is rejected or filtered.

  • Critical
    SPF – Sender Policy Framework. A DNS TXT record on your domain specifies which servers are allowed to send on its behalf. The receiving server checks whether the sending IP is permitted. Without a valid SPF record your mail looks forged. RFC 7208 ↗
  • Important
    SPF Strictness – the trailing all tag. -all (hard fail) gives the best protection, ~all (soft fail) is still acceptable, +all is dangerous (permits everyone). The RFC limit of max. 10 DNS lookups is also checked. dmarc.org FAQ ↗
  • Critical
    DKIM – DomainKeys Identified Mail. Your mail is cryptographically signed; the public key is published in DNS. The recipient verifies the mail was not altered in transit and genuinely originates from your domain. RFC 6376 ↗
  • Important
    DKIM Key Length – RSA keys below 1024 bits are considered insecure; 2048 bits is today's standard. Ed25519 is also recognised. Weak keys may be penalised by filters.
  • Critical
    DMARC – builds on SPF and DKIM and tells the receiver what to do when one fails. DMARC is what makes spoofing protection effective and provides reporting. RFC 7489 ↗
  • Important
    DMARC Policy Strength – p=none only monitors, p=quarantine moves forgeries to spam, p=reject refuses them outright. For real protection, at least quarantine plus a rua= report address is recommended.
  • Important
    SPF Alignment – the SPF-authenticated domain must match the visible From: address. Only aligned SPF counts towards DMARC.
  • Important
    DKIM Alignment – the DKIM-signed domain must match the From: domain. A common, hard-to-spot mistake.
  • Important
    DMARC Alignment – checks whether SPF or DKIM (or both) pass DMARC alignment.
  • Important
    From Display Name – detects brand impersonation and foreign email addresses in the display name (e.g. "PayPal Service <x@gmx.de>"). A classic phishing pattern that triggers filter suspicion.
  • Recommended
    ARC – Authenticated Received Chain. Verifies the ARC chain added by forwarding servers (e.g. mailing lists). Allows DMARC to pass even when an intermediary breaks SPF/DKIM alignment. RFC 8617 ↗
  • Optional
    X-Google-DKIM – Google's internal DKIM verification signal. A "fail" means Google's infrastructure rejected the DKIM signature — can negatively affect Gmail deliverability even if standard DKIM passed.

Shows whether your sending IP and hostnames are cleanly and consistently registered in DNS. Inconsistencies make your server look poorly maintained or compromised.

  • Critical
    PTR / Reverse DNS – your sending IP must have a hostname that in turn resolves back to the same IP (forward-confirmed rDNS). Without a PTR record many large providers reject outright. RFC 1912 ↗
  • Recommended
    PTR Pattern – generic or "dynamic-looking" hostnames (e.g. p5dxxxx.dip0.t-ipconnect.de) are treated as residential connections — a strong spam signal even if the PTR technically exists.
  • Important
    HELO / EHLO – the name your server presents at the start of the SMTP connection should be a valid FQDN that matches the sending IP.
  • Important
    MX-Records – checks whether the domain publishes mail servers that can receive. Important for bounces and credibility.
  • Recommended
    A / AAAA – do the underlying host addresses (IPv4/IPv6) exist? Gaps indicate an incomplete DNS configuration.
  • Important
    TLS Transport – was the mail transmitted encrypted (STARTTLS)? Unencrypted transmission is today both a reputation and a privacy issue.
  • Recommended
    Bounce Domain (Envelope-From) MX – can the Return-Path domain actually receive bounces? Otherwise non-delivery reports are lost.
  • Optional
    MTA-STS – enforces encrypted transport to your mail servers and prevents downgrade attacks. RFC 8461 ↗
  • Optional
    TLS-RPT – delivers reports about failed TLS connections to your reporting address. RFC 8460 ↗
  • Optional
    DNSSEC – is your zone cryptographically signed? Protects your DNS responses (including SPF/DKIM/DMARC) against tampering.
  • Optional
    BIMI & DANE/TLSA – BIMI displays your brand logo in the inbox (requires p=quarantine/reject), DANE pins TLS certificates via DNS. Advanced trust signals. bimigroup.org ↗
  • Recommended
    From-Domain Receive Check – checks whether the From header domain's MX records actually accept inbound mail. A From domain that cannot receive bounces signals an unmonitored or abandoned domain.

How common filters and reputation services rate your mail. The last four checks are opt-in and must be enabled on the start page because they contact external services.

  • Important
    SpamAssassin – the de-facto standard filter used by many mail servers. Shows the total score and the individual triggered rules with their point values. spamassassin.apache.org ↗
  • Important
    Rspamd – modern, widely used filter. Provides a detailed symbol analysis showing which features were scored and by how much. rspamd.com ↗
  • Critical
    DNSBL / RBL (IP Reputation) – is your sending IP listed on known blacklists (e.g. Spamhaus, Spamcop)? A hit is one of the most common reasons for outright rejection. Includes delisting hints. Spamhaus Lookup ↗
  • Recommended Opt-in
    Domain Age – how long has the sender domain been registered? Brand-new domains are a strong spam signal. Queried via RDAP (rdap.org). about.rdap.org ↗
  • Critical Opt-in
    Domain Blocklist – is the sender domain listed on a domain blocklist (Spamhaus DBL, URIBL)? Hits often lead directly to rejection.
  • Critical Opt-in
    Link Blocklist – checks the domains of all links in the mail against URI blocklists. A single listed link can send the entire mail to spam.
  • Recommended Opt-in
    Broken Links – makes HTTP GET requests to all links in the email to verify they respond with a 2xx/3xx status. Broken links damage recipient trust. Opt-in because it contacts the destination servers.

The technical and content structure of the message. Poor formatting is a classic spam signal and can break rendering for the recipient.

  • Important
    MIME Structure – is the message built RFC-compliantly (headers, body, boundaries, encoding)? Broken structure is penalised or simply not rendered correctly.
  • Recommended
    multipart/alternative – a pure HTML mail without a plain-text alternative looks unprofessional and suspicious. Both parts should be present.
  • Recommended
    Plain Text Part – the plain text part should contain meaningful content, not just whitespace or a placeholder.
  • Recommended
    Image/Text Ratio – too many images and too little text is a classic spam signal.
  • Recommended
    HTML Validity – malformed HTML and invalid tags can cause rendering issues and are penalised by filters.
  • Recommended
    Hidden HTML Text – invisible text (e.g. white on white) is a typical spammer trick.
  • Recommended
    Harmful HTML – detects <script> tags and meta-refresh redirects in email HTML — both are used in phishing and are hard-blocked by most clients.
  • Recommended
    Image Alt Text – images missing alt attributes reduce accessibility and can trigger some spam filters.
  • Critical
    Link Domain Mismatch – detects anchors where the visible text shows one domain but the href points to another — a classic phishing pattern.
  • Recommended
    Too Many Links – >30 links in one email is a recognised spam signal used by SpamAssassin and Gmail.
  • Recommended
    Tracking Links & URL Shorteners – URL shorteners and obvious tracking links obscure the real destination and are viewed critically by filters.
  • Recommended
    Subject – length, excessive CAPITALISATION and chains of exclamation marks raise the spam score.
  • Important
    List-Unsubscribe – bulk/marketing mail providers expect a List-Unsubscribe header. Without it you risk spam classification and complaints. RFC 2369 ↗
  • Recommended
    One-Click Unsubscribe (RFC 8058) – the List-Unsubscribe-Post header enables one-click unsubscribe at Gmail/Yahoo. Required for bulk senders since 2024. RFC 8058 ↗

The technical base headers. Missing or implausible required fields point to a misconfigured mail server.

  • Important
    Message-ID – every mail needs a unique, valid Message-ID. Its absence is a clear spam signal.
  • Important
    Message-ID Format – validates the <id@domain> format. An improperly formatted Message-ID is flagged by SpamAssassin.
  • Recommended
    Date & Date Skew – the send date must be present and plausible. Significantly off timestamps point to a misconfigured server.
  • Important
    Received Chain – the chain of servers the mail passed through should be complete and consistent, documenting the mail's path.
  • Recommended
    Reply-To – checks whether a Reply-To header is set and whether it is sensible.
  • Recommended
    Return-Path – checks whether the Return-Path is set and correctly formatted.
  • Recommended
    No-Reply Without Reply-To – when the From address is a no-reply address but no Reply-To is set, recipient replies are silently discarded.
  • Important
    Fake Reply Prefix – detects Re:/Fwd:/Aw: in Subject without a corresponding In-Reply-To header — a manipulation tactic.
  • Recommended
    Body Charset – checks whether the charset in the body part is correctly declared and consistent.
  • Recommended
    MIME Content-Type – checks whether the Content-Type header is correctly set.
  • Recommended
    MIME Boundary – checks the correctness of MIME boundaries in multipart messages.

Checks marked Opt-in are enabled by you on the start page — informed consent, revocable at any time.

Privacy by Design

Your test emails stay your business

sender.report is built as a disposable tool: no accounts, no profiles, no sharing. What you test disappears on its own.

  • The link is the key. Only someone who knows the mailbox URL can see its content — nothing is publicly discoverable.
  • Automatic deletion. Mailboxes and mails are completely removed once their validity period expires.
  • No external services. All scripts, fonts and styles come from the local server — no CDNs, no trackers.
  • No sharing. Contents are not passed to any advertising or tracking third parties. Full stop.
Privacy Policy
Mail receivedAnalysis runs immediately
Report readyAccessible only via your link
Automatically deletedWhen the mailbox expires

Frequently Asked Questions

Short and honest answers.

No. A temporary mailbox is created automatically — no registration, no email address, no password.

They are processed solely for analysis and automatically and completely deleted when the mailbox expires. There is no sharing with third parties.

The address accepts mail for 24 hours. That window is deliberately short — long enough for a test, and afterwards nobody can write to the address any more. The report itself is unaffected: it stays retrievable via its link for 7 days after the message arrived, and is then deleted automatically.

68 checks across five areas: Authentication (SPF, DKIM, DMARC including policy strength, key length, alignment and ARC), DNS & Infrastructure (PTR, HELO, TLS, MX, MTA-STS, DNSSEC etc.), Spam signals (SpamAssassin, Rspamd, DNSBL, optional domain/link blocklists and broken links), Format & Content, and Headers & Raw data. The result is summarised as a score from 0–10.

Yes. sender.report is open source and runs as a single Docker image including Web UI, SMTP receiver and database — entirely on your own infrastructure.

The simulator at /simulate lets you edit RFC 2822 source directly and see live how changes affect the score — without having to send a new test email.
Start testing now