How to set up DMARC/DKIM/SPF for IceWarp
Published 27 Jul 2026
Updated 27 Jul 2026
11 min read
Summarize with
IceWarp authentication needs one SPF TXT record that authorizes its outbound path, a 2048-bit DKIM key generated inside IceWarp, and one DMARC TXT record at _dmarc. I set them up in that order, then confirm that the SPF envelope domain or DKIM signing domain matches the visible From domain. DMARC passes when either matching path passes.
Cloud and self-hosted IceWarp use different DNS targets. The self-hosted DNS guide covers a server hostname and public IP, while the IceWarp Cloud guide uses the tenant hostname under onice.io. Keep every existing sender in the same SPF record before publishing a change.
Configuration outcome
- SPF: IceWarp's connecting IP is authorized by the envelope domain.
- DKIM: IceWarp signs with a 2048-bit key and the d= domain matches From.
- DMARC: Reports arrive first under p=none, followed by controlled enforcement.
- Validation: A live message shows dmarc=pass in Authentication-Results.
Add your domain
IceWarp does not use a separate ownership-challenge screen for a normal domain addition. I add the domain in WebAdmin or Remote Console, publish the required DNS, and verify it by resolving the records and sending mail.
- Sign in: Open IceWarp WebAdmin as a server administrator.
- Create: Select the plus menu, choose New domain, enter your exact From domain, and save.
- Identify: For Cloud, copy the tenant hostname ending in onice.io. For self-hosted, record the mail hostname and static outbound IP.
- Publish: Add the A or CNAME, MX and authentication TXT records at your authoritative DNS provider.
- Confirm: Resolve the domain's MX and mail hostname, then create a mailbox and complete an external send-and-receive test.
IceWarp WebAdmin New domain form
Do not replace working MX records until mailboxes exist and inbound delivery has been tested. Authentication records affect outbound identity, while MX records change where inbound mail is delivered.
IceWarp Cloud
- Target: Use the assigned tenant.onice.io hostname.
- SPF: Authorize the tenant hostname with one include mechanism.
- rDNS: IceWarp provisions PTR for the cloud sending path.
- DKIM: Generate the domain key in WebAdmin.
Self-hosted IceWarp
- Target: Point a mail hostname at the static server IP.
- SPF: Authorize the actual outbound IP or matching MX host.
- rDNS: Ask the IP owner to set PTR to the mail hostname.
- DKIM: Enable DKIM globally, then activate it per domain.
Set up SPF
IceWarp supports return-path alignment, so SPF can satisfy DMARC when the envelope sender uses your domain and the connecting server is authorized. Publish SPF at the domain used by smtp.mailfrom, which is usually the visible From domain for direct IceWarp sending.
- Query first: Check the root domain for an existing TXT value beginning with v=spf1.
- Choose Cloud: Add an include for the exact tenant.onice.io hostname assigned to the account.
- Choose self-hosted: Use mx only when the listed MX host sends outbound mail, or authorize the static outbound IP directly.
- Merge senders: Add IceWarp to the existing SPF record. Never publish a second SPF record at the same name.
- Control lookups: Keep the evaluated SPF tree at ten DNS-triggering lookups or fewer.
- Start soft: Use ~all during discovery, then move to -all after every legitimate sender has been tested.
IceWarp Cloud SPF exampleDNS
Host: @ Type: TXT TTL: 3600 Value: v=spf1 include:tenant.onice.io ~all
Replace tenant.onice.io with the hostname shown in your IceWarp Cloud account. Do not copy the placeholder. If an SPF record already exists, insert the include before its final all mechanism.
Self-hosted SPF examplesDNS
Host: @ Type: TXT TTL: 3600 Value: v=spf1 mx ~all Alternative with a static outbound IP: Value: v=spf1 ip4:192.0.2.10 ~all
The mx mechanism is correct only when the outbound connection comes from an IP resolved through your MX hosts. The ip4 mechanism is clearer when IceWarp sends through a dedicated static IPv4 address.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
Run the checker after the TXT record resolves publicly. A valid syntax result is only the first check. Send a real message and confirm that the evaluated envelope domain is your domain and spf=pass appears in Authentication-Results.
Some secondary sending services do not let you set a custom return path. Expect SPF alignment errors for those messages. That is acceptable for DMARC when an aligned DKIM signature passes, although keeping SPF technically valid for the service still matters.
Do not add a second SPF record
Two v=spf1 records at one hostname produce a permanent SPF error. Edit the existing record, preserve every authorized sender, and keep one final all mechanism.
Set up DKIM
DKIM is the most dependable DMARC path for forwarded mail because the signature can survive forwarding when the message body and signed headers remain unchanged. I use a unique selector such as iwdkim and generate a 2048-bit key.
IceWarp WebAdmin DKIM key generation panel
- Enable globally: In Remote Console, open Domains & Accounts, Global Settings, Domains, then enable DKIM.
- Open domain: Select the sending domain under Management and open its DKIM tab. In WebAdmin, select the domain, Properties, then DKIM.
- Activate: Turn on DKIM for the domain and enter a selector that is not already in use.
- Generate: Choose 2048 bits, generate the private key, and save. Keep the private key inside IceWarp.
- Copy public data: Retrieve selector data, then copy the hostname and complete public TXT value.
- Publish: Create the TXT record at selector._domainkey and wait for its TTL.
- Test signing: Send a new external message and verify dkim=pass with d= set to your From domain.
IceWarp DKIM DNS templateDNS
Host: iwdkim._domainkey Type: TXT TTL: 3600 Value: v=DKIM1; k=rsa; p=<public-key-from-IceWarp>
Copy IceWarp's complete public key without added spaces. Some DNS interfaces split a long TXT value into quoted chunks automatically. That is valid when DNS returns one concatenated value.
The signing domain must match
A valid signature with d=another-domain.example does not provide DMARC alignment for From: user@example.com. Configure IceWarp to sign with d=example.com or its organizational-domain match.
Set up DMARC
Publish one DMARC TXT record at _dmarc and start with p=none while you collect reports. Use the exact record v=DMARC1; p=none; rua=mailto:dmarc@example.com, replacing only the report mailbox. If the domain already uses p=quarantine or p=reject successfully, keep that stronger policy.
DMARC policy is published in your authoritative DNS, not configured in IceWarp WebAdmin. IceWarp's job is to produce the matching SPF or DKIM result that the receiver evaluates against this policy.
The DMARC record generator creates the TXT value when you need extra report addresses, a subdomain policy or explicit alignment modes. Keep the first deployment simple unless those controls solve a defined requirement.
Initial DMARC recordDNS
Host: _dmarc Type: TXT TTL: 3600 Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com
- Create mailbox: Make sure the rua address accepts aggregate XML reports or points to a reporting platform.
- Publish once: Add one TXT value at _dmarc. Multiple DMARC records make processing fail.
- Keep relaxed: Use the default relaxed matching during discovery unless strict subdomain matching is required.
- Collect reports: Wait for representative weekday, weekend and automated traffic before enforcing.
- Read results: Group source IPs, identify owners, and fix legitimate streams that fail both matching paths.
A p=none policy does not block impersonation. It gives the evidence needed to separate IceWarp mail, other approved senders and unauthorized use before enforcement.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Check the record after publication and confirm that the parser sees one DMARC version tag, one policy and the intended aggregate destination. A syntactically valid record still needs live-message testing.
The receiving system evaluates the visible From domain. SPF contributes only when its authenticated envelope domain matches From, while DKIM contributes only when the signature's d= domain matches From.
Verify and troubleshoot
DNS lookup tools confirm publication, but only a delivered message proves that IceWarp used the expected envelope sender and DKIM key. I send a fresh message after each change because stored messages and retries can carry old results.
- Send externally: Use an IceWarp mailbox on the configured domain and send a plain message to the tester.
- Inspect headers: Find Authentication-Results and note spf, smtp.mailfrom, dkim, header.d and dmarc.
- Compare domains: Match smtp.mailfrom or header.d to the visible header.from domain.
- Check identity: Confirm the connecting IP, HELO hostname and PTR belong to the intended IceWarp path.
- Retest changes: Wait at least the published TTL, send a new message, and compare the new result.
Use the email tester for a complete diagnosis of the received message. It exposes the actual sending path, DNS authentication outcomes and domain matching in one report.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
If SPF passes but DMARC fails, compare smtp.mailfrom with header.from. If DKIM passes but DMARC fails, compare header.d with header.from. A pass for a different domain authenticates that domain, not the visible sender.
If both mechanisms fail, work backward through DNS, the IceWarp domain configuration and the delivered headers. The compact matrix below identifies the next check.
|
|
|
|---|---|---|
SPF permerror | Duplicate or lookup excess | One SPF record |
SPF misaligned | Different envelope domain | smtp.mailfrom |
DKIM fail | Wrong key or changed body | Selector and logs |
DKIM misaligned | Signing domain differs | header.d |
DMARC fail | No matching pass | Both paths |
Use live headers, not DNS alone, to isolate the failure.
Common IceWarp DKIM failure
When the TXT record resolves but messages have no DKIM-Signature header, check both controls: DKIM must be enabled globally and activated for the sending domain. Generate and save the key after both controls are on.
Get alerted when it breaks
A one-time test cannot catch an expired key, an SPF edit that exceeds lookup limits, a new unauthorized source or a sudden authentication drop. Continuous aggregate-report processing turns those changes into operational alerts.
Suped is our product and the best overall DMARC platform for most teams that need this workflow. Its DMARC monitoring converts XML reports into source-level results, detects issues automatically, sends real-time alerts and gives exact steps to fix the affected sender.
- Route reports: Use Suped's aggregate-report address in the DMARC rua tag.
- Verify sources: Mark the known IceWarp sending IPs and investigate every new source.
- Set alerts: Notify owners when pass rates fall or an unverified source appears.
- Review issues: Follow the sender-specific fix steps, then confirm recovery in later reports.
- Unify checks: Track DMARC, SPF, DKIM, blocklist and deliverability signals together.
- Scale access: Use the multi-tenant dashboard when an MSP or agency manages many domains.
Mailbox-only reports
- Format: XML attachments need parsing and grouping.
- Detection: Problems wait for a manual review.
- Ownership: Source IPs need manual attribution.
- History: Trends require separate storage and analysis.
Suped monitoring
- Format: Reports become readable sender records.
- Detection: Alerts identify a change near its first report.
- Ownership: Verified and unknown sources stay separate.
- History: Pass rates and volume remain available by source.
Alert on change, not only failure
A new source can pass SPF for an unrelated envelope domain yet still fail DMARC. Alert on unverified sources, DMARC pass-rate drops and sudden volume shifts so the signal arrives before policy enforcement affects legitimate mail.
Secure your domain with p=reject
Move to p=reject only after every legitimate source has a stable matching pass and unknown traffic has been investigated. I stage enforcement by traffic evidence, not by a fixed calendar date.
- Build inventory: Include IceWarp, business applications, support systems, devices and every subdomain that sends.
- Require matching: Give each legitimate stream aligned DKIM wherever available, then retain SPF as a second path.
- Measure coverage: Review representative automated, low-volume and seasonal mail before changing policy.
- Quarantine first: Apply limited quarantine, inspect impact, then move to full quarantine.
- Reject fully: Publish p=reject after legitimate failures are cleared and alerting is active.
- Protect subdomains: Add sp=reject only after auditing delegated and inactive subdomains.
- Keep monitoring: Treat new sources and pass-rate drops as changes requiring an owner.
DMARC enforcement stages
Advance only when legitimate traffic has a stable matching authentication path.
Observe
p=none
Inventory all sending sources without receiver enforcement.
Sample quarantine
p=quarantine; pct=25
Apply quarantine to part of failing traffic and inspect impact.
Full quarantine
p=quarantine
Quarantine all failing traffic after legitimate failures are cleared.
Reject
p=reject
Reject failing mail while continuous monitoring remains active.
Staged DMARC policy examplesDNS
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Suped's Hosted DMARC is the practical control point for this rollout. It manages policy staging without repeated manual TXT edits, while Suped's issue detection and real-time alerts show which IceWarp or third-party stream blocks the next step.
Keep the reporting address at p=reject. Enforcement stops unauthenticated impersonation at receivers that honor DMARC, but reports remain necessary because legitimate systems change and unauthorized sources keep appearing.
Do not use pct as a permanent exception
The pct tag is a staging control and receiver handling can vary. Fix each legitimate sender, move to full enforcement, and use a separate subdomain when a stream needs a temporary policy boundary.
IceWarp authentication FAQ
These are the checks that usually come up after the first IceWarp test message.
