Sender-setup verification guide
Verify the sender before you increase email volume.
Build one inventory for every active send path, verify authentication on production messages, collect evidence for each destination provider, test unsubscribe suppression, and record a named owner's go/no-go decision. Passing these checks does not guarantee inbox placement.
Direct answer
DNS presence is configuration evidence, not production proof.
A defensible release decision pairs DNS inspection with received headers from every real sending path, provider-specific evidence, a completed suppression test, and documented unknowns.
1
inventory for every active send path
1+
production samples for each path
1
named owner for the decision
Step 1 · Sender inventory
Map the system that will actually send.
Create a separate record for each combination of domain, mailbox, service, Return-Path, and DKIM selector. If a field is unknown, assign an owner and keep it open; do not convert an assumption into a pass.
Required inventory fields
Step 2 · Authentication evidence
Separate what DNS says from what the message proves.
SPF and DKIM authenticate different identities. DMARC passes when at least one qualifying SPF or DKIM result also aligns with the visible From domain. Review the current explanations from Microsoft Learn and the sender obligations that apply to Gmail traffic in Google's sender guidelines.
SPF
DNS evidence
Confirm the domain publishes one syntactically valid SPF policy and that the inventory accounts for every authorized sending source. Record lookup or authorization uncertainty instead of guessing.
Production-message evidence
Send through the real production path, retrieve the received message's full headers, and record the SPF result plus the envelope or Return-Path domain. If SPF is the path that satisfies DMARC, that domain must align with the visible From domain.
Decision rule
No-go when the active source is absent, the production result fails, or required alignment cannot be demonstrated.
DKIM
DNS evidence
Resolve the public key for each selector in the inventory and confirm the selector belongs to the active sending path. A key in DNS does not prove that outgoing mail is signed with it.
Production-message evidence
From a received production sample, record the DKIM result, signing domain (d=), and selector (s=). If DKIM is the path that satisfies DMARC, the signing domain must align with the visible From domain.
Decision rule
No-go when the active path does not sign, the signature fails, or required alignment remains unknown.
DMARC
DNS evidence
Confirm the applicable DMARC policy for the visible From domain resolves at the expected _dmarc location, then preserve its policy and reporting destinations in the evidence record. Treat aggregate reports as an inventory signal, not proof that every message path passes.
Production-message evidence
Record the production sample's DMARC result and which aligned SPF or DKIM path produced the pass. Review aggregate reports for legitimate sources that the inventory missed before tightening policy.
Decision rule
No-go when the production sample fails DMARC or the team cannot identify the aligned authentication path.
Step 3 · Provider evidence
Apply the rule set for the recipients you will contact.
Provider requirements are not interchangeable. Capture the traffic scope, effective guidance, production sample, reporting limitations, and unresolved provider signals in the same release record.
Personal Gmail accounts
Scope
Record whether the sender falls under Google's requirements for all senders or its additional bulk-sender requirements, using actual daily volume to personal Gmail accounts.
Evidence to retain
Keep production authentication headers beside the decision. When Postmaster Tools has data, save the relevant authentication, reputation, spam-rate, or delivery-error view with its date range. Missing Postmaster data is not a pass: Google notes that low volume can limit reporting and the dashboards use provider-specific samples and denominators.
Yahoo-hosted recipients
Scope
Identify Yahoo-hosted destinations in the planned recipient mix and apply Yahoo's current sender guidance to that traffic; do not reuse a Gmail dashboard as Yahoo evidence.
Evidence to retain
Preserve a Yahoo-destination production sample, authentication results, unsubscribe evidence where applicable, and any provider response or deferral signals available to the team.
Outlook.com, Hotmail, and Live.com
Scope
Record daily volume to Microsoft's consumer domains. Microsoft's published high-volume requirements apply when a sender exceeds 5,000 messages per day to those domains.
Evidence to retain
For an applicable sender, preserve production proof for SPF, DKIM, and DMARC rather than only DNS screenshots. Keep the relevant provider response evidence with the same dated decision record.
Step 4 · Unsubscribe and suppression
Test the opt-out path end to end.
A visible link or header is not enough if a suppressed address can return through another queue. Use a controlled address, preserve timestamps, and keep the test result with the release decision.
Use RFC 8058 for the one-click protocol, then check the applicable provider guidance from Google and Yahoo. For US commercial-email obligations, consult the FTC's CAN-SPAM compliance guide. This operational guide is not legal advice.
Evidence checklist
Step 5 · Go/no-go record
Make the approval reviewable.
Store the decision with the evidence, not in a passing chat. A limited go must name its exact volume, audience, duration, owner, and rollback condition.
Go only within the verified scope
Approve when the inventory is complete, production evidence passes the applicable checks, opt-out propagation is verified, and a named owner accepts the documented conditions and unknowns.
Stop when a material unknown remains
Use no-go for an uninventoryed path, failed or unknown production authentication, an untested applicable opt-out, or an open provider or compliance question that could change the decision.
Verification is not an inbox-placement guarantee.
Passing authentication and provider setup checks removes known release blockers; it does not forecast every placement outcome. Provider evaluation, recipient behavior, list quality, message content, sending patterns, and post-approval changes can still alter delivery. Record uncertainty and monitor the released scope.
Evidence contract
Primary-source ledger
Each source below was checked on . The ledger supports the provider and protocol claims in this guide; it does not replace a fresh check for the sender's exact traffic and jurisdiction.
Current Gmail authentication, alignment, sender-practice, and applicable unsubscribe requirements.
Verified
Dashboard coverage, available evidence, provider-specific denominators, and reporting limitations.
Verified
Yahoo Sender Hub
Sender best practicesCurrent Yahoo authentication, sender practice, complaint, and unsubscribe guidance.
Verified
Microsoft Learn
Email authentication in Microsoft 365SPF, DKIM, DMARC, and alignment concepts used in the verification record.
Verified
Microsoft Security Blog
Outlook's requirements for high-volume sendersScope and authentication requirements for high-volume mail to Microsoft consumer domains.
Verified
US Federal Trade Commission
CAN-SPAM Act compliance guide for businessUS commercial-email identity, address, subject-line, and opt-out obligations.
Verified
RFC Editor
RFC 8058: Signaling One-Click Functionality for List Email HeadersThe one-click header pair, HTTPS POST behavior, and DKIM coverage requirements.
Verified
Maintenance
- Owner
- Folderly Research + Deliverability Operations
- Next review
Review sooner when
Qualified next action
Review the message, then verify the live path.
Use the deliverability test for a pre-send, message-level review. Then complete the production-header, provider, and suppression checks above. A test result cannot guarantee inbox placement or substitute for evidence from the actual sending system.
Does finding SPF, DKIM, and DMARC in DNS mean the sender is ready?
No. DNS confirms configuration is present. Readiness requires a message sent through each real production path, received headers showing the actual SPF, DKIM, and DMARC results, and evidence that the passing SPF or DKIM identity aligns with the visible From domain for DMARC.
Do Gmail, Yahoo, and Outlook use the same sender rules?
No. Authentication concepts overlap, but each provider publishes its own scope, volume definitions, evidence surfaces, and enforcement details. Record the planned destination mix and test each applicable provider rather than treating one provider's dashboard as universal evidence.
When should the launch decision be no-go?
Use no-go when an active send path is missing from the inventory, a production sample fails required authentication or alignment, applicable unsubscribe and suppression behavior has not been tested, or an open question could change the provider or compliance decision.
Does passing this verification guarantee inbox placement?
No. This guide verifies sender setup and preserves a reviewable release decision. Inbox placement also depends on provider evaluation, recipient response, list quality, content, sending behavior, and other signals that can change after approval.
Related resources
Keep the next step focused.
Use these pages to move from draft quality to send readiness without opening another complex workflow.