Agnitas SPF, DKIM and DMARC setup, step by step

For AGNITAS-managed E-Marketing Manager, register the sender domain in Domains, obtain the account’s SPF details and Support-issued public DKIM key, publish the approved records, and have AGNITAS confirm that branded signing is enabled. The documented standard DKIM selector is agn, using a 2048-bit key. A default AGNITAS signature is not proof that your own From domain is authenticated. AGNITAS DKIM manual.

This guide covers the commercial hosted EMM route managed with AGNITAS Support. It does not install or administer self-hosted OpenEMM, configure an independent SMTP service, or change your organization’s inbound mail routing. The exact SPF value, public key and environment details must come from your account, not another customer’s record.

This is a documentary setup guide; no customer account, DNS zone or delivered message was tested.*

On this page: Prepare the right domain · Obtain the account records · Publish SPF safely · Publish the public DKIM key · Confirm signing and sender selection · Preserve DMARC protection · Verify the actual mailing · Troubleshoot and hand over · Frequently asked questions

Prepare the right domain

Identify the EMM account, intended mailing, visible From address, sender domain, authoritative DNS provider and responsible administrator. Access to the domain registrar alone does not prove that its DNS editor controls the active zone. Use an authorized EMM operator who can manage the relevant domain; do not broaden permissions merely to follow a tutorial.

If employee mail uses Microsoft 365 while campaigns use EMM, these are different sending paths. Preserve the employee-mail authorization and configure its signing separately using the Microsoft 365 SPF and DKIM guide. An Outlook test does not validate an EMM campaign.

Export the existing records and note their owners, values and TTLs. Include existing SPF, DKIM selectors, DMARC and any delegated _domainkey namespace. Confirm whether the domain is shared by other EMM accounts or services. Do not delete a live selector, existing domain registration or nameserver delegation to obtain a clean-looking setup screen.

For an existing working domain, open its saved configuration first. Record the current signing arrangement and coordinate any replacement with Support. A key rotation can affect queued mail and other accounts; a different tutorial screenshot is not a reason to replace a working key.

Obtain the account records

The current EMM manual documents this sequence:

1. Open Domains and inspect the existing domain list.
2. For a genuinely new registration, choose New.
3. Enter the complete intended domain, such as news.example.com, in Name. Description is optional.
4. Select Save. The domain detail view exposes SPF entry, DKIM key and MX entry fields.
5. Retrieve the account’s Technical Setup document from News → Documents and resolve the exact record owners, types and environment with AGNITAS Support before publication.

These are documented account issuance channels. The private Technical Setup document was not accessed for this guide, so no universal SPF include or MX target is supplied here. Create and manage sender domains and addresses.

Ask Support to confirm the exact sender domain, full DKIM owner, complete public TXT value, intended signing domain, selector and post-publication activation handoff. AGNITAS documents creating and depositing the keys for its customers. Use that managed route; do not generate a private key in an online checker or put a private key in DNS, email or a support screenshot. If an organization has a separate existing-key import requirement, handle it through its approved secure process rather than treating this guide as authorization to transmit a secret. AGNITAS key management.

Separate authentication from inbound routing. The appearance of an MX field does not authorize replacing the organization’s mailbox MX records. Compare any proposed MX, forwarding address or response-processing destination with the approved routing plan. If EMM’s requirements conflict with existing mail service, stop and resolve the intended domain or subdomain arrangement with the administrators and Support. Do not skip a documented prerequisite and declare completion, or silently accept an inbound-mail move.

Publish SPF safely

Use the exact SPF requirement from the EMM account and Technical Setup document. First establish which DNS owner the instruction concerns and which envelope domain the actual EMM route uses. SPF evaluates the SMTP MAIL FROM identity, or HELO in the relevant SPF cases, not automatically the visible From address. A domain shown in a marketing profile is not sufficient evidence of the evaluated envelope identity. SPF identities.

At an owner requiring an SPF policy, publish one v=spf1 TXT record. If a policy already exists, incorporate only the approved EMM authorization into that single policy while preserving other legitimate senders and the established qualifier. Do not add a second complete SPF record or replace a combined policy with an EMM-only example. Unrelated TXT verification records should remain. SPF publication rules.

