iPost SPF, DKIM and DMARC setup, step by step

For iPost email sending, the preferred setup is to delegate an unused sending subdomain to iPost's two nameservers. iPost then manages that child domain's SPF, DKIM and other mail records. If NS delegation is unavailable, ask iPost Support for its CNAME alternative: an account-specific alias target, a separately issued DKIM TXT record and provider acceptance are required. Do not add SPF TXT beside the CNAME at the same owner. iPost delegation overview, Using a CNAME

This guide covers the iPost marketing platform. It does not cover Pepipost/Netcore Email API, transferring your parent domain's nameservers, or iPost's exceptional client-hosted DNS arrangement. Select the branch agreed with your iPost account team, preserve your intended visible From address, and validate both the branded signature and DMARC on received mail.

No customer account, DNS configuration, provider acceptance or delivered message was tested for this article. All diagnostic steps below are proposed checks.

Choose the correct iPost domain setup

iPost identifies NS delegation as its preferred approach. Client-hosted name service requires prior technical approval and hourly charges, and is outside this procedure. The reviewed setup pages do not specify an exact subscription tier or minimum named user role; arrange the required account and DNS-admin access rather than assuming those permissions are available. Delegation options

1. Inventory the domain before delegating or aliasing it

Choose a deliberate, unused child such as news.example.com. The examples in this article are placeholders, not your account values. Before making a change, record:

• The exact intended visible From address and domain.
• The chosen iPost subdomain, account and responsible Customer Success Manager or Support contact.
• The real authoritative DNS zone and its nameservers, which may differ from your registrar.
• Existing A, AAAA, MX, TXT, CNAME, NS, certificate-validation and security dependencies at or below the chosen name.
• Any current SPF policy, active DKIM selectors, direct or inherited DMARC policy, approved report destinations and policy owner.
• Existing mailbox, reply-processing, website, asset-hosting and tracking use of the subtree.

NS delegation changes who answers for the child zone. A record left under that child in the former parent zone may no longer be the record resolvers use. Do not delegate an active mailbox or website subtree and hope its dependencies survive. Choose an unused child, or arrange an explicit migration with all affected owners. Preserve the parent domain's MX, website records and nameservers.

A CNAME also needs a suitable unused owner. It cannot coexist at the same owner with ordinary A, MX or TXT records. Different descendants, such as SELECTOR._domainkey.news.example.com, are separate owners, but their actual authoritative zone still matters. An existing NS delegation must be reconciled before attempting a different alias design. iPost parent-domain identification, DNS alias rules

Use a zone export and dependency inventory rather than a DNS ANY query as your record inventory. Where DNSSEC or an existing child delegation is involved, have the DNS administrator review the chain of authority. Do not disable DNSSEC or change parent nameservers to bypass a setup error.

2A. Preferred route: create the child NS delegation

Coordinate the chosen domain and provisioning with iPost. In the authoritative parent zone for the selected child, publish the two nameserver records from iPost's current procedure. For news.example.com within the example.com zone, the structure is:

news.example.com. IN NS dns01.ipost.com.
news.example.com. IN NS dns01.smf.ipost.com.

These are two separate records at one owner. In a panel that appends example.com, enter news as the owner. In a full-name field, enter news.example.com. If the parent zone is itself a subdomain, calculate the owner relative to that actual zone. Do not enter @ unless it truly represents the intended owner in the selected interface.

Use the provider's default TTL or the TTL agreed with your DNS administrator; iPost's generic example uses 3600 seconds. In a BIND-style zone file, the trailing dots keep the targets absolute. Publish the hostnames, not static IPs copied from an old example. These nameservers are outside the delegated child, so this particular setup does not require in-child glue records. Creating NS records

This is not a registrar nameserver replacement for example.com. Keep its existing authoritative nameservers. You are adding delegation records for news.example.com within the parent zone, not moving the organization's entire DNS to iPost.

iPost's NS guide says it creates the remaining child A, MX, SPF, DKIM, DomainKeys and DMARC records. Do not manually add a parallel SPF policy or guessed DKIM selector in the old parent zone. Request confirmation of the actual signing domain, selector and intended child DMARC policy during onboarding. Legacy DomainKeys records are not evidence of a modern DKIM pass. Confirm the child policy and reporting choices before relying on them. iPost-managed records, Why delegate a subdomain?

2B. Alternative route: provision the CNAME with Support

Use this branch only when it is the agreed design. Do not combine it with the NS branch at the same owner.

1. Give your iPost CSM or Support the desired subdomain and explain that you need the CNAME setup.
2. Wait for iPost to supply the account-specific target. Its documentation illustrates names under ip02.com or a similar domain; that is a pattern, not a target to invent.
3. Publish a CNAME from your chosen subdomain to the exact issued target. Keep a copy of the supplied record set.
4. Notify iPost after publication. Support validates the alias and accepts it in iPost's system.
5. Publish the separately issued DKIM TXT record with its real owner, selector and public-key value.
6. Contact iPost again once both records are present so the complete setup is accepted. A visible DNS record alone is not provider acceptance.

