Reviews
Part of Comparing email software when the verdict is a process rather than a winner
Email Marketing Software Selection Checklist: Sender Setup
Use this email marketing software selection checklist to check domain control, SPF, DKIM, DMARC alignment and unsubscribe handling before a pilot.
This email marketing software selection checklist is for a specific decision: can a candidate send using your organisation's domain and handle unsubscribe requests as required before a controlled pilot? It covers the evidence to request about domain setup, authentication and suppression, not a product ranking or a full software review.
Set the sender boundary
Record the From domain recipients will see, the pilot's message types and who controls your DNS. Ask which sending domains and subdomains the service will use, including for signing and bounce handling. A general claim of authentication support does not show it can be configured for your domain.
Purpose and boundaries gates
- Name one message purpose
- Define sender, recipient, operator, owner
- Record source systems, volumes, retention
- Cost manual process and no-send
- Freeze product, edition, region, date
Use this boundary to keep supplier answers specific. Ask for the records and configuration instructions for the exact sending arrangement proposed; distinguish what the supplier configures from what your organisation must publish or maintain. Never treat access to the platform as proof that the person configuring it has authority to change your DNS.
Keep the legal permission assessment separate from technical sender setup: a successful authentication check does not establish permission to send. Assess the applicable subscriber and channel separately using the lawful basis guidance.
Checklist: domain authentication the candidate must support
Request a proposed configuration for SPF, DKIM and DMARC, then check each item against the domains and sending services you actually use.
- SPF:Ask which domain the service uses for its sending path and what DNS change it requires. Check the proposed change against the organisation's existing senders rather than accepting generic setup instructions.
- DKIM:Ask the supplier to identify the domain used to sign messages and provide the DNS record or records needed for your setup. Confirm that the proposed signing identity is suitable for the domain recipients will see.
- DMARC:Ask how the candidate's SPF and DKIM results relate to the visible From domain. DMARC checks alignment between the visible From domain and an authenticated sending identity; a pass from one mechanism alone is not enough if it is not aligned.
- Reporting and policy:Establish how your organisation will review DMARC reports and who approves any change to its policy. Do not let a supplier's setup instructions silently replace the organisation's existing policy.
- Ownership and changes:Record who can publish, amend and remove the DNS records, and what happens to the configuration if the pilot ends or the supplier changes its sending setup.
Have the candidate explain its requirements against your current domain configuration. A proposed record that conflicts with another sending service, or an answer that leaves responsibility for an essential change unclear, needs resolution before testing. Ask for the supplier's configuration documentation and a named support route for setup questions. Check the answers against your vendor due diligence record.
Test role separation between people who can edit DNS, configure the platform and authorise a test. The organisation should retain control of its domain and decide whether a proposed change is safe to make.
Checklist: unsubscribe and suppression behaviour
Authentication identifies the sending service; it does not ensure recipients can stop messages. For bulk marketing, test the candidate's opt-out handling and support for one-click unsubscribe. The bulk-mail authentication and unsubscribe guidance describes one-click unsubscribe support in connection with RFC 8058.
Permission and data gates
- Map acquisition routes to evidence
- Assess UK GDPR basis separately from PECR
- Prove suppression survives import and restore
- Identify pixels, redirects, device storage
- Minimise fields and set retention rules
For the candidate, check that:
- A recipient can unsubscribe through the message, and the platform can apply that request to the intended marketing audience.
- The service supports the RFC 8058 one-click mechanism and can demonstrate how it is enabled for the proposed sending configuration.
- The visible unsubscribe route and the one-click mechanism lead to effective suppression, rather than merely recording a preference that still allows another campaign to send.
- Suppressions remain effective when contact records are imported or synchronised, and when a list is restored.
- The organisation can tell which account, integration or authorised operator changed a suppression, and can retrieve the relevant record.
Check permission and suppression data alongside this technical test, using the quality checks on suppression. The UK GDPR lawful basis and the PECR rule for the actual channel and subscriber are separate questions; a platform setting does not answer either one.
The ICO's electronic mail marketing checklist asks senders to keep a do not contact list of anyone who opts out or unsubscribes. Make sure the proposed test data and audience categories preserve the distinctions your organisation needs to apply those rules.
Run a domain-and-unsubscribe test before live sending
Use a controlled test environment and synthetic contacts. Before sending, compare the supplier's documented configuration with the DNS changes approved by your domain owner. After the test message arrives, inspect its authentication results and confirm that SPF, DKIM and DMARC behave as intended for the visible From domain.
Then exercise both unsubscribe routes using test recipients. Check that a one-click request takes effect, that the recipient is suppressed from the relevant marketing audience and that a later import or synchronisation does not put that address back into an eligible state. Do not use a real recipient to find out whether suppression works.
Record the candidate's exact product and sending configuration, the test date, the person who ran each check, the result and any unresolved dependency. Capture the supplier's relevant setup instructions and the test message's headers so another operator can understand what was tested. This record covers the setup you tested, not every future configuration or message.
If a test fails, ask whether the cause is a missing DNS change, an unsupported platform capability or an issue in your own configuration. Resolve the cause and repeat the affected check before authorising a pilot. If the supplier cannot show how one-click unsubscribe works or how a request results in suppression, a general claim of support is not proof.
Decide whether the setup is ready for a pilot
Allow the candidate to proceed only when your domain owner can account for the required DNS changes, authentication results suit the sending domain, and both unsubscribe routes have been demonstrated to produce suppression. Make any remaining responsibility explicit, such as who monitors reports and approves later DNS changes.
Hold the decision if a required record, alignment result or unsubscribe behaviour is unknown. Stop this proposed setup if the candidate cannot support a required capability or if the organisation cannot safely control the domain changes. These are decisions about sender setup, not a general judgement that the software is suitable for every use. Comparing suppliers is a separate process.
Approve only a bounded trial once the setup has passed these checks. Define who may change the sending configuration and who can halt sending if authentication or suppression stops working.