Count the evaluated DNS-dependent mechanisms and modifiers, including nested processing, against SPF’s ten-term limit. This is not a limit of ten visible include strings. Review include, a, mx, exists, ptr and redirect behavior as applicable; an existing all mechanism causes redirect to be ignored. Do not casually append a new authorization after a terminal all. Preserve the intended policy semantics rather than changing ~all to -all as a shortcut. An SPF result does not dictate every receiver’s delivery decision. Lookup limits, redirect behavior.

Map the issued full owner to the actual zone. For news.example.com in the example.com zone, a relative-name editor usually needs news; if news.example.com is separately delegated, its apex uses that editor’s documented root convention, often @ or an empty field. Other panels expect the full name. Inspect the saved full owner to prevent duplicated suffixes. SPF is not inherited automatically from a parent domain.

Publish the public DKIM key

AGNITAS documents agn._domainkey as its standard relative selector owner and 2048 bits as its standard key length. Support can accommodate an agreed selector or key requirement; obtain the actual issued packet rather than assuming every account must use the default. Do not select a shorter key merely to work around a DNS form. Current DKIM procedure.

Publish the complete public TXT value supplied for this account and domain. Retain all required tags and the entire public key. A screenshot fragment, bare selector or private signing key is not the record value. DNS panels can display long TXT data in multiple quoted character strings; preserve their complete concatenated value as one record rather than creating separate records containing key fragments. DKIM DNS key publication.

For the documented standard selector, these owner examples illustrate DNS-name handling, not tenant keys:

• Signing domain example.com, authoritative zone example.com: full owner agn._domainkey.example.com; relative owner agn._domainkey.
• Signing domain news.example.com, authoritative zone example.com: full owner agn._domainkey.news.example.com; relative owner agn._domainkey.news.
• The same signing domain in a separately delegated news.example.com zone: relative owner agn._domainkey.
• If _domainkey.news.example.com itself is delegated, publish through that namespace’s actual authority; the relative owner there is agn.

Substitute the Support-issued selector when it differs. Do not remove an existing delegation to force a record into the parent zone. At an occupied selector, identify the owner and coordinate the change; do not add a second competing key. A CNAME at that exact owner cannot coexist with the required TXT record. This documented managed route uses a public TXT key, not a guessed CNAME alias or proxy setting.

The provider’s directory-linked DKIM article explicitly describes publishing the public key in customer DNS before AGNITAS enables the signature. That older article was published in 2014 and modified in 2021; its handoff is consistent with the current manual’s Support-managed key procedure. Obtain explicit current activation confirmation for your account after publication rather than treating the older article’s broad whitelisting or security claims as a guarantee. AGNITAS publication and activation handoff.

Confirm signing and sender selection

Keep DNS publication, EMM validation, signing activation and sender selection as separate checks. A key visible in the account does not prove the outgoing service is using it.

The current manual says an invalid DKIM entry can disable New address, while a missing entry produces warnings. It also describes an option for externally managed DKIM. Do not turn off the warning feature simply to bypass an invalid managed configuration. Confirm which management model actually applies and correct its record or handoff first. Domain validation behavior.

After the domain is ready, use New address if the intended sender does not already exist. Enter only the part before @ in Name; EMM adds the selected domain. Saved addresses appear in the Sender email dropdown when creating a mailing. Choose the intended address for the actual mailing being validated. Existing addresses should be checked, not duplicated. EMM sender-address workflow.

The same address dialog exposes Forward address, Filter address and response-processing options. Autoresponder configuration is also described in the manual. These can change reply handling or send additional messages; leave them unchanged unless their exact destinations and behavior are separately approved. Do not copy a blurred or sample forwarding address from a source image.

AGNITAS says mail uses an AGNITAS signature until a customer’s own key is entered. That is an important diagnostic distinction, not a successful branded-DKIM acceptance criterion. Confirm Support has enabled the intended customer-domain signer, then verify a newly delivered mailing.

Preserve DMARC protection

DMARC passes when SPF or DKIM both passes and aligns with the visible From domain. Relaxed alignment permits the same Organizational Domain; strict alignment requires identical domains. Check the effective adkim and aspf settings. A child envelope domain does not satisfy strict SPF alignment with its parent, and a valid AGNITAS-owned signature alone does not prove branded DKIM alignment. Do not assume a universal EMM Return-Path. DMARC identifier alignment.

Inspect the direct policy and any applicable inherited policy before editing. Missing TXT at _dmarc.news.example.com does not by itself mean the subdomain is unprotected. Preserve established enforcement and authorized report destinations; adding a child monitoring policy can weaken inherited protection. DMARC policy discovery.

