A website form email system is ready only when the enquiry survives independently of email and every related message has a verified sender, authenticated domain, monitored destination, observable delivery state, and tested failure path. A successful form animation does not prove that a customer received a confirmation or that staff received a notification.

For a Canadian contractor or service business, the practical release decision is:

Can a valid website enquiry be stored once, notify the right people through authenticated email, accept replies at a monitored address, expose delivery failures, and remain actionable when email is delayed or rejected?

This checklist owns the email transport and operational acceptance decision for website forms. The contractor quote-form checklist owns fields, validation, privacy notice, form submission, CRM creation, and the complete enquiry path. The domain and DNS handoff checklist owns preservation and control of the live DNS zone. This guide goes deeper on the mail identity, authentication, event states, and recovery work that those broader resources intentionally do not own.

It is implementation guidance, not legal advice and not a guarantee of inbox placement. Canadian electronic-message requirements depend on the message, purpose, relationship, content, recipient, sender, and applicable law. Mailbox providers also use changing private filtering systems beyond the controls described here.

Store the enquiry before attempting email

Email should report that an enquiry exists; it should not be the only copy of the enquiry. Persist the validated submission in the approved system before requesting either the customer confirmation or staff notification.

A durable sequence is:

  1. Validate and normalize the permitted fields on the server.
  2. Create one enquiry record with a unique, non-secret identifier.
  3. Return an accurate submission result to the visitor.
  4. Queue the approved email jobs with idempotency controls.
  5. Record provider acceptance, deferral, delivery, bounce, complaint, or other supported events against the enquiry.
  6. Escalate a failed notification through a separately tested operating path.

Do not delete or roll back a valid lead merely because an email provider is unavailable. Do not tell the visitor “we emailed you” until the application has at least accepted responsibility for requesting that message. Even then, explain the result conservatively: queued or provider-accepted does not mean delivered to an inbox.

The website response, CRM record, email job, and provider event need a shared correlation key. That key should not expose the person's email, phone number, address, or project description in a URL, subject line, analytics event, or public log.

Inventory every system that sends as the domain

Before changing DNS or enforcing a policy, inventory all legitimate senders. A contractor domain may send from:

  • employee mailboxes;
  • website form confirmations;
  • internal form notifications;
  • booking and rescheduling systems;
  • CRM automations;
  • invoice, estimate, and payment systems;
  • review-request or follow-up workflows;
  • help desk, chat, and support tools;
  • newsletters or marketing platforms; and
  • legacy hosting, printers, scanners, or applications.

For each sender, record the business owner, provider account, message purpose, visible From domain, envelope or return-path domain, DKIM signing domain and selector, sending IP responsibility, expected volume, recipient types, reply destination, bounce destination, and removal process.

Unknown senders are a deployment blocker for stronger DMARC enforcement. A DNS record copied from an old provider may authorize infrastructure that no longer has a business purpose. Conversely, removing an active provider from SPF or changing DMARC without a complete inventory can interrupt legitimate mail.

The Canadian Centre for Cyber Security's email configuration guidance recommends configuring SPF, DKIM, and DMARC and periodically reviewing DMARC results for important mail that may be blocked. Apply those controls as a maintained system, not three DNS strings pasted once.

Give form email a stable sender identity

A customer confirmation should come from an address the business controls and recipients can recognize. A staff notification should also use a controlled sender. Never put the visitor's submitted email address in the From field merely so staff can click Reply.

Using the visitor as From creates several problems:

  • the website is not authorized to send as the visitor's domain;
  • SPF, DKIM, or DMARC can fail or misalign;
  • a forged or mistyped address can make the message deceptive;
  • untrusted input enters a security-sensitive header; and
  • provider complaints appear to implicate an unrelated domain.

Use a controlled address such as website@ or notifications@ under an approved domain or subdomain. Put the validated visitor address in Reply-To only when the business wants staff replies to go there and the risk review permits it.

RFC 5322 distinguishes the message author in From, the transmission agent in Sender when applicable, and the optional address suggested for replies in Reply-To. The implementation should preserve those different jobs.

Validate the submitted email as data, not executable header content. Reject carriage returns, line feeds, or other input capable of adding headers, and use a maintained mail library rather than concatenating raw SMTP text. OWASP's input validation guidance recommends server-side syntactic and semantic validation as early as practical.

Understand what SPF proves

Sender Policy Framework lets a domain publish which hosts may use that domain in SMTP authorization identities. It does not authenticate the visible From address by itself, encrypt a message, or guarantee delivery.

