What proof of domain ownership is acceptable?

Provide either registrar account access screenshots showing control, a TXT record placed at the DNS root for token verification, or an administrative email confirmation from the domain registrar. Exact token values and timestamps help IT verify ownership quickly.

Who must sign or approve the request?

Require the requester, a designated IT approver, a security/compliance reviewer if applicable, and an authorized business owner who has decision authority over communications or customer contact changes.

Is notarization or in-person signing required?

Not typically. Most domain change requests are administrative and can be signed electronically. If a third party or legal requirement demands notarization, follow state notary rules or remote online notarization (RON) processes where permitted.

How long should I wait after changing DNS records?

Propagation can be near-instant for low TTLs but commonly takes 24–72 hours for full global propagation. Validate mail routing, SPF/DKIM/Dmarc behavior, and certificate issuance where relevant.

What if a vendor or partner still receives mail at the old domain?

Maintain appropriate forwarding or bounce-handling on the old domain for a transitional period, notify external partners in advance, and monitor for undelivered important messages to re-establish communication quickly.

How long must I retain the signed request?

Retain the signed request and audit trail at least as long as operational needs dictate; follow federal retention baselines where applicable (e.g., IRS 3 years) and industry rules such as HIPAA six-year retention for healthcare-related records.

Electronic Signature
Templates
Miscellaneous
Email Domain Change Request

Email Domain Change Request

This template is fully customizable. Edit the text, fill out the fields, and send it for signature. Give it a try!

EMAIL DOMAIN CHANGE REQUEST

Parties

Service Provider Name Service Provider Contact Client Name Client Contact

Recitals

WHEREAS, Service Provider provides email hosting, routing, and related administrative services to Client pursuant to existing agreements and operational procedures; and

WHEREAS, Client requires a permanent change to the email domain used for outbound and inbound mail for specified user accounts and requests Service Provider to implement such change from the Current Domain to the New Domain identified below; and

WHEREAS, Service Provider and Client desire to document the scope, schedule, payment, and responsibilities associated with the requested email domain change.

Request Details

Current Domain:

Requested New Domain:

Effective Change Date (requested):

Scope of Work

Detailed Scope

Payment Terms

Service Fee Amount:

Payment Schedule and Milestones

Late Payment Fee:

Billing Contact / Invoice Address

Term and Termination

Term Commencement Date:

Term End Date (if applicable):

Either party may terminate this Request for convenience upon written notice delivered at least days prior to the intended termination date. Termination for material breach may be immediate if the breaching party fails to cure within thirty (30) days after written notice.

Confidentiality

Each party acknowledges that in the course of performance under this Request it may receive or have access to confidential information of the other party. "Confidential Information" includes nonpublic technical, business, financial and customer data, DNS and MX configuration details, migration plans, and any proprietary processes. Each party shall (i) hold Confidential Information in strict confidence, (ii) use Confidential Information solely for the purpose of performing obligations under this Request, and (iii) disclose Confidential Information only to employees, subcontractors, or agents who have a need to know and are bound by confidentiality obligations no less protective than those set forth herein. Confidential Information does not include information that is or becomes publicly available through no wrongful act of the receiving party or that is independently developed without use of the disclosing party's Confidential Information.

Service Levels and Responsibilities

Service Provider will perform the services with commercially reasonable skill and care in accordance with industry standards. Client shall provide timely access to administrative accounts, DNS control panels, and any required authorization to modify DNS records and account settings. Delays caused by Client's failure to provide required information or approvals may result in schedule adjustments and additional charges.

Warranties, Limitation of Liability

Each party represents that it has authority to enter into this Request. EXCEPT AS EXPRESSLY SET FORTH HEREIN, SERVICE PROVIDER DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL EITHER PARTY BE LIABLE FOR INDIRECT, INCIDENTAL, SPECIAL OR CONSEQUENTIAL DAMAGES, AND EACH PARTY'S AGGREGATE LIABILITY FOR DIRECT DAMAGES ARISING OUT OF OR IN CONNECTION WITH THIS REQUEST SHALL NOT EXCEED THE TOTAL AMOUNTS PAID OR PAYABLE BY CLIENT UNDER THIS REQUEST FOR THE APPLICABLE SERVICE.

Governing Law

This Request shall be governed by and construed in accordance with the laws of the jurisdiction specified below, without regard to its conflict of laws principles.

Governing Jurisdiction

Entire Agreement

