Mailrelay SPF, DKIM and DMARC setup, step by step

To authenticate Mailrelay email, add include:spf.ipzmarketing.com to the appropriate existing SPF policy, publish Mailrelay's DKIM CNAME at ipz._domainkey.YOUR-DOMAIN pointing to dkim.ipzmarketing.com., and verify the domain in Settings → Email authentication. Keep the domain's existing DMARC protection. Then check a delivered message for a passing, aligned signature from your intended domain. Mailrelay sender authentication

This guide covers Mailrelay's email-marketing platform at mailrelay.com and its ipzmarketing.com account infrastructure. It also explains the documented SMTP bounce-domain option. It does not configure unrelated products called “mail relay,” and a campaign test does not validate every SMTP or API integration.

These are documented setup instructions and proposed checks. No customer account, DNS zone or delivered message was tested for this article.

Before you start: identify the account and sending domain

You need an address on a domain you control, access to its authoritative DNS, and access to the intended Mailrelay account. A personal Gmail or Outlook address does not give you permission to authenticate gmail.com or outlook.com. Mailrelay documents domain authentication on its free account as well as paid plans. Mailrelay setup overview and prerequisites

Record the following before changing anything:

• The exact account hostname, intended From address and Reply-To address.
• Whether you are validating a newsletter, automation, SMTP submission or API-triggered workflow.
• Existing SPF, DKIM and DMARC records, including other active senders.
• The DNS zone and authoritative nameservers, which may differ from the domain registrar.
• Who can pause the affected workflow and restore the previous, known-good configuration.

Keep a before-and-after change record. Do not replace a corporate email provider's MX records, erase its SPF authorization or remove its DKIM selectors to add Mailrelay.

If the domain also sends employee mail through Microsoft 365, preserve that independent sender configuration; see EmailAuth’s Microsoft 365 authentication guide.

Understand the four identities before editing DNS

SPF passes only when the connecting server is authorized for the evaluated envelope domain. An SPF include at example.com does not make a message use that domain in its envelope. Read the receiver's smtp.mailfrom result rather than assuming the visible From is the SPF identity. SPF identity

DMARC requires SPF to pass and align, or DKIM to pass and align. Relaxed alignment compares organizational domains; strict alignment requires an exact match with the From domain. For example, bounce.example.com can align with example.com under relaxed SPF alignment but not under aspf=s. A provider-owned envelope domain may pass SPF without aligning. An aligned DKIM pass can still satisfy DMARC. DMARC alignment

Add Mailrelay to SPF without losing existing senders

Mailrelay documents this authorization mechanism:

include:spf.ipzmarketing.com

Its full starter example is:

v=spf1 a mx include:spf.ipzmarketing.com -all

The starter is not a replacement for an existing policy. Inspect the current account instructions, inventory authorized senders, and merge only the required permission into the single SPF TXT record at the specified owner. The a and mx mechanisms also authorize addresses and consume lookup terms, so do not add them without checking that they belong in your sending policy. Mailrelay's SPF instructions

For example, if the current policy already contains approved services, insert the Mailrelay include before the terminal all mechanism while preserving those services and the intended ending qualifier. Do not paste multiple complete v=spf1 strings together or create a second SPF record. Unrelated TXT records can remain.

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

SPF permits no more than ten evaluated DNS-query-causing terms, including nested includes and redirects. Counting only the includes visible in the top-level record is insufficient. Resolve duplicate policies, syntax errors and lookup excess before sending. Do not replace a maintained provider include with a copied IP list unless you have an agreed process to track future provider changes. SPF publication and lookup limits

-all produces fail for an unmatched sender; ~all produces softfail, not pass. Neither qualifier determines inbox placement by itself. Keep a deliberate existing qualifier rather than tightening or weakening it as an incidental onboarding change. SPF results

Publish the DKIM CNAME and verify the correct domain

Mailrelay's current first-party guide documents this DKIM delegation for a From domain of example.com:

Owner: ipz._domainkey.example.com
Type: CNAME
Target: dkim.ipzmarketing.com.

