Antagonist Hosting SPF, DKIM and DMARC setup, step by step

Antagonist's DirectAdmin-hosted mailboxes use the SPF include include:_spf.webhostingserver.nl and provider-managed DKIM. With Antagonist authoritative DNS, its default zone contains three DKIM CNAMEs: whs1._domainkey, whs2._domainkey and whs3._domainkey. Their targets are specific to your account/domain. Preserve those generated records, check the single SPF policy, and verify a new message has a passing aligned Antagonist DKIM signature plus DMARC pass. Current DirectAdmin DNS guide · Antagonist DKIM

This procedure is for Antagonist-operated mailboxes on its DirectAdmin hosting/email platform with Antagonist authoritative nameservers. It does not establish a general external-DNS signing workflow. It also excludes WP.one, self-managed servers and mail sent through Microsoft 365, Google Workspace or another external SMTP service.

On this page: Check the scope · SPF · DKIM · DNS names and conflicts · DMARC · Verify · Troubleshooting · FAQ

Check the scope

Start with an existing hosting or email plan that includes Antagonist mailboxes. You need access to the correct domain in DirectAdmin, permission to manage its DNS, and a mailbox that sends through Antagonist's mailserver. A domain-only registration is not evidence of a configured sending service.

1. Confirm the nameservers that actually serve your domain. If another provider is authoritative, editing DNS in DirectAdmin will not change public answers.
2. Identify the outgoing mailserver used by each mail client. Receiving mail at Antagonist does not prove a desktop client or application sends through it.
3. Inventory other senders and save the existing SPF policy, all DKIM selectors, DMARC policy and any delegated DNS namespaces.
4. In DirectAdmin, choose the domain using the globe selector at the top right if the account contains several domains. Open Accountbeheer → DNS Beheer (Account Management → DNS Management).

The current DirectAdmin guide describes automatic defaults, name syntax, the editor and its nameserver boundary. Alias domains or pointers have their own view under Accountbeheer → Domein Pointers → Weergave in the DNS column. Inspect the domain you actually send as, rather than assuming an alias automatically inherits every authentication record.

If you use external DNS: do not infer that copying the CNAMEs enables signing for every Antagonist product. Older official support material explicitly restricted that scenario, while newer material includes specific migration instructions. This guide does not resolve those product-specific conditions. Obtain current instructions for your exact hosting product and outgoing route before changing DNS authority or relying on copied records. Historical external-DNS limitation · Separate WP.one migration procedure

SPF

The documented default

The current Antagonist DNS guide shows this default SPF TXT policy:

Owner: example.com.
Type: TXT
Value: v=spf1 include:_spf.webhostingserver.nl ~all

example.com is illustrative. Use your own domain and the exact include _spf.webhostingserver.nl. Do not substitute _spf.antagonist.nl, guess a branded include, or copy historical IP ranges from an old example or comment. Antagonist maintains the infrastructure behind its documented include. SPF explanation and editing

The trailing dot belongs to the fully qualified DNS owner, not to the SPF include inside the TXT string. The quoted value sometimes shown in a zone listing is DNS presentation syntax; use the editor's TXT value field without adding literal extra quote characters unless its format requires them.

Preserve a multi-sender policy

First search the selected domain's TXT records for a value beginning v=spf1:

• If the correct policy already exists, verify it rather than adding another.
• If it authorizes other legitimate services, retain them and merge Antagonist's required include before the terminal all. Preserve the chosen qualifier unless deliberately changing policy.
• If no SPF policy exists at the required owner, add one TXT record using the intended sender inventory. The default above is appropriate only when it expresses your actual sending arrangement.

In DirectAdmin, use the existing record's edit/pencil control. For a new record, choose Record toevoegen, record type TXT, the fully qualified domain name with its terminating dot, and the SPF TXT subtype where offered. Enter the planned value and use Toevoegen. Do not reset the entire DNS zone to repair one policy.