This Request, together with any attachments, exhibits, and any controlling master services agreement between the parties, constitutes the entire agreement and understanding between the parties with respect to the subject matter hereof and supersedes all prior and contemporaneous agreements, proposals, negotiations and communications, whether written or oral. No modification of this Request shall be effective unless in writing and signed by authorized representatives of both parties.

Notices

All notices required or permitted under this Request shall be in writing and delivered to the billing/contact addresses provided above or to such other address as a party designates in writing. Notice is effective upon receipt.

Acceptance

By signing below, each party certifies that it is authorized to enter into this Email Domain Change Request, that all information provided is accurate, and that the parties agree to the terms and conditions set forth herein.

Service Provider:

By:

Date:

Client:

By:

Date:

What an Email Domain Change Request is and when it's used

An Email Domain Change Request is a formal, auditable record used to authorize, track, and approve replacement or consolidation of an organization email domain (for example migrating from @oldco.com to @newco.com). It documents requester identity, proof of domain ownership, technical DNS actions required, and approvals from IT and authorized business owners. The form helps coordinate timing, reduce delivery failures, ensure security controls remain in place, and create a retained record of who approved the change and when it took effect.

Why use a formal request for changing an email domain

A documented Email Domain Change Request reduces operational risk by capturing authorization, proof of ownership, and required DNS changes; it supports auditability for compliance programs and creates an evidence trail you can retain under ESIGN (15 U.S.C. §7001) and UETA frameworks where applicable.

Which teams typically complete and approve this request

Common participants include the employee requesting the change, IT or DNS administrators, security or compliance reviewers, and an authorized business approver.

Requesting Employee — Submits domain details, business justification, and initial proof of ownership for IT to validate.
IT / DNS Administrator — Verifies DNS records, schedules changes, and documents propagation windows to minimize email disruption.
Compliance / Security Reviewer — Confirms policy adherence, checks certificate and SPF/DKIM/DMARC changes, and approves go/no-go.

Final signoff should come from an authorized signer with decision authority; record retention follows your corporate retention schedule and applicable federal rules.

Core elements every professional Email Domain Change Request contains

A complete request combines identity and authorization data with technical steps and an approval chain so IT can implement changes safely and with traceability.

Requester

Full legal name, job title, department and contact phone so approvers can validate the business need and reach the requester if questions arise.

Domain Details

Old and new domain names, intended cutover date, and DNS records to be updated (A, CNAME, MX, SPF, DKIM, DMARC) including exact record values.

Proof of Ownership

Evidence such as access to domain registrar account, TXT record proof, or administrative email verification showing authority over the new domain.

Technical Plan

Step-by-step DNS change checklist, rollback steps, anticipated propagation window, and post-change validation tasks (delivery checks, certificate renewal).

Approvals

Signatures or electronic approvals from IT, security/compliance, and an authorized business owner with authority to change official contact addresses.

Audit Metadata

Timestamps, approver identities, IP addresses, and change ticket or ticket number for cross-reference in incident and audit logs.

Required data elements at a glance

Requester Name: Full legal name

Old Domain: Exact domain string

New Domain: Exact domain string

Ownership Proof: Registrar/TXT proof

Authorized Signer: Name and title

Effective Date: MM/DD/YYYY

Step-by-step: complete and submit the request

Follow a simple sequence to collect proof, obtain approvals, schedule the DNS change, and validate post-cutover.

01

Prepare: Gather registrar access, TXT record details, and business justification.
02

Document: Fill the request form with exact DNS entries and cutover timing.
03

Approve: Route to IT, security, and an authorized business approver for signatures.
04

Implement: IT updates DNS, monitors propagation, and runs delivery tests.

Configuring the online workflow for this request

Design the digital workflow to collect fields, enforce required approvals, and capture an audit trail with timestamps and signer identity.

Field	Configuration
Requester	Required field with email and phone validation
Proof Upload	File field accepting PDF, PNG, JPG; required for submission
IT Approval	Conditional signer; required before security review
Security Review	Required role-based approval with comment field
Cutover Confirmation	Final checkbox and date with automated notification

Typical routing and handoffs after submission

The request follows a predictable path from intake through technical verification to final cutover confirmation.

Intake: Requester completes form and uploads proof of ownership.
IT Review: IT validates records and prepares a DNS change plan.
Security Check: Security reviews DMARC/SPF/DKIM impact and approves.
Cutover: IT implements DNS changes and confirms delivery success.

Digital submission and e-signature considerations

