Source review dated 8 November 2026. Provider settings and acceptance exercises below are documentary guidance, not executed account, DNS or message tests.
Establish which Mailrelay route is sending
This guide covers the Mailrelay email-marketing account documented at mailrelay.com and help.mailrelay.com, with authentication settings associated with ipzmarketing.com. A similarly named SMTP relay service is not automatically the same product. Record the account hostname, campaign owner, intended From address, DNS zone and workflow before using the instructions. The provider requires a domain whose DNS you can manage; a consumer Gmail or Outlook address cannot be authenticated as your own domain. Mailrelay setup and verification guide.
Create a small change plan before opening DNS. List the ordinary corporate mail platform, other approved sending services and any active Mailrelay automations using the same domain. Assign separate owners for campaign configuration, DNS publication and mail-security acceptance. Preserve the current DNS answers and a baseline message where available. If an API or transactional route also sends mail, identify it separately and require evidence from that route; a newsletter test does not establish every application's sending behavior.
Choose one controlled recipient and harmless campaign content. Record the expected From address and intended reply destination before the test. That makes an unexpected provider-domain sender, a stale campaign address or a mistaken account easier to detect. Do not use a large production audience simply to obtain authentication evidence.
Publish the provider's records without replacing other senders
Mailrelay's first-party instructions specify the SPF include include:spf.ipzmarketing.com. Add it to the existing SPF policy at the correct owner when applicable, preserving other legitimate senders. Its documented DKIM delegation is a CNAME at ipz._domainkey.<your-domain> pointing to dkim.ipzmarketing.com.. Replace only the example domain with the real domain; confirm that the current account instructions still match before applying either change. Mailrelay sender authentication.
Write the change request as explicit owner, record type, value, purpose and rollback value. Many DNS interfaces automatically append the zone name. Inspect the resulting fully qualified owner so that ipz._domainkey is not accidentally published beneath a duplicated domain suffix. A CNAME owner cannot also host a conflicting record. If the proposed selector is already occupied, stop and resolve the collision with the administrator and provider rather than deleting an unknown service's record.
The published complete SPF example includes additional mechanisms. Do not replace an established corporate policy with that example or add mechanisms whose authorization has not been reviewed. SPF permits only one applicable policy and has a limit of ten evaluated DNS-causing terms under §4.6.4, including nested evaluations; this is not a packet-count limit. Retain a before-and-after policy comparison and assess the effective lookup cost rather than counting only visible includes. In particular, ~all produces softfail rather than pass or guaranteed acceptance. The terminal qualifier reports an SPF result; it does not itself guarantee how every receiving system will deliver a message. SPF specification.
Separate link branding from SMTP bounce configuration
Mailrelay's custom-domain configuration changes tracking links and image URLs. The documented flow creates a chosen subdomain CNAME to the account's ipzmarketing.com hostname, then adds and activates it under Settings > Custom domains. Obtain the exact account target instead of treating yourdomain.ipzmarketing.com as a literal value or deriving it from the company's public website name. Custom-domain setup.
Reserve a hostname with no existing website, mail or validation dependency. After activation, check an actual rendered message's image URLs and tracking links. Confirm that a harmless link opens its intended destination, not merely that the DNS alias resolves. Keep the previous branding configuration available until that functional check succeeds. Do not change the corporate root MX records to enable tracking: the documented branding step calls for a CNAME at its selected subdomain.
The updated first-party setup guide, dated 7 November 2026, gives a newer Settings > Tracking and bounce domains flow: Add, enter the chosen subdomain, publish the exact displayed CNAME, then Verify. It separately instructs enabling asynchronous bounce and states that this uses the custom domain as Return-Path for messages sent via SMTP. This documents an SMTP capability, not proof that every newsletter or API route uses it. Confirm which interface the current account exposes and record asynchronous-bounce activation separately from tracking activation. Inspect an actual SMTP message’s Return-Path and SPF result before claiming alignment. A branded click URL alone still proves neither. Updated custom-domain procedure.
Preserve the domain's DMARC policy
Mailrelay shows a monitoring-policy example, but an organization may already have an enforced DMARC policy covering several business systems. Inspect that policy and its applicable domain scope before making a change. Do not replace an existing quarantine or reject policy with a generic p=none value to obtain a green setup indicator. A policy of none requests no DMARC-based disposition; it does not guarantee inbox delivery or prevent a receiver from applying other controls. DMARC specification.
For this route, compare the visible From domain with the domain authenticated by SPF and with each successful DKIM signature's d= domain. Apply the published alignment mode rather than assuming that any related-looking string qualifies. Reply-To, display name and tracking hostname are separate identities. A passing aligned DKIM signature can satisfy DMARC even if SPF passes under an unaligned provider domain. Conversely, SPF and DKIM can both pass without establishing an aligned path for the visible From address.
Verify application status and the received newsletter
Use Settings > Email authentication to check the intended domain. The provider also recommends sending a test newsletter and opening the recipient's original-message view, such as Gmail's Show original. Run both checks: the account panel examines expected configuration, while the received message shows what the selected campaign actually emitted. Mailrelay verification instructions.
The required original received-message identity table has not been populated here. Create one row per tested account, From domain and workflow. Each row should contain send time, campaign identifier, visible From, Reply-To, Return-Path, receiver-evaluated SPF domain and result, every DKIM d=/s= pair and result, alignment assessment, DMARC result, tracking domain, functional reply outcome and a restricted evidence location. Record observed values rather than copying expected DNS settings into the result columns. Preserve the trusted receiver's Authentication-Results together with the original source so that the reviewer can distinguish receiver results from untrusted headers.
A DKIM signature authenticates signed material and a domain identity; it does not encrypt the email or certify the truth of its content. Record the actual selector used even when it matches the expected ipz delegation. If a gateway changes the message after signing, compare a direct-delivery test with the affected route before deciding that the DNS key is wrong. DKIM specification.
Diagnose failures and recover narrowly
If the account reports missing DNS, check authoritative owner names, record type, CNAME target and caching before repeating edits. If DNS is correct but the signature is absent or uses an unexpected domain, check the campaign's actual sender and account settings, then ask Mailrelay support to explain that route using sanitized headers. If DMARC fails despite authentication passes, investigate alignment. If authentication passes but delivery is poor, examine the receiver's rejection or filtering evidence rather than repeatedly changing DNS.
Pause the affected campaign if its identity is uncertain. Restore only the approved configuration changes when rollback is necessary, retaining unrelated SPF senders and the organization's DMARC enforcement. Test replies and branded links after recovery. When retiring Mailrelay, first stop dependent campaigns and integrations, then review whether its DNS authorizations and delegated selector can safely be removed. No account, live DNS or received message was inspected in this research. Exact-route testing, the original identity table, FAQ relevance review and human mail-security SME approval remain open; this is an unpublished candidate.