Replace example.com with the domain you are authenticating. For news.example.com, the owner becomes ipz._domainkey.news.example.com. The selector is ipz in this documented workflow. Confirm the records displayed for your own domain before publishing; if your account supplies a different set, resolve that difference with Mailrelay rather than combining instructions from unrelated accounts. Mailrelay DKIM setup

The target is a hostname, not a TXT public-key string. Do not generate your own key, paste a private key into DNS or publish a TXT record alongside the CNAME. Mailrelay maintains the signing infrastructure behind the delegation. A DNS alias still does not prove that the actual message received a branded signature.

After publication, return to Settings → Email authentication and run the domain's available verification check. Check the intended sender domain, not just the account's generic hostname. Treat successful verification as a prerequisite for the message test, not as a substitute for it.

Configure tracking and SMTP bounces separately

The newer Mailrelay walkthrough uses Settings → Tracking and bounce domains. The help-center article also calls this area Custom Domain. Use the relevant account screen, choose Add, enter your unused subdomain without a URL scheme, and copy the CNAME displayed by the application. Then confirm that you added the records and run Verify or Check, as shown in that screen. Current walkthrough and custom-domain procedure

The structure below is illustrative. ACCOUNT-HOST is the exact target supplied by your account, not your company's domain name guessed into an address.

Owner: click.example.com
Type: CNAME
Target: ACCOUNT-HOST.ipzmarketing.com.

Use a hostname with no website, mailbox or validation dependency. Do not turn the root domain into a CNAME or replace a working From subdomain's SPF TXT record with a tracking alias. If the From domain is news.example.com, a distinct name such as click.news.example.com avoids placing the tracking CNAME at the same owner as the sending-domain records.

Mailrelay separately documents Enable asynchronous bounces. With that enabled, the custom domain is used as the Return-Path for SMTP mail, even when SMTP tracking is disabled. This is an SMTP-specific documented behavior, not proof that every newsletter or API workflow uses the same envelope. Check the actual Return-Path and SPF identity for each route. SMTP bounce behavior

At a bounce CNAME owner, do not add a competing SPF TXT record. Follow the issued alias and inspect the SPF answer reached through it. If the target's SPF fails, collect the message and DNS evidence for Mailrelay rather than editing DNS under a domain you do not control.

Check image loading and tracking destinations separately from authentication. Mailrelay warns that expired domains or deleted custom-domain CNAMEs can break images and links even while a dashboard still shows a previous successful DNS status. Do not remove an old tracking domain until you have considered links in messages already delivered. Custom-domain troubleshooting

Put records at the correct apex, child or delegated owner

A DNS editor's Host/Name is often relative to the zone being edited. These are owner-name examples, not instructions to create all records:

@ always means the apex of the zone open in the editor. Some systems accept full names instead; inspect the saved fully qualified owner to catch duplicated suffixes. If news.example.com has its own authoritative nameservers, publish its records in that child zone. Preserve the parent NS delegation. DNS zones and delegation

At an existing delegated _domainkey.news.example.com authority, the full DKIM owner ipz._domainkey.news.example.com maps to relative ipz. Preserve that NS delegation and other selectors; use the actual issued owner and authority. Relative names.

A CNAME cannot coexist with ordinary A, AAAA, MX or TXT data at the same owner. The normal zone apex also requires SOA and NS records and is unsuitable for these aliases. Resolve conflicts with the current service owner; do not delete unfamiliar records to force a save. DNS alias rules

For Cloudflare, keep the issued authentication and bounce CNAMEs DNS only and unflattened so the public alias remains visible. Check both per-record flattening and any “flatten all CNAMEs” zone setting, coordinating shared-setting changes with the DNS administrator. A DNS-only record can still be flattened. Cloudflare CNAME verification

Keep the required literal CNAME answer: turn relevant per-record Flatten off where available and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, apex CNAMEs are flattened by default and same-zone targets are flattened regardless of that setting; flatten-all cannot be overridden per record. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration without breaking other services or removing NS delegation. These are DNS-host behaviors, not controls assumed in the sending provider. Cloudflare flattening controls and limits.

Preserve DMARC and make reporting useful

Inspect the policy applying to the exact visible From domain, including inherited parent protection. Do not overwrite p=quarantine or p=reject with a generic starter, and do not create a weaker child policy without assessing what it previously inherited. Keep existing reporting and alignment choices unless the domain owner approves a change. DMARC policy discovery