Only one SPF policy TXT record may exist at a given owner. Other TXT records, such as service verification tokens, may coexist and should remain intact. A policy with redirect= needs deliberate reconciliation; introducing an all mechanism can make its redirect ineffective. Validate the full policy, not just the added token. SPF record selection and evaluation

Check the envelope identity and lookup budget

SPF checks the connecting IP against the domain in the SMTP envelope sender, normally shown as smtp.mailfrom in receiver results. It does not directly authenticate the visible From address. Look at a fresh Antagonist message to establish the actual domain; the documentation does not provide a universal mailbox Return-Path formula or strict-alignment guarantee.

An SPF record at example.com does not automatically apply to mail.example.com. If a different service uses a provider-owned envelope domain, adding that service to an unrelated customer apex policy does not change the evaluated identity.

SPF permits at most ten DNS-query-causing terms during evaluation, including nested includes and terms such as a, mx, exists and redirect. It is not a ten-vendor allowance. Use a complete lookup analysis after a merge, and do not replace the maintained include with static IPs simply to shorten the count. The EmailAuth SPF guide explains this distinction.

Antagonist's default ~all produces softfail for otherwise unmatched senders. It does not guarantee acceptance. Similarly, -all signals SPF fail rather than commanding every receiver to reject. Do not relax a policy merely because a forwarded message failed SPF; first identify the route and alignment result.

DKIM

Preserve the three provider-managed CNAMEs

Antagonist documents automatic DKIM signing for its webhosting platform and says customers using its mailserver need not create signing keys. Its current DNS defaults name three selectors. In the selected domain's DNS Beheer, find all three:

The documented target pattern is:

ACCOUNT_SPECIFIC_TOKEN.whs1.dkim.webhostingserver.nl.
ACCOUNT_SPECIFIC_TOKEN.whs2.dkim.webhostingserver.nl.
ACCOUNT_SPECIFIC_TOKEN.whs3.dkim.webhostingserver.nl.

These are patterns, not values to publish. Obtain each complete target from your existing DirectAdmin records or a domain-specific correction supplied by Antagonist. Do not use the example token from the help page, manufacture a token from your domain, or assume another account's target works.

Keep all three selectors. Seeing whs1 on today's test message is not a reason to remove whs2 and whs3; the provider may use them as its signing configuration changes. Do not replace the CNAMEs with TXT copies of the keys currently returned by their targets. That would detach your records from provider-managed key changes.

There is no documented customer private-key upload or manual DKIM-generation step for this scoped managed-mail workflow. If the defaults are absent, request the correct domain-specific records and verify the service's signing status rather than inventing a replacement key. Antagonist signing behavior · Current selector defaults

DNS names and conflicts

In the example.com zone, whs1._domainkey expands to whs1._domainkey.example.com. A full name in DirectAdmin needs its terminating dot: whs1._domainkey.example.com.. Preserve the terminating dot on each full CNAME target as shown by the provider. Without it, an editor that interprets names relatively may append your domain to the target.

For a separately configured sending domain mail.example.com, the full selector owner would be whs1._domainkey.mail.example.com. Its relative name is whs1._domainkey.mail in an example.com parent zone, but whs1._domainkey in a separately authoritative mail.example.com zone. These are name-mapping examples, not confirmation that a new sending subdomain is already configured on your account.

If _domainkey.example.com has been delegated with NS records, selectors beneath it are answered by that child zone. There the relative name is whs1, not whs1._domainkey. Preserve the delegation and check all dependent senders with the DNS administrator before changing it. Creating a hidden parent-zone record will not repair an answer served from the delegated zone.

A CNAME owner cannot also hold a conflicting TXT, A or AAAA record. Another service's existing selector is a dependency to investigate, not a record to delete blindly. Different selectors can coexist for different senders.

These authentication CNAMEs must remain publicly resolvable aliases, not HTTP redirects. Antagonist's normal managed defaults should not require proxy or flattening changes. If additional DNS tooling is involved, confirm the records stay DNS-only and literal CNAMEs: per-record or zone-wide flattening must not hide them. Do not switch off a shared setting, DNSSEC or other zone protections just to repair one selector, and do not treat this safeguard as an external-DNS setup procedure.