RFC 7208 defines SPF evaluation for the SMTP MAIL FROM identity and, in some cases, the HELO identity. For website form mail, verify the actual return-path domain created by the email provider and how that provider authorizes it.

Check that:

  • every active sending service is intentionally represented;
  • the domain publishes one valid SPF policy rather than competing records;
  • mechanisms resolve within the protocol's DNS-lookup limits;
  • removed providers are removed after their last legitimate traffic ends;
  • the final qualifier reflects an approved policy decision; and
  • the tested message produces the expected SPF result at real recipients.

Do not add an include because a setup wizard displays it without confirming which domain it affects and which system owns it. Do not flatten provider records into fixed IP addresses unless the provider supports that design and someone will maintain the changes.

Verify DKIM signing from the actual sender

DomainKeys Identified Mail adds a cryptographic signature that lets a receiver verify selected message headers and body content against a public key in DNS. The signature identifies a signing domain and selector; it does not prove that every statement in the message is true.

RFC 6376 defines the signature and verification model. For every website email provider, send a real test and inspect the received headers. Confirm:

  • a DKIM signature exists where the design requires it;
  • verification passes at representative receiving systems;
  • the signing domain belongs to or is deliberately delegated by the business;
  • the selector resolves to the intended public key;
  • the provider protects and rotates the private key under a documented process;
  • template or forwarding changes do not unexpectedly break the signature; and
  • old selectors are retired only after no legitimate mail depends on them.

Publishing a DKIM key is not enough. The provider must sign the production message with the matching private key, and the receiving system must validate it.

Make DMARC alignment an explicit domain decision

DMARC connects the visible From domain to a passing SPF or DKIM identity through alignment. It also lets a domain publish receiver-handling policy and reporting destinations. Authentication and alignment are separate: a provider can pass SPF for its own domain while failing to align with the business domain shown to the customer.

RFC 7489 defines the DMARC model. For each message stream, capture:

  • visible From domain;
  • SPF result and authenticated domain;
  • DKIM result and signing domain;
  • SPF alignment result;
  • DKIM alignment result;
  • overall DMARC result; and
  • the published policy applied by the receiver.

DMARC can pass when either an aligned SPF identity or an aligned DKIM signature passes under the specified mode. A durable production design should not depend on an accidental provider default. Configure and test the identity the business intends to own.

Move from monitoring to quarantine or reject only after the complete sending inventory, aggregate reports, forwarding cases, subdomains, and vendor configurations have been reviewed. A strict policy can protect the domain from some spoofing, but an incomplete rollout can also reject legitimate mail.

DMARC reports are operational and security data. Limit access, validate report-processing tools, define retention, and avoid publishing a reporting address that no one monitors.

Treat mailbox-provider rules as separate requirements

SPF, DKIM, DMARC, and standards-compliant formatting are foundations, not an inbox guarantee. Receiving providers also consider reputation, complaints, volume, content, recipient engagement, IP history, and signals they may not disclose.

Google's current email sender guidelines set baseline requirements for mail sent to personal Gmail accounts and additional requirements for higher-volume senders. They cover authentication, DNS, TLS, message format, spam rate, alignment, and unsubscribe behaviour for applicable traffic. Yahoo publishes its own sender requirements and recommendations, while Microsoft has announced authentication requirements for high-volume consumer Outlook senders.

Record which policies apply to the business's actual volume, domains, recipients, and message types. Do not quote a bulk-sender threshold as though it were a safe harbour below which authentication or responsible sending no longer matters. Review the provider pages at implementation and during maintenance because their rules and enforcement can change.

Separate requested confirmations from promotion

A confirmation that acknowledges a submitted request has a different job from a newsletter, upsell, review request, reactivation campaign, or general promotion. Keep those purposes and eligibility rules separate.

For a website confirmation:

  • identify the business and the request being acknowledged;
  • state what was received without repeating unnecessary personal detail;
  • explain the next operational step accurately;
  • provide a monitored reply or contact path;
  • avoid inventing response times, availability, prices, or acceptance; and
  • do not use the message as a disguised promotional campaign.

The CRTC's CASL FAQ explains that whether a message is a commercial electronic message depends on its purposes and content, and it outlines consent, identification, and unsubscribe requirements where applicable. Responses to requests and requested quotes can involve specific exceptions or requirements. Do not ask the email template developer to make a universal legal classification. Have the approved reviewer determine the message type and required content for the actual workflow.

If promotional content is added later, treat that as a purpose and template change. Recheck consent, suppression, identification, unsubscribe, provider policy, and reporting rather than assuming the original form submission authorizes every future message.

Design customer confirmations for clarity and restraint

