Good questions.
Straight answers.

Deliverability concerns whether a message reaches the intended inbox. It is different from a server merely accepting the message. Authentication, sender behavior, reputation, recipient expectations, and the receiving system can all affect the outcome. Start by identifying which of those signals your test actually measured.

No. A score summarizes the checks performed on a particular message. It cannot observe every recipient’s history, every provider’s filtering, or your entire sending reputation. Read the evidence and limitations beside the score, then verify changes with a fresh controlled test.

Create a test address, then send one representative message through your normal sending platform. The first received message is analyzed. Use a fresh test for each revision and keep the sender, route, and change documented. If test creation is unavailable, wait for the service to recover rather than sending to an old address.

Public message tests do not require an account where the service is enabled. A customer account provides a separate private workspace and history. The availability of each checker depends on its configured capabilities; a tool page must show unavailable when its required service is not configured.

Start with a reproducible failure in trusted receiving evidence. Check the exact sender identity, signature, and alignment before making broad DNS changes. Once authentication is working, investigate sending practices and reputation. Change one thing at a time so a new result can be interpreted.

SPF evaluates sending authorization for an identity. DKIM verifies a message signature associated with a signing domain. DMARC connects authenticated identities to the visible From domain through alignment. A pass for one mechanism is useful evidence, but the mechanisms answer different questions.

The passing SPF identity may not align with the visible From domain, and there may be no passing aligned DKIM signature. Record the domains used by each check instead of comparing only the pass/fail labels. The alignment tutorial walks through a simplified example.

The selector and signing domain identify where a public key is published in DNS. Read s= and d= from a DKIM-Signature header in an actual message from the relevant sender. Guessing selectors is not a substitute for checking the service and signature you are investigating.

No. DNS lookup confirms that a key is published at a location. Verifying a signature also requires the signed message and its parameters. Inspect the trusted receiver’s result or use a suitable message validator for that separate task.

Review legitimate senders and their actual authentication paths before strengthening policy. Prepare evidence, ownership, and a rollback plan. Current protocol guidance and deployed receiver behavior must both be considered; older rollout tutorials may describe mechanisms that are no longer in the current standard.

No. Verification combines signals with different limits, such as syntax, domain routing, and provider observations. Mailbox behavior can be ambiguous or change later. Unknown, risky, and unavailable outcomes should stay distinct from invalid or confirmed signals, and a result is not permission to send.

There is no single universal blacklist of individual mailboxes. A product may check the address’s domain or a provider-specific address signal. It must name the datasets and coverage instead of implying every mailbox provider maintains a public address-level blocklist.

No. They evaluate different identifiers and datasets. Use the relevant domain or actual sending IP from trusted evidence, and follow the list operator’s documented purpose and lookup rules. An unavailable query is not a not-listed result.

No. Logo display depends on the receiving provider and its current requirements, as well as authentication, assets, and any required evidence document. A DNS record is one part of a readiness review, not a universal display guarantee.

Each tool page identifies the capabilities currently available. A page is not evidence that every provider is active. Unconfigured or unreachable services must return unavailable or unknown, not a fabricated clean result. Check the coverage and observation time before relying on a response.

A placement test observes what happens at a defined set of controlled or provider-managed seed mailboxes. The report should identify provider coverage, timing, and whether each message was observed in inbox, spam, not received, or unavailable. It cannot reproduce every subscriber’s mailbox.

Possible causes include delay, rejection, routing problems, or unavailable monitoring. Collect bounce and timing evidence before assigning a cause. Missing and unknown should not be relabeled as spam just to make a report look complete.

Receiving systems use their own policies and observations, and accounts can have different histories. Compare the provider-specific evidence and controlled conditions. A result at one mailbox is not proof that another provider will make the same decision.

Keep the sender, sending platform, timing, and receiving sample as consistent as possible. Make one documented change, retain a baseline, and compare fresh observations. If several things changed at once, describe the uncertainty rather than claiming a single cause.

The existing diagnostic workflow is built around the first received message. Create a fresh test for each revision so evidence does not become mixed. Record which change belongs to each report and check the configured expiry before sending.

Start with Email foundations, then work through SPF, DKIM, and DMARC. Use one message you are authorized to inspect while you learn. If a lesson is not published yet, use the linked primary references and return when a reviewed version is available.

The academy has a curriculum of 100 distinct topics across ten learning tracks. Only approved, substantive lessons appear in the public catalogue. Planned topics and editorial drafts are not published tutorial pages, and no claim of 100 completed articles is made before that work is finished.

A published academy lesson requires a recorded technical review and an approval decision. Draft previews are labeled and are not an independent human-review claim. Check the sources and actual review information, and report a correction when evidence no longer matches current guidance.

Start with read-only investigation. Any production edit should follow your organization’s approved change process and your provider’s current instructions. Example domains, addresses, and records are illustrative; do not copy them as your production configuration.

The editorial process records primary sources, material changes, and actual review information. Provider-specific instructions need rechecking after updates. A recent modification date alone does not prove that an article was technically reviewed or that its advice still applies.

Deliverlens is built by Fintrate. Final legal notices must identify the registered entity, its role, and the applicable contact details. Draft policy previews are not a substitute for approved production terms.

Yes. Choose Reject optional or open Cookie settings in the footer. Optional categories start off. Essential session and security functionality may still be needed for forms and accounts. The consent interface describes which optional integrations, if any, are actually installed.

Yes. Reopen Cookie settings in the footer and save your new choice. Turning off preference storage removes the saved theme preference. Any future analytics or marketing integration must respect both the initial choice and withdrawal before it can be enabled.