The current DirectAdmin help states its TTL is fixed at one hour. Negative answers have a separate SOA-controlled cache lifetime. Expect cached resolvers to lag after a repair, but first confirm the authoritative answer is correct.

DMARC

Antagonist's current default zone example includes _dmarc with v=DMARC1; p=none. Inspect what your domain actually publishes. Do not add a second record or replace an existing enforcement policy with that default.

Before creating a policy for a subdomain, check whether it already has a direct policy or inherits one from a parent. Preserve the applicable p, subdomain handling, adkim, aspf and report recipients. If no direct or inherited policy applies and you are deliberately starting without enforcement, this is a minimal first record:

Owner: _dmarc.example.com.
Type: TXT
Value: v=DMARC1; p=none

For the example.com zone, the relative name is _dmarc. For mail.example.com, the direct policy's relative name is _dmarc.mail in the parent zone or _dmarc in a separate mail.example.com zone. The example requests no reports and must not be used to override a stronger existing policy. DMARC policy discovery and alignment

For reports, first select an authorized destination and approve its privacy, access and retention arrangements. Aggregate reports reveal sending IPs, domains, counts and authentication activity. A rua destination outside the policy domain's organizational domain needs the report receiver's DNS authorization. Obtain its exact instructions and do not copy an arbitrary example address. Failure reports can expose more message information and are not a default requirement here. External report authorization

Verify

Check the records publicly

Replace the example domain. Query Antagonist's actual authoritative nameserver and at least one recursive resolver, using dig or an equivalent DNS lookup:

dig +short NS example.com
dig +short TXT example.com
dig +short CNAME whs1._domainkey.example.com
dig +short CNAME whs2._domainkey.example.com
dig +short CNAME whs3._domainkey.example.com
dig +short TXT whs1._domainkey.example.com
dig +short TXT _dmarc.example.com

Expect the single intended SPF policy and all three account-specific CNAME targets. Follow each CNAME to confirm its current public DKIM key resolves. The TXT lookup for whs1 illustrates that final resolution; repeat for the other selectors. A missing TXT answer at the alias needs investigation of the CNAME chain, not an extra TXT pasted beside it.

Check a newly delivered mailbox message

Send through the real Antagonist mailbox route, not a different SMTP server using the same From address. Keep the intended visible From address unchanged. Use a receiver you control or trust and inspect raw headers:

1. Record the visible From domain, smtp.mailfrom, and the receiver's SPF result.
2. Locate the intended Antagonist DKIM signature. Record its d= and s= and confirm the receiver reports DKIM pass for that signature.
3. Confirm the signing domain aligns with the visible From under the applicable adkim mode. Relaxed alignment allows the same organizational domain; strict alignment requires identical domains.
4. Confirm DMARC pass at that trusted receiver. A generic DMARC pass caused solely by SPF does not prove Antagonist DKIM is working.

DMARC needs at least one passing aligned authentication path. Nevertheless, investigate actual SPF fail, temperror or permerror even if DKIM passes. Separate authorization errors from a valid but unaligned envelope identity; examine the actual evaluated domain and connecting IP before editing SPF.

An attacker can insert an Authentication-Results field, even with a familiar authserv-id. Trust the field only when your receiving infrastructure establishes its origin and rejects or distinguishes forged incoming fields. If that boundary is unclear, use an independent trusted mailbox or a receiver administrator's trace. Authentication-Results standard

Repeat the test for each client and other production route. Website scripts, forwarding and third-party senders need separate evidence; a successful mailbox test does not certify them all.

Troubleshooting

Keep the exact error text, sending time, sanitized authentication headers and DNS answers for support. Antagonist requests desired DNS records as text rather than screenshots when assisting with changes. Do not include passwords or unnecessary message content.