For a domain with no established applicable policy, an owner-approved monitoring rollout can use this example after replacing the report address with a working, managed destination:

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Publish one applicable DMARC record at that owner. Mailrelay's minimal p=none example has no reporting address; it does not request aggregate reports by itself. p=none requests no DMARC-based enforcement, but receivers can still reject or filter mail for other reasons.

For the first-policy example, _dmarc.example.com maps to relative _dmarc in the example.com zone. The existing child owner _dmarc.news.example.com maps to _dmarc.news in that parent zone, but _dmarc at a separately delegated news.example.com authority. Preserve applicable policy and delegation.

Review reports for legitimate sources, authentication failures and alignment before a separate enforcement decision. An outside reporting service may need to authorize receiving reports for your domain. Do not add a vendor's reporting address or forensic reporting without reviewing access and privacy. DMARC aggregate reporting

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.

Verify public DNS before the controlled send

Replace all uppercase placeholders. ZONE is the authoritative parent or delegated child zone; SENDING-DOMAIN is the exact domain being authenticated. These commands are read-only examples, not results from a tested customer.

dig NS ZONE +short
dig @AUTHORITATIVE-NS SENDING-DOMAIN TXT +noall +answer
dig @AUTHORITATIVE-NS ipz._domainkey.SENDING-DOMAIN CNAME +noall +answer
dig @RECURSIVE-RESOLVER ipz._domainkey.SENDING-DOMAIN TXT +noall +answer
dig @AUTHORITATIVE-NS _dmarc.SENDING-DOMAIN TXT +noall +answer
dig @AUTHORITATIVE-NS CUSTOM-DOMAIN CNAME +noall +answer
dig @RECURSIVE-RESOLVER ACTUAL-MAIL-FROM-DOMAIN TXT +noall +answer

Check that the DKIM alias is exact and resolves to usable key data, the tracking/bounce target belongs to your account, the relevant SPF owner has one valid policy, and DMARC preserves the intended protection. Follow a delegated selector or child zone to its actual authority. Compare authoritative answers with a recursive resolver after the relevant cache TTLs expire.

An empty short answer is not proof that the record is missing. Repeat the lookup without output-shortening options to distinguish NXDOMAIN, no data, SERVFAIL and timeout. Fix authoritative errors first; waiting longer cannot fix a wrong owner or target. SPF validation also needs the recursive policy chain and connecting IP, not just visible TXT syntax.

Accept the setup only after inspecting delivered headers

Send harmless content to controlled external recipients through each actual workflow. A preview and an account badge are insufficient. Open the original received message and inspect the trusted receiver-added Authentication-Results. A familiar authserv-id or a header's position is not proof of origin: both can be forged. Use only results your receiving system or administrator confirms were added inside its trusted boundary, with untrusted look-alike fields removed. Authentication-Results trust boundary

Retain a private evidence row with:

DMARC can pass on SPF while the intended DKIM signature is absent or broken. That is not acceptance of this DKIM setup. Likewise, a valid vendor-domain signature does not substitute for the branded aligned signature you intended. DKIM verification and DMARC alignment

A genuine SPF fail, softfail, neutral, none, temperror or permerror must be investigated, even when DKIM makes DMARC pass. On a direct test, diagnose the exact envelope owner and authorization chain; for a provider-owned owner, escalate with the connecting IP, timestamp and receiver result. For a forwarded message, compare a direct delivery before changing the origin policy. A passing but unaligned provider-envelope result is a different condition and should be documented, not “fixed” with an unrelated root include.

Diagnose the actual smtp.mailfrom result independently: fail or softfail calls for checking the connecting sender against the approved authorization; temperror is a transient evaluation failure, often DNS; permerror requires checking malformed or duplicate policies and the evaluated lookup budget. An aligned DKIM pass does not repair these SPF faults. Do not change an unrelated apex policy to fix a provider-controlled envelope domain. SPF result definitions.

Troubleshooting Mailrelay authentication

Pause the affected workflow while repairing an unverified identity. Restore only the recorded changes in your recovery plan, preserving unrelated senders and security policy. Retain old working keys and aliases until dependent traffic and previously sent messages have been assessed.