Vendasta partner marketing and client-domain mail have separate configuration contexts. Establish which account sends the message before requesting DNS changes. A partner's verified domain is not evidence that every client domain is authenticated. Record the business owner and permission to change each client's DNS independently.
Use the correct account's records
For the partner domain, open Partner Center > Marketing > Email settings and locate the Email domains card. The current documentation describes four generated records: SPF TXT, DMARC TXT and two DKIM CNAMEs. Copy both DKIM records. For a client, use its Business App > Administration > Email configuration and Authorize a domain, then publish that client's displayed values and wait for verification. Vendasta authentication reference
Reconcile generated SPF and DMARC suggestions with existing policies instead of creating duplicates. Preserve other legitimate senders and approved reporting destinations. The documentation allows up to 72 hours for verification to appear; compare actual DNS answers and the exact account status before repeatedly recreating the records.
Diagnose delivery without changing unrelated policy
For a client website form, check the From domain and whether it is authorized in that client's account. A platform Delivered label can mean the receiving server accepted the message, not that it reached the inbox. Inspect quarantine and the received headers when accessible. Do not adopt overly broad troubleshooting shortcuts: an SPF pass is not caused by the terminal ~all or -all choice, and changing that terminal mechanism does not repair a passing-but-unaligned signature. Receiver filtering is not determined by one DNS switch. Use the standards-based acceptance checks below to separate authorization, alignment and placement.
Keep reporting destinations and retention decisions with the domain owner. Do not remove rua or ruf merely to silence report volume without understanding the visibility being lost. The provider’s simplified delivery tables do not override receiver discretion: p=none is not a promise of inbox delivery, and changing ~all to -all cannot alter a previously matched SPF pass.
Verify DNS and a real receiving result
Before changing partner or client marketing domain authorization, export the existing DNS values, record the approved diff and name the rollback owner. Confirm whether the DNS editor expects a relative label or a fully qualified name; doubling the domain suffix creates a record that no intended verifier will find. Query the actual owner name after saving, including any CNAME target, rather than relying on the editor's success banner.
SPF must remain one policy at the relevant domain and stay within the DNS-querying-term limits in RFC 7208. Adding an include does not itself establish alignment. Under RFC 9989, DMARC passes when at least one successful SPF or DKIM result aligns with the visible From domain under the applicable mode. Do not require both mechanisms to align as a condition imposed by the standard, and do not mistake a provider-domain pass for an aligned customer-domain pass.
Send a campaign or client notification from the exact account whose domain was authorized to a mailbox you control. Save the receiving system's trusted authentication results, visible From, envelope identity, DKIM d= and s= values, timestamp and provider status. A DNS lookup only shows the available key; RFC 6376 verification also evaluates the signature over the received message. Use non-sensitive content and avoid exposing full customer messages to public checkers.
Use a bounded acceptance and rollback decision
Fictional written diagnostic case only: VD-01 assumes the agency domain is verified in Partner Center while a form uses info@client.example from a client Business App whose domain is not verified. Email History says Delivered; the received folder, SPF and DKIM results are unknown. The client owner must authorize the correct domain in that client context and inspect a controlled received notification. Agency verification and an acceptance label do not close client alignment or inbox placement. No account, DNS, relay or message was tested for this example.
If the test fails, separate missing DNS, wrong selector, inactive provider configuration, unexpected routing and message modification before making another change. Retest the same workflow after each approved correction. Do not weaken the whole domain's DMARC policy to hide a single sender problem. Where rollback is needed, restore the approved prior routing or sender configuration and retain key records while queued signed messages still need them. Keep the test evidence and unresolved exceptions with the domain inventory. No tenant access, DNS change or real sending was performed in preparing this guide.
Keep an accountable acceptance record
Create one row per account, domain and materially different route. Record the business owner, DNS owner, change reference, intended From, observed From, envelope domain and SPF result, each DKIM d= and s= with its result, applicable alignment mode, trusted receiver and timestamp, provider activation state, placement observation, unresolved question and next action. Mark missing values unknown rather than treating them as pass or fail. The owner accepts only the intended route and identity supported by the recorded evidence; otherwise hold that route and follow the approved recovery plan.
Separate a passing message from enforcement readiness
RFC 9989 Section 7.4 requires valid DKIM for a domain publishing p=reject and cautions about indirect-mail interoperability. A single aligned SPF result does not by itself justify a reject-policy rollout. Review all legitimate routes and policy ownership separately from this provider setup.