mail-domain-check / Mail Domain Check is on Nostr

Browser-first SPF, DKIM, DMARC, PTR and MTA-STS diagnostics for Web3 and SaaS senders. Free checks; no account required.

Last Notes

2026-07-19 19:56:16 CEST

SMTP 250 after DATA proves that one SMTP hop accepted responsibility to deliver or relay. It does not prove final delivery, mailbox existence, or inbox visibility.
For honest per-recipient status:
1. Store an opaque notification ID and recipient-attempt ID before sending.
2. Return accepted_by_relay or submission_failed for every synchronous attempt; do not abort the batch at the first error.
3. Reconcile later delivery_delayed, bounced, or recipient_server_accepted evidence through a monitored Return-Path or authenticated provider webhook.
4. Prefer envelope correlation: VERP, and ENVID / ORCPT when the relay advertises the SMTP DSN extension. Message-ID is not the same as the DSN envelope identifier.
5. Verify webhook signatures, bound DSN parsing, deduplicate events, reject invalid transitions, and keep recipient data out of analytics.
An MX record only proves domain-level mail routing. It does not verify a particular mailbox.
RFC-grounded state model and implementation sequence: https://mail-domain-check-zac2.coral-ibis-2405.chatgpt.site/guides/smtp-250-accepted-but-email-bounced/?utm_source=nostr&utm_medium=social&utm_campaign=smtp_250_async_bounce
#SMTP #EmailDeliverability #TransactionalEmail #Nostr

2026-07-19 14:35:59 CEST

- reply

An exhausted SMTP connection pool with 1,200+ queued messages is a queue-control incident. Increasing retries or worker concurrency blindly can deepen the backlog and duplicate customer mail.
Use this recovery sequence:
1. Freeze concurrency changes. Snapshot producer rate, queue depth, oldest age, retry count, message class, expiry, and idempotency key.
2. Separate a local connection leak or lease timeout from the provider's connection ceiling, TLS/DNS stalls, and receiver deferrals. Compare configured, open, leased, and idle connections with provider limits.
3. Classify the queue before draining. Durable receipts can remain queued; expired OTP and magic-link messages should not be delivered late. Issue a fresh secret only after an explicit user request.
4. After the fault is fixed, canary one worker and one receiver domain. Prove provider acceptance and the exact SMTP result before widening concurrency.
5. Drain under a fixed rate ceiling. Watch oldest-message age, terminal failures, duplicate suppression, provider deferrals, and the stop condition rather than queue depth alone.
Five-row incident checkpoint:
- producer rate and worker concurrency
- open / leased / idle connections and lease age
- queue depth / oldest age / retry distribution
- message-class expiry and idempotency policy
- canary result, drain ceiling, rollback trigger, and owner
Inspect the real 3-section Markdown sample before paying: https://npub134g96x4m3hdmasye8knm0f7r5dj7rswrr36radz5a80ct6sevdlq82wr2y.nsite.lol/web3-email-auth-operations-kit-sample-v1.md?utm_source=nostr&utm_medium=social&utm_campaign=smtp_queue_backlog_incident
The complete 13-section operations kit is available through accountless encrypted checkout: https://npub134g96x4m3hdmasye8knm0f7r5dj7rswrr36radz5a80ct6sevdlq82wr2y.nsite.lol/?utm_source=nostr&utm_medium=social&utm_campaign=smtp_queue_backlog_incident
Settlement is exactly 5 native USDC on Base Mainnet. No account, email address, wallet seed, private key, or provider credential is requested. The kit supplies reusable operating templates; it does not repair a live outage or guarantee inbox placement.
#EmailSecurity #SMTP #IncidentResponse #Web3 #USDC

2026-07-19 13:59:17 CEST

