Quick answer: For the VIDsigner notification route documented by Signaturit, the sender address stays sign@vidsigner.net. Company branding is not permission to send from your own email domain. Do not add guessed Signaturit SPF includes or DKIM records to your DNS to change that address.
This guide covers VIDsigner notification identity and the documented branding options for Remote and Centralized signatures. It does not establish custom-domain settings for every Signaturit product, a different eSignature platform, or a separately contracted email integration. Confirm the product before applying advice found under the broader Signaturit name.
This is a source-document review, not a tested tenant configuration or live delivery audit.
What can you change?
Signaturit's sender-address guidance, states that “the email address sign@vidsigner.net must always remain.” The displayed sender name can be customised. That is a visible label, not a replacement address or an authenticated domain.
For example, a company name shown beside sign@vidsigner.net still identifies a message using the provider's address. Putting your own email address into a display-name field would not authenticate that address. Use a clear company name rather than a label that could confuse recipients about the actual sender.
SPF, DKIM and DMARC: who controls what?
SPF checks whether the sending server is authorised for the SMTP envelope sender domain, usually reflected in the delivered Return-Path. It does not authenticate a company display name. Publishing an extra SPF permission on your company domain cannot change which domain a received message actually uses.
DKIM verifies a cryptographic signature. The signature's d= value identifies its signing domain and s= identifies its selector. Those values must come from the actual message and the provider's real configuration, not from a guessed DNS hostname. You do not control the signing keys or DNS for vidsigner.net merely because you use the service.
DMARC connects the visible From address domain with a passing SPF or DKIM identity. For a message whose From address is sign@vidsigner.net, that comparison concerns vidsigner.net, not the company name displayed next to it. A passing result for an unrelated signing domain is not enough. See DMARC's identifier-alignment rules.
This guide supplies no customer SPF include, DKIM CNAME, selector or DMARC policy to publish. It also does not claim that every VIDsigner message currently passes authentication. That needs message-level evidence. Leave your existing mail records, MX routing and DMARC protection unchanged for this branding task.
Request the supported notification branding
The official notification-template article, documents a support-assisted workflow for Remote and Centralized signatures:
- Confirm that your account uses that VIDsigner notification route.
- Prepare a publicly reachable URL for your approved JPEG or PNG company logo. The vendor asks for its web address, not an image attachment.
- Choose the notification box colour as a hexadecimal value. The documented option excludes white.
- Ask
support@validatedid.comfor the branding change using those details. Include the intended account context through your established support channel, not credentials or document contents. - Ask support separately how to apply your desired sender display name. The sender-address article confirms that capability but does not publish a self-service menu or activation procedure.
Agree on the intended changes before they are made. Keep the prior branding details so support can restore them if needed. This is not a DNS migration, and a cosmetic change is not proof of SPF or DKIM activation.
Check a notification without guessing DNS records
Use an existing authorised notification, or arrange a controlled, non-sensitive test with an approved recipient. Do not send a real contract or trigger an unintended signing request just to test email. Open the received message's original headers, rather than a screenshot of its sender label.
- Confirm the actual From address and whether the message belongs to the intended VIDsigner workflow.
- Have the receiving mail administrator identify their trusted authentication results. A familiar
authserv-idlabel or a header near the top is not sufficient: results must be attributable to the receiver's known processing and trust boundary. RFC 8601 explains this distinction. - Record SPF's evaluated domain and result, DKIM's signing domain, selector and result, and the DMARC result. Keep signature validation separate from domain alignment. EmailAuth explains raw DKIM results versus aligned DKIM policy results.
- Check branding and delivery separately. Authentication success does not guarantee inbox placement, nor prove that a signing request is legitimate.
No account changes, message sends or header tests were performed to prepare this guide.
Troubleshooting and escalation
The company name changed, but the address did not: that matches the documented fixed-sender design. Changing DNS on your domain will not replace the provider's From address.
The notification uses another address or product: stop applying this guide. Ask support to identify the product, sending route and any account-specific custom-domain capability in writing before changing records.
Authentication fails or the message is missing: give the provider and receiving administrator the relevant timestamp, message identifier and redacted diagnostic results through an approved channel. Preserve the original for authorised investigation; do not publicly upload headers, signing links or documents. Ask them to investigate the actual sender, signature and receiver decision. Do not disable spam filtering, broadly allowlist domains or weaken your company's DMARC policy as a workaround.
You need your own From domain: obtain explicit documentation for a supported alternative product or route. Require the exact record owners and values, who activates them, how success is checked and how to roll back. The VIDsigner branding instructions alone do not establish that capability.
Common questions
Is there a Signaturit SPF record I should add for this VIDsigner route?
Not from this workflow. It documents a provider-owned sender address, not a customer-domain SPF onboarding process. Do not copy an include from another Signaturit product or a third-party example.
Does changing the logo enable DKIM for my domain?
No. Branding affects presentation. DKIM needs a real signing configuration and corresponding DNS under the signing domain's control.
Is a notification safe if DMARC passes?
A pass establishes domain authentication under the receiver's checks, not the legitimacy of the requested signature. Verify unexpected document requests through a contact channel you already trust before opening or signing anything.