Only when no applicable policy exists, the owner approves monitoring and an appropriate reporting plan is in place, this is an illustrative first-policy template:

Full owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:APPROVED-REPORT-ADDRESS

Replace the domain and the complete report address before publication. In an example.com zone, the relative owner is normally _dmarc; for a From domain news.example.com in that parent zone it is _dmarc.news. Use the DNS host’s actual naming convention and one DMARC policy per owner. Monitoring does not request rejection or quarantine. Never replace an established quarantine or reject policy with this example, and do not use the obsolete pct tag as a new rollout method.

For aggregate reports, compare the Organizational Domain of the destination URI’s host with that of the domain where the DMARC policy was found, which need not be the visible From domain. If those Organizational Domains differ, the report-generating receiver must check DNS authorization; a destination within the same Organizational Domain is excepted. A different hostname alone is not the external-destination test. Arrange the applicable authorization with the reporting operator. This protocol check does not replace the owner’s approval to share sending-activity data with that recipient. Aggregate-report authorization, RFC 9990 section 4.

Verify the actual mailing

Use read-only DNS queries first, substituting the real domains and issued selector. The examples below deliberately contain no usable account key or fabricated result:

dig +short TXT example.com
dig +short TXT agn._domainkey.news.example.com
dig +short TXT _dmarc.news.example.com

Query the actual SPF owner, not automatically example.com. Compare the DKIM response with Support’s complete public value and check the correct authoritative namespace, then recursive resolvers and caching. Empty output is a reason to investigate authority, names and propagation, not permission to delete unrelated records. An absent child DMARC record still requires policy-discovery checks.

After AGNITAS confirms signing, send an authorized mailing through the intended EMM route to a valid controlled recipient. Select the intended branded From address and record which account and mailing produced the sample. No campaign or test was sent for this guide.

Inspect the raw message in the receiving system. Use Authentication-Results produced inside that receiver’s known processing boundary and its documented treatment of externally supplied result headers. Ask the receiver administrator when that boundary is unclear. A familiar authserv-id string or a header’s position alone is not proof of trust; disregard attacker-supplied results. Authentication-Results security.

Record the unchanged visible From domain, actual envelope identity, SPF result, intended DKIM signature’s d= and s=, DKIM result, and DMARC result. Acceptance for this new branded DKIM setup requires:

• The intended EMM customer-domain signature passes, using the agreed selector and signing domain.
• That signing domain aligns with the intended visible From under the effective adkim policy.
• The trusted receiver reports dmarc=pass for that unchanged From.

A generic DMARC pass through SPF alone does not prove DKIM works. Neither an unrelated passing signature nor rewriting From to an AGNITAS-owned domain satisfies this branded setup test. Separately assess SPF: investigate fail, softfail, neutral, none, temperror and permerror, even when aligned DKIM supplies DMARC pass. Authentication is not an inbox-placement guarantee.

Troubleshoot and hand over

New address is disabled or DKIM warnings persist. Compare the full selector owner and complete public TXT key with the account packet. Check authoritative DNS and the domain selected in EMM. Do not disable the warning merely to proceed.

DNS is correct but only the AGNITAS signature appears. Confirm Support’s post-publication activation, the actual account, mailing route and selected sender. Provide sanitized authentication evidence through the approved support channel rather than creating a replacement key independently.

SPF fails or returns an error. Inspect the actual envelope owner and sending IP. A fail or softfail concerns authorization outcomes; temperror indicates a transient evaluation problem, while permerror calls for checking invalid policy, duplicate SPF records or lookup limits. Adding another apex include does not repair every case.

DKIM passes but DMARC fails. Compare the intended signing domain with the unchanged From under the effective policy. Verify which signature passed and examine SPF alignment separately. Do not weaken DMARC to conceal an identity mismatch.

Replies or other mail routes break. Compare the DNS and routing baseline, especially any separately approved MX or forwarding changes. Do not restore an entire zone or delete shared selectors as a speculative repair. Roll back only the authorized affected change after checking dependencies and queued-message implications with the responsible operators.

Keep the final account/domain inventory, Support-issued public packet, DNS before-and-after values, activation confirmation, selected sender and dated receiver evidence. Mark untested routes explicitly. Revalidate after signer rotation, account migration or a changed sending path, and review aggregate reports across legitimate senders before any enforcement decision.