The confirmation should help the customer verify that the correct business received the request and understand what happens next. It should not expose the full form submission by default.

Include only the approved details. A short service category and reference may be enough. Avoid putting access instructions, sensitive property conditions, payment data, uploaded-file links, private notes, or full free-text descriptions into an ordinary email unless the security and privacy design specifically requires and protects them.

Build both HTML and useful plain-text representations. Use a real text heading hierarchy, descriptive links, sufficient contrast, meaningful alternative text for informative images, and a layout that remains readable when images are blocked or text is enlarged. Keep the critical acknowledgement and contact path in text rather than inside one image.

Test the message in representative mobile and desktop clients. A template preview cannot show every receiver rewrite, dark-mode change, clipped message, blocked asset, or link-protection redirect.

Make staff notifications actionable without leaking the lead

Internal notifications should point authorized staff to the system of record. They should not become an uncontrolled duplicate customer database spread across inboxes.

A useful staff notification can include:

  • controlled business identity;
  • non-sensitive enquiry reference;
  • approved service or routing category;
  • receipt time and assigned queue;
  • a link to the authenticated record; and
  • an escalation instruction if the record cannot be opened.

Avoid names, email addresses, phone numbers, street addresses, and project descriptions in subject lines, lock-screen previews, broad distribution lists, or logs unless there is an approved necessity. Do not attach customer uploads to routine notifications.

Use a role mailbox or queue with named ownership when more than one person may respond. Define who monitors it during normal hours, who covers absence, how duplicates are prevented, and how a reply becomes part of the CRM record. A notification sent to a departed employee's mailbox is technically delivered and operationally lost.

Keep reply routing under business control

Test customer replies and staff replies as separate paths.

For customer confirmations, decide whether replies go to a monitored business mailbox, support queue, or no-reply address with a clear alternative. A no-reply sender can reduce ambiguity for an unmonitored stream, but it is inappropriate if the message invites a response.

For staff notifications, a validated visitor address in Reply-To can make a deliberate reply easier, while From remains the authenticated business-controlled identity. Confirm that the email client uses the intended destination and that replies do not expose internal recipients or create a loop.

Test aliases, forwarding rules, shared-mailbox permissions, auto-replies, and provider routing. A working SMTP send says nothing about whether the destination mailbox is monitored or whether replies enter the approved customer record.

Model delivery as states, not a boolean

“Email sent” collapses several different facts. Use the provider's documented event model and preserve the original code or reason.

A practical state set is:

| State | Evidence and next decision | | --- | --- | | Queued | The application recorded an idempotent job but has not handed it to the provider | | Provider accepted | The provider accepted responsibility for processing; inbox delivery remains unproven | | Deferred | A temporary condition exists; retry ownership and next attempt are known | | Delivered | The receiving mail system accepted the message; inbox placement and reading remain unproven | | Bounced or rejected | The receiving system returned a failure; preserve the standardized and provider-specific reason | | Complained | A supported complaint signal arrived; apply the approved suppression and investigation process | | Suppressed | Policy or prior failure prevents a new attempt; expose this to authorized operators | | Unknown | No trustworthy terminal evidence is available; do not relabel it delivered |

RFC 5321 distinguishes temporary 4yz replies, for which retry may succeed, from permanent 5yz replies, where the exact request should not simply be repeated. Let the mail provider handle SMTP retry according to its documented service, and ensure the application does not create a second message every time it sees a delay.

Vendor labels such as “soft bounce” and “hard bounce” can hide important detail. Retain the actual enhanced status, diagnostic text where safe, attempt count, timestamp, message identifier, and provider documentation needed for support.

Make retries idempotent and bounded

A visitor may double-click, the application may time out after queueing, a worker may restart, or a webhook may be delivered more than once. Use a deterministic key for each intended message, such as enquiry ID plus template purpose and version.

Verify that:

  • one accepted enquiry creates at most one initial customer confirmation;
  • one event replay does not create another message;
  • a transient provider error follows a bounded retry policy;
  • a permanent recipient error does not loop;
  • manual resend requires authorization and records the reason;
  • a corrected address creates an explicit new attempt; and
  • duplicate provider webhooks update one message record safely.

Do not retry blindly across two providers. A failover provider can deliver a duplicate after the first provider recovers, and it may not share authentication, suppression, templates, or event semantics.

Protect provider credentials and event webhooks

Email API keys, SMTP credentials, DKIM private keys, and webhook secrets belong in protected configuration, never MDX, client-side code, form markup, analytics, screenshots, or command output.