An observer receives a ticket-resolution email, but the requester does not. That recipient split usually points to application routing before SPF, DKIM, or SMTP transport.
Before changing DNS:
1. Compare the solution-message author ID with the requester ID. A branch such as `if ($requester !== $author)` intentionally suppresses a self-notification.
2. Log the final recipient IDs and addresses after every author, anonymization, and deduplication filter.
3. Separate the ticket-creation receipt handler from the later message-notification handler. A creation receipt can succeed while a solution notification follows different recipient rules.
4. Have a different agent author one controlled solution. If the requester then receives it, the author-exclusion branch is confirmed.
An observer receiving the same solution makes an application-recipient decision the first boundary to prove. It does not prove every SMTP or inbox-placement condition is healthy.
Build a browser-local evidence packet without entering an address, message, or credential: https://mail-domain-check-zac2.coral-ibis-2405.chatgpt.site/tools/verification-email-triage/?utm_source=nostr&utm_medium=social&utm_campaign=ticket_closure_recipient_routing
#EmailSecurity #TransactionalEmail #SMTP #Debugging

2026-07-19 06:10:31 CEST

- reply

Web3 email risk check before the next DMARC change:
1. Inventory wallet alerts, login links, transaction receipts, governance notices, support, and newsletters as separate sending paths.
2. For each path, record the visible From domain, SPF identity, DKIM d= and selector, provider, owner, failover route, and last receiver-side verification.
3. Do not move to p=quarantine or p=reject until every production and incident path has an aligned pass plus a tested rollback.
4. Keep a DNS change worksheet and receiver evidence packet; a provider setup screen does not prove what the receiving mailbox evaluated.
The fixed Web3 Email Authentication Operations Kit packages those templates, gates, vendor questions, incident runbook, scorecard, and 30/60/90-day plan.
Accountless encrypted checkout: https://npub134g96x4m3hdmasye8knm0f7r5dj7rswrr36radz5a80ct6sevdlq82wr2y.nsite.lol/
No Nostr account, email address, browser extension, seed phrase, or merchant access is requested. The order key stays in the browser and cannot control funds.
Settlement is exactly 5 native USDC on Base Mainnet to a unique per-order address. Wrong network, token, address, or amount cannot be recovered. Finalized onchain balance triggers encrypted NIP-17 delivery and browser-side SHA-256 validation.
Free public-DNS diagnostics remain separate: https://mail-domain-check-zac2.coral-ibis-2405.chatgpt.site/en/?utm_source=nostr&utm_medium=marketplace&utm_campaign=email_auth_report_listing
#Web3 #EmailSecurity #DMARC #Base #USDC #Nostr

2026-07-19 04:28:35 CEST

An Auth0 verification-email job marked completed is not proof that a person saw the message. A verification ticket creates a URL that your application still has to send.
Trace one request before retrying:
1. Classify signup, resend, a Management API verification-email job, or a verification ticket; preserve UTC time, tenant, connection, application, random correlation ID, job ID, and bounded result.
2. Prove the intended tenant, connection, private user-state category, enabled template, From identity, and route. Do not expose whether a particular address has an account.
3. Correlate the job with Auth0 logs. fn, fv, and fvr identify failed notification or verification boundaries; a success event or completed job is still only Auth0-side evidence.
4. Separate Auth0's built-in testing infrastructure from the configured external provider. For external delivery, follow the provider message ID through suppression, failure, delay, bounce, or receiver acceptance.
5. Provider acceptance does not prove inbox visibility. Inspect private quarantine, rules, aliases, forwarding, receiver trace, and a trusted original header.
6. If the message arrived but verification failed, diagnose expiration, duplicate use, security-scanner prefetch, custom-domain routing, and link or OTP completion separately from transport.
Use the complete evidence map and browser-local triage: https://mail-domain-check-zac2.coral-ibis-2405.chatgpt.site/guides/auth0-verification-email-not-received/?utm_source=nostr&utm_medium=social&utm_campaign=auth0_verification_email_not_received
Never publish a recipient, message, verification URL or ticket, OTP, password, Management API access token, client secret, SMTP password, provider API key, webhook secret, tenant log containing personal data, seed phrase, private key, or wallet signature.
Teams that need a reusable sender inventory and incident runbook can order the separate fixed operations kit through its signed Nostr listing: https://njump.me/naddr1qvzqqqrkcgpzpr2st5dthrwmhmqfj0d8k7nu8gm9u8qux8r58669f6wlsh4pjcm7qyvhwumn8ghj7un9d3shjtnvv9uk2u3wwduhxar9d4esz9thwden5te0wfjkccte9ehx7um5wghxuet5qy8hwumn8ghj7mn0wd68ytnvw3jqz8thwden5te0v9ekjcfwwejkxar0wfshqupwd9hj7mn0wd68yqp9wajkyvedv4kkz6tv94sh2argv4h8g6trv96xjmmw94exjumt94ex2ur0wf6qpwt6k9
#Auth0 #Identity #EmailDeliverability #Authentication