The resulting record types have this relationship. This is an explanatory template, not a paste-ready zone file:

news.example.com. IN CNAME ACCOUNT_SPECIFIC_IPOST_TARGET.
SELECTOR._domainkey.news.example.com. IN TXT "ACCOUNT_ISSUED_DKIM_PUBLIC_RECORD"

The underscore in _domainkey is required. iPost's current full CNAME guide uses that spelling. Use the account-issued selector rather than assuming every customer uses the sample dkim1. The exact d= in the eventual signature determines the signing domain used in the key lookup.

For a parent example.com zone, a key under news.example.com would usually have a relative owner such as SELECTOR._domainkey.news. If news.example.com is a separate authoritative zone, the relative owner would be SELECTOR._domainkey, but that existing delegation must first be compatible with the agreed CNAME design. Verify the resulting full owner, not just what the editor displays.

Copy the actual public key from iPost, never the sample key. Some DNS tools display long TXT values as adjacent quoted strings. Their contents form one logical record without added spaces. Use your DNS host's expected entry format, preserve the complete p= value and avoid adding display quotes, whitespace inside the key or separate TXT records for the chunks. Never request or publish the private signing key. iPost CNAME and DKIM procedure, DKIM key retrieval

Resolve the SPF documentation conflict before publishing

iPost's detailed Using a CNAME page says iPost creates SPF and that the CNAME resolves the required TXT data. Its Delegation Overview more broadly says the CNAME option requires manual SPF and DKIM TXT records. These descriptions are not fully consistent.

For the detailed alias procedure above, do not add an SPF TXT record at news.example.com beside its CNAME. Ask Support to confirm the precise owner and design if its issued record set appears to require both. If a separate SPF owner or a different architecture is intended, have Support reconcile the records before proceeding. Do not “fix” the discrepancy by editing your parent-domain SPF or replacing a working alias. Detailed SPF note, Overview wording

Preserve the literal CNAME and certificate setup

If your DNS host offers an HTTP proxy, use DNS-only for the provider-required alias unless iPost explicitly documents another arrangement. Also check per-record flattening and zone-wide flattening: a dashboard can show “CNAME” while public DNS returns only addresses, preventing literal-CNAME validation.

Cloudflare automatically flattens apex CNAMEs and same-zone targets. Its paid zone-wide flattening option cannot be overridden per record. A name that looks like an ordinary subdomain can still be the apex of a separately delegated zone, where a conventional CNAME conflicts with required apex records. Do not broadly change a shared zone's proxy, flattening or security settings for this one record. Ask the DNS owner and iPost for a suitable unused non-apex owner or another supported design. Cloudflare flattening behavior

iPost also supplies an additional certificate-validation CNAME and may require certificate-authority authorization changes. Its two pages differ on whether a CAA change is always required. Obtain the actual certificate record set and its exact owners from Support; do not invent a CAA value or loosen broader certificate policy. A valid web certificate and a passing mail signature are separate checks.

The overview warns that the CNAME route does not support Google Postmaster Tools or Yahoo Sender Hub and can expose the vendor target in some mailbox interfaces. Consider those limitations before choosing it. A displayed brand or target label is not an SPF or DKIM result.

3. Select the correct Sender Domain for the mailing

After DNS provisioning and any required Support acceptance, configure the sending identity in iPost. The documented path is the icon beside your name → gear icon for General Settings → Delivery Management → Sender Domains.

Use Add New Domain for the intended configuration. The manager accepts a subdomain delegated to iPost's nameservers; CNAME configurations require Support to provide the associated iPost domain. Enter the recognizable configuration name, correct (Sub) Domain, From Name and approved From local part. Confirm the complete From address produced by the form, because its domain is populated from the selected subdomain.

Set the reply-forwarding address to a real mailbox controlled by your team and verify the sender postal address. Leave the IP selection at the account configuration unless a specific sending-IP choice has been agreed. Then select the saved entry from Email Configuration → Sender Domain for the actual mailing. Sender Domain manager

Keep these as three separate checks:

1. DNS/provider readiness: iPost recognizes and accepts the provisioned domain and records.
2. Identity configuration: the intended Sender Domain exists with the correct From and reply handling.
3. Mailing selection: the specific send uses that configuration, not an old default.

Do not invent a self-service “Verify” button or assume that adding an entry activates every campaign. If the workflow would change your approved visible From address, stop and agree the identity configuration with iPost rather than quietly substituting a different sender to obtain a pass.

4. Understand the envelope and DMARC policy scope

iPost documents a tagged SMTP envelope sender at the delegated subdomain for bounce processing. The visible From can optionally use the same subdomain for its in-bound message filter, but that is not mandatory. Tracking-link branding is a third identity and does not establish mail alignment. iPost envelope and reply handling

