DMARCNeeds review
_dmarc.example.com publishes p=none with aggregate reporting, but no enforcement policy is active.
Mailbox providers can observe authentication, but failing mail is not being asked to quarantine or reject.Sample deliverable
See what the $49 readiness audit looks like
This is a fictional example for example.com. It shows the shape, evidence density, fix priority, and caveats a real SenderReady audit provides before a DNS admin, founder, agency, or email owner changes records.
Fictional domain
example.com sender readiness fix plan
Executive verdict
The domain has basic DMARC visibility and some SPF/DKIM coverage, but it is not ready for a high-risk launch until each active sender is confirmed and SPF lookup headroom is restored. Enforcement should wait until legitimate aligned traffic is visible in reporting.
Evidence table
Real audits use live public lookups at review time. This sample uses illustrative evidence so you can inspect the deliverable format without exposing a customer domain.
SPFWarning
Root SPF record authorizes two senders and reaches nine public DNS lookups in the sampled chain.
One more include can push the domain over the lookup limit and make SPF evaluation fail.DKIMAction needed
The submitted selector resolves for the marketing platform, but the transactional selector was not supplied.
Some legitimate streams may be unsigned or unverified until selectors are confirmed per provider.BIMIOptional
No BIMI record was found at default._bimi.example.com.
No immediate sending failure. Consider only after DMARC alignment and brand assets are mature.MTA-STSMissing
_mta-sts.example.com was not found and no HTTPS policy file was submitted for review.
Inbound mail transport hardening is not advertised; this is separate from outbound authentication.TLS-RPTMissing
_smtp._tls.example.com was not found.
The domain is not requesting transport-security failure reports.Priority fix list
The paid audit is meant to become an owner-ready task list. Each fix includes the likely owner, why it matters, and how to verify it after records change.
DNS admin
Stabilize the SPF policy before adding another sender.
Merge duplicate sender paths, remove unused includes, and keep the lookup count below ten after recursive public evaluation.
Verify: Rerun the SPF checker and confirm a single root TXT policy with fewer than ten DNS lookups.Email platform owner
Confirm DKIM selectors for every active sending stream.
Collect selectors from marketing, transactional, and support tools instead of assuming one selector covers every stream.
Verify: Check each selector publicly and confirm a signed sample message from each platform.Domain owner
Move DMARC enforcement only after legitimate senders are visible.
Keep reporting active, review aggregate data, then plan a staged policy move when all known senders align.
Verify: Confirm DMARC rua reporting works and failing legitimate traffic has been addressed before changing policy.Security or IT
Decide whether inbound transport reporting matters for this domain.
MTA-STS and TLS-RPT are not outbound authentication fixes, but they may be useful for receiving-domain security posture.
Verify: Publish test-mode records only after the receiving MX hosts and HTTPS policy endpoint are confirmed.Provider-specific remediation example
Real audits separate detected public-DNS clues from customer-submitted platform context so the fix plan can tell the DNS owner what to verify in each provider.
Shopify notifications
Review Shopify Email or store-notification sender settings before changing root-domain DNS.
Verify: Confirm the authenticated sending domain in Shopify admin, then verify a signed sample message.Klaviyo campaigns
Use the account-generated branded sending domain and DKIM records instead of copying generic values.
Verify: Verify with provider admin screens and signed sample messages before moving DMARC enforcement.Google Workspace mailbox
Confirm Workspace DKIM is enabled for the From domain and that SPF still represents every sender.
Verify: Do not publish generic DKIM values; check the exact selector and public DNS after activation.What the real report includes
- Executive verdict and score with the strongest public-DNS risks called out first.
- Evidence table for DMARC, SPF, DKIM, BIMI, MTA-STS, TLS-RPT, and related caveats.
- Owner-ready fix list with priority, accountable team, concrete action, and verification step.
- Provider-context notes based on the sending tools and selectors submitted with the request.
- Scope limits that separate observed public facts from recommendations and non-guarantees.
Scope and caveats
SenderReady uses public DNS records and the context you submit. It does not log in to mailboxes, ESPs, DNS hosts, subscriber lists, or provider dashboards, and it cannot guarantee inbox placement, legal compliance, reputation recovery, or provider approval.
Want this for your domain?
Email and domain are enough to request scope. Add platform, selector, or timing details only if you already have them.
Request this sample-style audit
Email and domain are enough to request the same style of public-DNS readiness report for your domain. Add provider context only if you already have it.