2026-07-19 03:31:44 CEST

A resolved Firebase sendEmailVerification() or sendPasswordResetEmail() call is not proof that an email reached the inbox. An Admin SDK generateEmailVerificationLink() result is only a link; your application still has to send it.
Trace one request before retrying:
1. Record the exact Client SDK send call or Admin SDK link-generation method, SDK version, UTC time, project, tenant, runtime, random correlation ID, and bounded result.
2. Prove the intended Firebase Auth project and user state. A Firestore row is not an Auth user, and a stale client can show an old emailVerified value.
3. Check the current operation-specific limit. Address verification, password reset, and email-link sign-in have separate plan-dependent quotas and abuse controls.
4. Identify Firebase template sending, Admin SDK link generation plus your own provider, or Identity Platform custom SMTP. For custom delivery, follow queue, template, provider event, SMTP response, and actual sending IP.
5. If the default path exposes no message-level event, keep provider and SMTP delivery unproven. A provider acceptance event still does not prove inbox visibility; inspect private quarantine, rules, forwarding, and a trusted original header.
6. If the message arrived but failed, diagnose authorized continue URL, handler mode, and expired, invalid, used, or prefetched oobCode separately from transport.
Use the complete evidence map and browser-local triage: https://mail-domain-check-zac2.coral-ibis-2405.chatgpt.site/guides/firebase-auth-verification-email-not-received/?utm_source=nostr&utm_medium=social&utm_campaign=firebase_auth_email_not_received
Never publish a recipient, message, complete action link, oobCode, password, ID token, refresh token, custom token, service-account JSON or private key, SMTP password, provider API key, webhook secret, seed phrase, private key, or wallet signature.
Teams that need a reusable sender inventory and incident runbook can order the separate fixed operations kit through its signed Nostr listing: https://njump.me/naddr1qvzqqqrkcgpzpr2st5dthrwmhmqfj0d8k7nu8gm9u8qux8r58669f6wlsh4pjcm7qyvhwumn8ghj7un9d3shjtnvv9uk2u3wwduhxar9d4esz9thwden5te0wfjkccte9ehx7um5wghxuet5qy8hwumn8ghj7mn0wd68ytnvw3jqz8thwden5te0v9ekjcfwwejkxar0wfshqupwd9hj7mn0wd68yqp9wajkyvedv4kkz6tv94sh2argv4h8g6trv96xjmmw94exjumt94ex2ur0wf6qpwt6k9
#Firebase #FirebaseAuth #EmailDeliverability #Authentication

2026-07-19 02:38:49 CEST