Scope credentials to the required domain or stream where the provider supports it. Restrict account access, enable multifactor authentication, inventory administrators, rotate credentials through a tested process, and remove former users.

Treat delivery webhooks as untrusted public inputs. Verify the provider's current signature or authentication method, validate timestamps where supported, limit payload size, parse strictly, prevent replay from creating side effects, and log enough non-sensitive evidence to investigate. An unsigned request claiming “delivered” must not overwrite the authoritative state.

Run a production delivery matrix

Use controlled addresses and clearly labelled test enquiries. Test the deployed canonical form, production DNS, production provider, real templates, and actual downstream event processing.

| Test | Required evidence | | --- | --- | | Valid submission | One stored enquiry, one confirmation job, one staff notification job, and correct on-page result | | Authentication | Received headers show expected SPF, DKIM, DMARC, and alignment outcomes | | Gmail, Yahoo, Outlook, and business mailbox samples | Accepted, junked, rejected, or delivered outcome recorded without claiming universal coverage | | Customer reply | Reply reaches the monitored destination and can be connected to the correct enquiry | | Staff reply | Authenticated business identity is preserved and the reply does not expose unintended recipients | | Invalid visitor address | Enquiry remains stored; bounce or rejection is visible; no infinite retry occurs | | Provider outage | Form remains accurate, email job is recoverable, and staff escalation follows the approved fallback | | Duplicate submission or webhook | Idempotency prevents duplicate messages and duplicate lead actions | | Template rendering | HTML, plain text, mobile layout, blocked images, links, and essential content remain usable | | Sensitive-data check | Subjects, URLs, headers, analytics, logs, and notifications contain no unapproved customer detail | | DNS change | Authentication remains correct after propagation and rollback is available |

Inbox placement observed for a few test addresses is useful evidence, not a universal deliverability percentage. Never publish a made-up inbox rate. Record the date, receiver, provider message ID, authentication results, visible folder, template version, DNS state, and tester.

Create a form-email acceptance register

The final release record should contain:

  • sending-domain and subdomain ownership;
  • complete sender inventory;
  • message-purpose and legal-review decisions;
  • From, Sender, Reply-To, envelope, and bounce identities;
  • SPF, DKIM, and DMARC configuration and test results;
  • provider-account owner and credential scope;
  • customer and staff template versions;
  • queue, idempotency, retry, and suppression rules;
  • event-webhook verification and state mapping;
  • production test matrix and evidence;
  • monitored mailbox and escalation owners;
  • accepted limitations and remediation date; and
  • change triggers and next review date.

Use four release outcomes:

  • Pass: every required identity, authentication, routing, event, and recovery test matches the approved design.
  • Pass with recorded limitation: an authorized owner accepts a bounded limitation, compensating control, and dated remediation.
  • Fail: an essential sender, authentication result, monitored destination, stored lead, failure signal, or recovery path is missing.
  • Not applicable: the stream or capability does not exist, with evidence supporting that conclusion.

Maintain the system when anything around it changes

Re-run affected checks when the business adds or removes a form, provider, CRM, calendar, mailbox, domain, subdomain, DNS host, sending address, template, forwarding rule, webhook, campaign, or staff owner. Review current mailbox-provider requirements before a material sending change.

Monitor:

  • authentication failures and DMARC aggregate reports;
  • unusual bounce, complaint, deferral, or suppression changes;
  • message queues that stop progressing;
  • notifications with no assigned owner;
  • provider or DNS accounts with stale users;
  • expiring or rotated keys;
  • forms whose stored enquiries no longer match message events; and
  • templates that add new promotional or sensitive content.

The ongoing website maintenance guide explains how monitoring, routine changes, incidents, exclusions, and offboarding should be assigned after launch. Email delivery needs that ownership because a configuration can drift while the visible form still appears to work.

Scope the implementation around recoverable delivery

A responsible website-development scope should name the system of record, sending inventory, domain identities, authentication configuration, message purposes, templates, reply routes, provider states, retries, webhooks, tests, mailbox owners, escalation path, maintenance triggers, and exit plan.

Nexxen's website development service connects approved forms, CRM handoffs, calendars, analytics, and lead workflows with defined failure states. Before implementation, prepare the real sending-domain inventory, provider access, approved confirmation language, monitored destinations, DNS owner, privacy and CASL reviewers, and evidence required for launch acceptance.

This checklist is operational guidance, not legal, cybersecurity, privacy, accessibility, or mailbox-provider advice. Authentication improves identity and policy control but does not guarantee inbox placement, reading, replies, or lead outcomes. Test the exact production system and keep the final decision tied to dated evidence.