Use an e-signature-capable workflow tool that captures signer identity, timestamps, and an exportable audit trail for retention.

File formats: Accept PDF, DOCX, PNG, and JPG for proof uploads.
Audit trail: Capture signer email, IP, timestamp and action log.
Authentication: Support email verification, SMS code, or SSO for stronger signer attribution.

Typical timelines and processing expectations

Processing times vary by organization size and change complexity; set expectations for each stage and plan for DNS propagation delays.

Request Submission:

Submit at least 5 business days before desired cutover for routine changes.

IT Verification:

Allow 1–3 business days for IT to validate DNS and rollback plans.

Security Review:

Expect 1–2 business days for DMARC/SPF/DKIM impact assessment.

DNS Update:

Planned change may take effect within minutes but propagation can take up to 48–72 hours.

Post-Cutover Validation:

Allocate 1–2 business days to confirm mail delivery and certificate status.

Common preparation and implementation mistakes to avoid

Incomplete proof of ownership or an expired registrar session delays approval and can require re-initiation of the request process.
Using incorrect DNS values or omitting DKIM/SPF updates causes delivery failures and increases the risk of messages being marked as spam.
Scheduling cutovers without accounting for TTLs and propagation times creates email downtime across clients and third-party services.
Failing to notify vendors, partners, or certificate authorities in advance results in lost service notifications and broken integrations.

Operational and compliance risks from an incorrect change

Email Downtime: Lost or delayed messages

Delivery Failure: Increased bounce and spam rates

Data Exposure: Misconfigured forwarding risks leakage

Regulatory Impact: HIPAA/FERPA breaches risk sanctions

Business Disruption: Customer communications interrupted

Reputational Harm: Phishing and brand impersonation risk

Real-world examples of domain change coordination

Two brief illustrations show common motivations and how a documented request reduced risk and clarified responsibilities.

Martin Properties (small real estate firm)

The firm needed to consolidate two legacy domains after a merger

IT required registrar proof and a weekend cutover
Using a formal request scheduled DNS changes, reduced downtime, and preserved transactional email continuity across tenants and vendors.

Optica Ventures LLC (venture services)

Optica updated branding and required a controlled migration to a new domain

Security insisted on DKIM/SPF/DMARC checks before change
The documented approval chain and proof of ownership avoided certificate renewal gaps and prevented phishing risks during rollout.

Key milestones from submission to validated cutover

Organize the request into sequential milestones so stakeholders know when their action is required and what validation is expected at each stage.

01

1. Request Submitted

Requester provides domain details, proof, and preferred cutover window for IT planning.

02

2. Technical Validation

IT verifies DNS ownership proof, pre-authorizes required record changes, and prepares rollback steps.

03

3. Approvals Obtained

Security and business approvers sign off on the plan and confirm timing to external dependencies.

04

4. Cutover & Validation

IT implements DNS changes, monitors propagation, and confirms mail delivery and certificate health.

Frequently asked questions about Email Domain Change Requests

Answers to common questions on proof, timing, signing authority, and retention to help avoid delays and rework.

Need help? Contact support

What proof of domain ownership is acceptable?
Provide either registrar account access screenshots showing control, a TXT record placed at the DNS root for token verification, or an administrative email confirmation from the domain registrar. Exact token values and timestamps help IT verify ownership quickly.
Who must sign or approve the request?
Require the requester, a designated IT approver, a security/compliance reviewer if applicable, and an authorized business owner who has decision authority over communications or customer contact changes.
Is notarization or in-person signing required?
Not typically. Most domain change requests are administrative and can be signed electronically. If a third party or legal requirement demands notarization, follow state notary rules or remote online notarization (RON) processes where permitted.
How long should I wait after changing DNS records?
Propagation can be near-instant for low TTLs but commonly takes 24–72 hours for full global propagation. Validate mail routing, SPF/DKIM/Dmarc behavior, and certificate issuance where relevant.
What if a vendor or partner still receives mail at the old domain?
Maintain appropriate forwarding or bounce-handling on the old domain for a transitional period, notify external partners in advance, and monitor for undelivered important messages to re-establish communication quickly.
How long must I retain the signed request?
Retain the signed request and audit trail at least as long as operational needs dictate; follow federal retention baselines where applicable (e.g., IRS 3 years) and industry rules such as HIPAA six-year retention for healthcare-related records.

be ready to get more

Join over 28 million airSlate SignNow users

Sign Now