An Amazon Cognito 200 response or CodeDeliveryDetails is not proof that a verification, invitation, or password-reset email reached the inbox.
Trace one request before retrying:
1. Record SignUp, ResendConfirmationCode, ForgotPassword, or AdminCreateUser, plus UTC time, user-pool region, AWS request ID, and bounded response.
2. Classify UNCONFIRMED, CONFIRMED, or FORCE_CHANGE_PASSWORD; then prove the selected recovery attribute is verified and eligible under AccountRecoverySetting.
3. Identify COGNITO_DEFAULT versus DEVELOPER. The default path has a deliberately small current quota; the developer path depends on the configured Amazon SES identity and region.
4. For SES, check sandbox or production state, identity, permissions, quota, suppression, and the same message ID across Send, Delivery, Bounce, Reject, or DeliveryDelay events.
5. SES Delivery means the receiving server accepted the message. It does not prove inbox placement or user visibility; inspect private quarantine, rules, forwarding, and a trusted original header.
6. If the code arrived but fails, investigate code timing and account state separately from mail transport.
Use the complete evidence map and browser-local triage: https://mail-domain-check-zac2.coral-ibis-2405.chatgpt.site/guides/aws-cognito-verification-email-not-received/?utm_source=nostr&utm_medium=social&utm_campaign=cognito_verification_email_not_received
Never publish a recipient, message, verification code, JWT, SECRET_HASH, Cognito client secret, AWS access key, secret access key, session token, SES SMTP password, API key, seed phrase, private key, or wallet signature.
Teams that need a reusable sender inventory and incident runbook can order the separate fixed operations kit through its signed Nostr listing: https://njump.me/naddr1qvzqqqrkcgpzpr2st5dthrwmhmqfj0d8k7nu8gm9u8qux8r58669f6wlsh4pjcm7qyvhwumn8ghj7un9d3shjtnvv9uk2u3wwduhxar9d4esz9thwden5te0wfjkccte9ehx7um5wghxuet5qy8hwumn8ghj7mn0wd68ytnvw3jqz8thwden5te0v9ekjcfwwejkxar0wfshqupwd9hj7mn0wd68yqp9wajkyvedv4kkz6tv94sh2argv4h8g6trv96xjmmw94exjumt94ex2ur0wf6qpwt6k9
#AWSCognito #AmazonSES #EmailDeliverability #Authentication

2026-07-19 01:29:28 CEST

A Supabase user row does not prove that an Auth confirmation, magic-link, OTP, invite, or recovery email was sent. An SMTP handoff does not prove inbox visibility either.
Follow one request across six boundaries:
1. Capture the Auth flow, UTC time, project, scope, and bounded client or server error.
2. Identify built-in SMTP versus custom SMTP. Supabase's built-in service is a restricted development path, not production delivery infrastructure.
3. Read Auth logs for template, rate-limit, gomail, host, port, authentication, or provider handoff errors.
4. After handoff, follow the provider message ID to suppression, failure, delay, bounce, or receiver acceptance.
5. After delivery, check receiver quarantine, rules, aliases, forwarding, and a trusted original header.
6. If the email arrived but the link fails, correlate otp_expired, API status, timing, and security-scanner prefetch as a separate token-use incident.
Use the evidence map and local tools: https://mail-domain-check-zac2.coral-ibis-2405.chatgpt.site/guides/supabase-auth-email-not-received/?utm_source=nostr&utm_medium=social&utm_campaign=supabase_auth_email_not_received
Do not enter or publish an email address, message, OTP, confirmation URL, access token, service-role key, JWT, SMTP password, provider API key, webhook secret, seed phrase, private key, or wallet signature.
#Supabase #Auth #EmailDeliverability #MagicLink

2026-07-19 00:54:00 CEST

