A marketing platform is a new route, not a replacement mailbox
A campaign service can send with your visible From address while using its own envelope domain and DKIM signature. Connecting it safely means giving that route an aligned identity without disturbing the mailbox, invoice system and website mail already using the domain.
The common failure is to follow a generic domain wizard as if it owns all email. An instruction to “connect the domain” can include verification tokens, DKIM records, a return-path CNAME or changes unrelated to ordinary receiving mail. Treat each requested record as a separate delegation with a named purpose.
The mechanism-led reframe is to onboard one message route. Preserve existing MX and authentication, give the campaign route its own owner and identifiers, test it end to end, and retain a rollback for only what was added.
Write the route contract before opening DNS
Record the platform account, business owner, technical owner, approved visible From address, monitored Reply-To mailbox, campaign type, sending subdomain if used, intended MAIL FROM domain, intended DKIM domain and selectors, unsubscribe owner, support contact and person authorised to pause sending.
Obtain account-specific setup instructions while signed in through the provider’s known address. Save the date and screen reference. Do not borrow DNS values from another customer or an undated blog. Distinguish an ownership-verification token from records that affect message authentication.
Set an exit condition too: how the account will stop sending, how contacts remain suppressed, which credentials will be revoked and when DNS delegations can be removed. Onboarding without retirement ownership creates forgotten authority.
See also how DMARC alignment works and, for a form or shop sender, authenticating website and application email.
If the sender is a form, shop or booking application instead, follow the website and application email guide for that route.
Preserve the current mail baseline
Export or record current MX, SPF, DKIM, DMARC and relevant CNAME records with fully qualified names, values and TTLs. Send controlled messages from staff mail and one critical application, then save From, envelope, DKIM and receiver authentication results. This is the control you will repeat later.
Do not replace MX records for a sending-only campaign platform unless receiving mail is an explicitly approved part of the design. Do not delete existing selectors or verification tokens merely because the new wizard does not recognise them. DNS contains records for several services.
If you cannot explain the existing SPF policy or identify who owns a requested hostname, stop before saving. A provider success screen is not worth a receiving-mail outage.
Choose an envelope design without SPF sprawl
SPF authorises the connecting host for a MAIL FROM or HELO domain. The policy is published at the identity being checked, and only one SPF record is permitted at an owner name. RFC 7208 defines the SPF identities, record selection and processing limits.
Find which MAIL FROM domain the platform will actually use. A custom return-path subdomain delegated to the provider can give route separation and relaxed DMARC alignment without adding another include to the root policy. If the provider instead requires an include in an existing policy, merge it into the single record only after mapping every current term and checking lookup expansion.
The trade-off is ownership. A delegated subdomain is clear but must be monitored and removed during retirement. A shared root policy looks simpler but couples unrelated senders and can approach processing limits. Choose from observed identities and provider support.
Give DKIM a distinct selector and aligned domain
DKIM signs message content and names a signing domain in d=. Its selector identifies the public key location beneath _domainkey. RFC 6376 defines selectors, signing domains and key retrieval. Use only values generated for your account and domain.
Compare each requested TXT or CNAME owner with live DNS. If the selector is occupied, do not overwrite it; request a supported alternative. Publish the public key or delegation only. The private key remains with the authorised signer.
After DNS validation, send a real campaign-format test. Confirm that the receiver records DKIM pass for a domain aligned with the visible From domain. A pass for the platform’s unrelated domain can be technically valid yet provide no DMARC alignment for your brand.
DMARC decides whether the new identities connect to From
DMARC uses a passing aligned SPF or DKIM identity to validate use of the Author Domain. RFC 9989 defines the pass relationship and relaxed or strict alignment. You need at least one aligned path, although maintaining both can provide resilience and clearer evidence.
Do not weaken organisation-wide alignment or policy to accommodate one platform. Configure the route’s custom return path or signing domain where supported. If the account cannot align either mechanism, use a business-controlled sending subdomain with an explicit risk decision or choose a service that supports the required identity.
Google requires authentication for mail to personal Gmail accounts and tells users of service providers to verify their domain mail is authenticated. Google’s current sender guidelines describe those requirements. Authentication still does not guarantee inbox placement or permission to contact recipients.
Exercise the whole campaign journey before launch
- Verify public DNS. Query every added owner name and record the answer and UTC time.
- Send to controlled recipients. Use the real template and link path across more than one mailbox service you operate.
- Inspect original-message evidence. Confirm From, Reply-To, envelope domain, DKIM domain, SPF, DKIM and DMARC.
- Use unsubscribe. Confirm the recipient is suppressed and a later import cannot silently reactivate it.
- Reply and handle a bounce. Verify the monitored mailbox and platform event ownership.
- Repeat baseline routes. Send staff mail and a critical application message after the DNS change.
Launch only to an approved audience under your organisation’s own permission and data-handling process. Begin at a controlled volume supported by the account, watch receiver responses and pause on unexpected failures or complaints.
If the platform also stores audience permissions and objections, use separate consent and suppression records rather than treating one status as proof of another.
Protect audience data as well as authentication evidence
The onboarding record should hold the route contract, provider account reference, DNS baseline, requested owner names, received test results and suppression-test outcome. Keep it away from campaign exports. The people checking DKIM do not need the audience list, and the people approving content do not need DNS recovery details. Link to controlled evidence stores instead of copying everything into one ticket.
Use test contacts created for the organisation, not a slice of the live audience. Redact subjects, personal addresses and tracking identifiers from headers while retaining From, Reply-To, Return-Path, signing domains and authentication verdicts. Suppression evidence can be a dated platform event and a controlled re-import attempt; it should not expose somebody’s marketing history to unrelated administrators.
The campaign owner should agree access and retention with the data owner before launch. DNS passwords, API tokens and DKIM private keys stay in approved systems. If platform support asks for a contact export or secret to diagnose domain authentication, refuse and escalate through the authenticated account channel. Stop onboarding when the route cannot be tested without using unapproved personal data.
Check the data owner and the campaign owner sign the same record before the first live launch, including who may add contacts, who may raise volume and who may pause. A marketing platform is also a place where bad audience hygiene becomes a complaint problem at a receiver you cannot control. Agreeing these boundaries up front means the technical configuration and the recipient rules change together, instead of being governed by separate teams with different definitions of success.
Prove the campaign route and the recipient controls together
Send the final campaign template from the actual platform account to controlled recipients. Check the visible From and Reply-To addresses, envelope domain, each DKIM signature and the receiver’s SPF, DKIM and DMARC results. Match those identities to the route contract and the DNS records added for this account. A platform “verified” screen confirms its own check, not what the recipient received.
Use the unsubscribe control, then try the organisation’s normal import process and confirm the address remains suppressed. Verify that replies reach the monitored mailbox and that a safe invalid test destination produces an event owned by the campaign team. After DNS work, repeat staff mail and one critical application from the saved baseline so campaign delegation has not displaced ordinary service.
Record launch readiness only when aligned authentication, suppression, replies and bounce ownership all work on the intended route. Keep queries, event records and redacted headers with UTC times. An unaligned provider signature, failed unsubscribe or altered staff result is a separate blocker, even if the campaign message reached an inbox.
Pause the launch when control of the route is incomplete
Do not launch if the provider asks to replace MX records without an approved receiving-mail design, an SPF change would create a second record, a DKIM selector is already occupied, or the visible From identity cannot align. Stop an active send if suppression fails, complaints rise unexpectedly, replies are unmonitored or ordinary business mail changes after the DNS edit.
Pause the campaign in the platform first, then use the agreed rollback for records added solely for that route when it is safe. Give the campaign owner, DNS administrator and provider support the route contract, public queries, event times and redacted headers. Keep the audience list and credentials out of that handover.
Do not loosen organisation-wide policy, import opted-out contacts again or switch domains to evade receiver controls. Resume only after the account owner can demonstrate the intended identities and the data owner accepts the audience and suppression controls.
Sources and further reading
- Google email sender guidelines
- RFC 7208: Sender Policy Framework
- RFC 6376: DomainKeys Identified Mail signatures
- RFC 9989: Domain-based message authentication, reporting and conformance