Use the smallest authorized sample that reproduces the issue. Avoid customer records, credentials, and unnecessary attachments. Read the applicable privacy and retention information before submitting sensitive material, and never treat an opaque report link as permission to share private content.

Use the Contact page for the support and corrections route. If no support destination is configured, the form must say it is unavailable and must not claim a message was sent. Do not include passwords, API keys, raw private messages, or unnecessary recipient information.

Your current plan version defines access separately for each diagnostic service. Open the Services area in your account to see whether a service is enabled, its included allowance, any pack balance, and the next reset time. Do not rely on an old pricing screenshot: archived plan versions can differ from the catalogue shown to new customers.

No. Deliverlens records an allowance for each service in the assigned plan version, so using one checker does not silently consume another checker’s included units. A purchased pack can also grant units only to the services listed for that pack. Your account shows included and pack balances separately for each service.

Each enabled service has a reset cadence in your plan version. For a monthly cadence, Deliverlens calculates the current UTC usage window from the entitlement start date and displays its exact end time in your account. A service configured with no recurring reset keeps its defined entitlement window instead. Check the displayed timestamp before scheduling a large run.

Not automatically. Billing frequency and service-usage cadence are separate settings. An annual subscription can still open monthly service-allowance windows when the published plan version uses a monthly reset. Review the service table and reset timestamp shown before checkout and in your account; do not multiply one monthly allowance by twelve and assume it is available at once.

Base plan units belong to their recorded usage window and the current implementation does not move unused units into the next recurring window. Pack grants are tracked separately and may have their own expiry. Because carryover and expiry are commercial terms, confirm the published plan and pack details before purchase; an unpublished draft is not a promise of future availability.

A paid pack creates service-specific grants for the eligible services listed in that pack. Deliverlens uses the current plan allowance first and draws from an eligible pack only after that service’s included allowance is exhausted. Expiring pack grants are selected before grants without an expiry. Your account keeps included and pack balances separate so the source of each available unit stays clear.

Deliverlens first checks for an eligible pack grant for that service. If neither the plan window nor a pack has a unit available, the new run is rejected with a quota response instead of starting work or creating a negative balance. The account service view shows the remaining amounts and reset time. Retry after the reset or purchase an applicable published pack when one is offered.

A plan change is effective only after Deliverlens records the corresponding entitlement state from a verified billing event or an authorized administrative adjustment. Checkout completion by itself is not proof that access changed. Proration and change timing must follow the published commercial terms for the selected offer; until those terms are approved, contact support rather than assuming an immediate upgrade or refund.

Use the Billing area to open the payment provider’s customer portal when that connection is available. Cancellation timing, renewal access, refund eligibility, taxes, and pack treatment must follow the approved terms attached to your purchase. Deliverlens does not infer those rules from a button click. If the portal is unavailable or the published terms do not answer your case, contact support with the order reference only.

The Billing area lists Deliverlens order and subscription states recorded from verified provider events. When the customer portal is configured, use it for provider-hosted invoices, receipts, and payment-method management. A pending or failed order does not grant units. If the two views appear inconsistent, use the order reference when contacting support and do not send card details by email.

Sign in, open API keys, choose a name that identifies the application or environment, select only the required scopes, and set an expiry. Deliverlens checks your plan’s active-key limit before creating it. Copy the secret immediately and store it in a secrets manager; the interface will not reveal the same plaintext token again.

No. The plaintext API secret is returned once, when the key is created. Deliverlens stores a one-way representation used to authenticate later requests, not a retrievable copy for the interface. If the secret is lost or may have been exposed, create a replacement, update the client, verify it, and revoke the old key.

Choose the smallest set your integration needs. A client that starts diagnostic runs needs the create scope; a client that only reads its reports should not receive write access. Scope checks do not replace plan entitlements or service quotas: the account must also be allowed to use the requested service. Use separate named keys for unrelated systems so each can be revoked independently.

No. Service allowances belong to the customer account and its current entitlement, so runs started by different keys and by the customer interface draw from the same service-specific ledger. Keys are still identified in API analytics, and request-rate protections can reject excessive traffic independently of the remaining service allowance. Separate keys improve control and attribution, not the size of the plan.

Yes. Authenticated runs from the customer interface and integration API use the same account entitlement and service-specific usage ledger. Each ledger entry records its channel so usage can be explained without maintaining two conflicting balances. Public anonymous tools follow their own availability rules and are not presented as part of a customer allowance unless the product explicitly records them that way.

No. A service unit is reserved when a new diagnostic run is accepted, not every time its status or result is read. Polling still counts as API traffic and is subject to request limits and rate protection, so use the recommended interval and stop after a terminal state. Repeating a create request without the same idempotency identifier can represent a separate run.

A completed observation commits its reserved unit. A failed or unavailable run releases the reservation. Partial results are charged only when that service’s plan entitlement marks partial observations as billable. Unknown is a result meaning, not permission to invent a clean outcome. Inspect the run’s usage disposition and service policy when reconciling a balance.

Open API usage in the customer account and choose a date window of up to 93 days. The report groups request counts, successful and rejected responses, and rate-limited requests by endpoint, named key, service, and day. Revoked keys keep their historical identifier while their secret remains unavailable. Times are reported in UTC so windows can be compared consistently.

A rate error means too many API requests arrived within the applicable traffic window; slow down and honor retry information. A service-quota error means the account has no included or eligible pack unit for that service until its displayed reset or another valid grant. Check the response status, API usage report, service balance, and UTC reset time before retrying.

Revocation deletes that authentication token, so its next protected request is rejected. It does not erase completed diagnostic records, usage ledger entries, or aggregated request history needed to explain prior activity. Replace the credential in every authorized client before revoking during a planned rotation, or revoke immediately if exposure is suspected and then investigate recent key-level analytics.