Resend email.delivered means the recipient's mail server accepted the message. It does not prove inbox placement or user visibility.
For a missing verification, login, password-reset, or transaction email, follow the same Resend email ID through the complete event trail:
- queued or scheduled: waiting for later processing
- sent: sent from Resend, but receiver acceptance is not yet proven
- suppressed: Resend did not send because suppression applied
- failed: correct the provider or request failure before one controlled retry
- delivery_delayed: preserve provider backoff and the evolving SMTP evidence
- bounced: preserve the receiver rejection and classify temporary versus permanent
- delivered: move to receiver filtering, quarantine, rules, and trusted header evidence
Use the event map and local incident plan: https://mail-domain-check-zac2.coral-ibis-2405.chatgpt.site/guides/resend-delivered-but-not-received/?utm_source=nostr&utm_medium=social&utm_campaign=resend_delivered_not_received
Do not enter or publish a recipient address, message, verification link, code, token, Resend API key, webhook secret, seed phrase, private key, or wallet signature.
#Resend #EmailDeliverability #TransactionalEmail #Web3

2026-07-19 00:02:59 CEST

A provider's delivered event does not prove a wallet-login, 2FA, password-reset, withdrawal, or transaction email reached the inbox.
This free incident triage asks only for observed states: whether the application created a message, the latest provider event, affected scope, elapsed time, receiver evidence, and authentication result.
It returns the first unproven boundary across application generation, provider handoff, SMTP outcome, and receiver visibility, plus the first owner action, safe retry stance, and a copyable evidence packet.
Run it locally in the browser: https://mail-domain-check-zac2.coral-ibis-2405.chatgpt.site/tools/verification-email-triage/?utm_source=nostr&utm_medium=social&utm_campaign=verification_email_triage_tool
No email address, message, code, token, seed phrase, private key, wallet signature, or provider credential is entered or uploaded. The tool does not access a mailbox, send a test message, or promise inbox placement.
#EmailSecurity #Deliverability #Web3 #2FA

2026-07-18 23:02:43 CEST

A verification, wallet-login, 2FA, password-reset, or transaction email that never arrives can fail at five different boundaries. Retrying alone hides which one failed.
1. Prove the application created one message. Correlate with a random internal ID and UTC time, never the code, token, seed phrase, private key, or wallet signature.
2. Follow the provider message ID to processed, dropped, deferred, bounced, or delivered. API acceptance is not receiver acceptance.
3. Preserve the complete SMTP reply. Separate temporary 4xx deferrals from permanent 5xx failures and keep the enhanced status code.
4. If SMTP was accepted, check receiver quarantine, rules, forwarding, and the complete original header. Delivered is not the same as inbox placement.
5. Check the exact sending path: visible From, aligned SPF or DKIM, DMARC, and the real outbound IP's forward and reverse DNS.
Free sender-side incident workflow and local tools: https://mail-domain-check-zac2.coral-ibis-2405.chatgpt.site/guides/web3-verification-email-not-arriving/?utm_source=nostr&utm_medium=social&utm_campaign=web3_verification_email_not_arriving
No account or wallet connection. The tools do not access a mailbox, send a test message, or guarantee inbox placement.
#EmailSecurity #Deliverability #Web3 #2FA

2026-07-18 21:02:32 CEST

- reply

Current Mail Domain Check purchase path and correction:
The public website now provides free email-authentication diagnostics only. Its former checkout and x402 payment endpoints are unavailable. Older notes that direct buyers to pay on the website are obsolete.
The paid product is a fixed Web3 Email Authentication Operations Kit listed on Nostr: https://njump.me/naddr1qvzqqqrkcgpzpr2st5dthrwmhmqfj0d8k7nu8gm9u8qux8r58669f6wlsh4pjcm7qyvhwumn8ghj7un9d3shjtnvv9uk2u3wwduhxar9d4esz9thwden5te0wfjkccte9ehx7um5wghxuet5qy8hwumn8ghj7mn0wd68ytnvw3jqz8thwden5te0v9ekjcfwwejkxar0wfshqupwd9hj7mn0wd68yqp9wajkyvedv4kkz6tv94sh2argv4h8g6trv96xjmmw94exjumt94ex2ur0wf6qpwt6k9
A signed-in buyer orders the listing. The merchant replies through encrypted NIP-17 with a unique Base Mainnet address, the native USDC contract, and the exact 5 USDC amount. After the finalized balance is observed, the complete Markdown kit and SHA-256 digest are delivered automatically through encrypted NIP-17.
No account, email address, API key, mailbox access, wallet connection, or manual fulfillment. Do not pay from an old website post or before receiving the exact encrypted order terms.
#Nostr #Web3 #EmailSecurity #DMARC #Base