For an illustrative author address offers@example.com and MAIL FROM at news.example.com, the two domains can align in relaxed SPF mode when they share the same Organizational Domain. They do not meet strict aspf=s equality. If both identities are exactly news.example.com, exact alignment is possible, subject to a genuine SPF pass. For DKIM, compare the actual passing d= against the author domain under adkim, rather than inferring it from the chosen domain's label. DMARC alignment rules

Do not add a generic iPost include to the parent SPF merely because the visible From uses the parent domain. SPF evaluates the actual envelope domain, and SPF policies do not inherit from parent to child. If Support legitimately issues an SPF policy for a separate owner, keep one v=spf1 record there, preserve other authorized senders and the chosen final qualifier, and evaluate the complete 10 DNS-query-causing-term budget, including nested includes and redirects. a, mx, ptr and exists also consume that budget; ip4, ip6 and all do not. SPF lookup limits

Keep DMARC enforcement and reporting deliberate

Inspect the policy that applies to the actual visible From domain, not only the delegated child. For From at example.com, an iPost-managed policy at _dmarc.news.example.com is not the author-domain policy. For From at news.example.com, a direct child policy may override inherited parent protection. Agree iPost-managed child policy, alignment requirements and report recipients with the organization's domain-security owner.

Preserve existing direct and inherited DMARC policies. Do not replace enforcement with p=none, add a duplicate policy or publish a child exception just to complete onboarding. Under the NS route, have iPost manage the child policy through the agreed process; a TXT record added beneath the delegation in the parent zone is not a reliable substitute.

Only if no direct or inherited policy applies, and the owner approves an initial non-enforcing policy, this is a minimal first record for the example author domain:

_dmarc.example.com. IN TXT "v=DMARC1; p=none"

In an editor that appends the example.com zone suffix, enter _dmarc for the full owner _dmarc.example.com. For a child author domain, the full owner _dmarc.news.example.com maps to _dmarc.news in the parent example.com zone when that parent remains authoritative, or _dmarc in a separately authoritative news.example.com zone. If the editor expects a full name, use the complete owner instead. Under iPost NS delegation, the child policy is provider-managed: request the approved change through iPost, never by adding a record in the parent zone below the delegation cut. All mappings remain subject to the no-existing-direct-or-inherited-policy guard above.

This example requests no reports. Add rua only for an approved destination; where its organizational domain differs from that of the policy, the report receiver must provide the required DNS authorization. Review report access, retention and privacy, because aggregate reports contain source-IP and domain information. Do not copy an arbitrary reporting mailbox or change existing recipients without approval. DMARC discovery and policy, External report authorization

5. Verify DNS without confusing it with sending success

Use your actual names and the issued selector. These example commands have not been run against a customer domain:

dig example.com NS
dig news.example.com NS
dig news.example.com CNAME
dig news.example.com TXT
dig SELECTOR._domainkey.news.example.com TXT
dig _dmarc.news.example.com TXT
dig _dmarc.example.com TXT

For the NS branch, confirm the parent referral names both iPost nameservers and that the child authority answers consistently. Query the actual DKIM owner supplied by iPost or shown in the message; do not assume the template selector. Confirm the managed SPF, key and intended DMARC policy in the child zone. A delegation entry with no working child authority is not completion.

For the CNAME branch, confirm a literal alias to the exact issued target. Follow the alias for its SPF TXT result and inspect the separately published DKIM owner. Check for wrong-zone publication, duplicated suffixes, conflicting data and flattening. Confirm certificate-validation records separately and obtain Support's final acceptance.

Retain full answer status, TTLs, authority and timestamps. Compare authoritative answers with a recursive resolver after allowing for caching. A timeout or SERVFAIL is not proof a record is absent. A public key resolving successfully does not prove that iPost is applying the corresponding signature to your mailing.

6. Verify a fresh delivered iPost message

With sending approval, use the actual campaign configuration and intended From to send a controlled message to a mailbox you control or trust. Check direct delivery first, then separately examine any forwarding or gateway route that matters. Preserve the message ID, UTC timestamp, raw headers and relevant receiver trace with appropriate access controls.

Trust only Authentication-Results inserted by receiving infrastructure you control or trust. It must remove or distinguish untrusted upstream fields. An attacker can forge a convincing Authentication-Results header, including its authserv-id; matching that string alone does not prove origin. If the trust boundary is unclear, use an independent trusted mailbox or receiver trace. Receiver trust requirements

Record and compare:

A generic DMARC pass could come from SPF while the new DKIM signature is still broken. Do not accept this branded-DKIM setup until its intended signature also passes and aligns. Conversely, aligned DKIM can satisfy DMARC while SPF fails, but an SPF fail, softfail, temperror or permerror still needs diagnosis. If an account uses an unrelated provider envelope that passes SPF, record it as unaligned rather than calling SPF broken merely for lacking alignment. Escalate unexpected envelope behavior to iPost with evidence.

Authentication and inbox placement are separate outcomes. For Microsoft 365 recipients, EmailAuth's inbound DMARC handling guide explains why the receiver's delivery decision can differ from the authentication verdict without changing the sender's DNS result.

Troubleshooting iPost setup