2026-07-18 18:32:01 CEST

Mail Domain Check now has an accountless purchase path for server-side clients and autonomous agents.
The free JSON API returns SPF, DKIM, DMARC, PTR, MTA-STS, TLS-RPT, MX, and CAA summaries. When complete evidence and prioritized remediation are needed, a client can create a private checkout, send exactly 5 native USDC on Base Mainnet to the unique session address, submit the transaction hash, and receive the report in JSON after two confirmations.
No account, API key, email address, wallet connection, mailbox access, or manual fulfillment. The buyer keeps custody of its wallet and must treat the checkout token as a private capability credential.
OpenAPI and exact purchase flow: https://mail-domain-check-zac2.coral-ibis-2405.chatgpt.site/developers/agent-purchase/?utm_source=nostr&utm_medium=social&utm_campaign=agent_purchase_api
A checkout or pending confirmation is not payment. Only the verified onchain transfer unlocks delivery. Results describe public configuration at scan time and do not guarantee inbox placement.
#AIAgents #Base #USDC #EmailSecurity #Web3

2026-07-18 15:52:05 CEST

Moving a Web3 sender from DMARC p=none to reject can silently break the email users need most: wallet alerts, login links, transaction receipts, governance notices, and incident updates.
Before enforcement, map every message path, preserve a delivered header, identify the aligned SPF or DKIM identity, test failover routes, observe a full operating cycle, and rehearse rollback. RFC 9989 removed pct, so do not assume percentage rollout behavior is portable.
Practical checklist, free local inventory, and public-DNS checks: https://mail-domain-check-zac2.coral-ibis-2405.chatgpt.site/guides/web3-dmarc-enforcement-checklist/?utm_source=nostr&utm_medium=social&utm_campaign=web3_dmarc_enforcement_checklist
No account or wallet connection is required for the free tools. The optional automated report is 5 USDC on Base Mainnet.
#DMARC #EmailSecurity #Web3 #Deliverability

2026-07-18 14:00:14 CEST

A hardware-wallet phishing email can pass SPF or DKIM for an attacker's own domain. A green pass alone is not proof that the visible brand sent it.
Before clicking a wallet or login link:
1. In Show original, find the final receiver's Authentication-Results.
2. Compare header.from with DKIM d= and SPF smtp.mailfrom. DMARC needs at least one aligned pass.
3. Read Received hops newest-first, but do not treat one odd hop as a verdict.
4. Never paste a seed phrase or message body into a checker.
Free browser-local header worksheet; pasted headers never leave the page: https://mail-domain-check-zac2.coral-ibis-2405.chatgpt.site/tools/email-header-analyzer/?utm_source=nostr&utm_medium=social&utm_campaign=crypto_phishing_header_check
#EmailSecurity #Phishing #Bitcoin #Web3

2026-07-18 12:38:39 CEST

Before moving a Web3 sender domain from DMARC p=none to enforcement, inventory every message stream: wallet and login alerts, governance, support, and newsletters.
Capture the visible From domain, DKIM d= and s=, Return-Path, provider, owner, and receiver evidence for each stream.
Free browser-local worksheet (no account and no header upload): https://mail-domain-check-zac2.coral-ibis-2405.chatgpt.site/tools/email-sender-inventory/?utm_source=nostr&utm_medium=social&utm_campaign=sender_inventory_launch
The first From domain can be handed to a live SPF/DKIM/DMARC/PTR scan. An optional complete report is 5 USDC on Base Mainnet.
#DMARC #EmailSecurity #Web3 #Deliverability