HENNGE One SPF, DKIM and DMARC setup, step by step

To authenticate mail routed through HENNGE Email DLP, add include:spf.mta.hdems.com to the applicable existing SPF policy, generate a DKIM selector in Tenant Settings → DKIM Setup, publish its public TXT record for every registered sending domain, and activate those domains. Remove the t=y test-mode flag before final acceptance. Then verify that a message delivered after DLP processing has a passing, aligned HENNGE DKIM signature and passes DMARC. SPF setup, DKIM setup

This procedure covers Email DLP within HENNGE One, not every HENNGE product. No tenant configuration, customer DNS lookup or change, or live delivery test was performed for this guide.

On this page

• Check the product, domains and mail route
• Configure SPF without replacing other senders
• Generate and activate Email DLP DKIM
• Add another domain without replacing the selector
• Map DNS names to the authoritative zone
• Preserve DMARC policy and verify alignment
• Validate DNS and the delivered message
• Troubleshoot and recover safely
• Frequently asked questions

Check the product, domains and mail route

HENNGE's current Email DLP setup instructions describe product specifications as of October 2026. They require customer-owned domains already registered with HENNGE One. Confirm your tenant's entitlement, supported connection and administrator access before scheduling the change. An administrator must be able to manage Email DLP settings; the DNS administrator must control each affected zone. DKIM prerequisites, registered-domain management

Prepare this information:

Preserve upstream signing as well as configuring DLP signing. A Microsoft 365 or Google Workspace signature can become invalid when Email DLP changes an attachment into an encrypted ZIP or a Secure Download link. HENNGE recommends signing in Email DLP too. Different selectors allow upstream and DLP public keys to coexist. ARC information can help a receiver interpret earlier authentication, but it is not a substitute for checking the final aligned signature. Email DLP DKIM overview

If you also maintain upstream Microsoft 365 authentication, use the separate Microsoft 365 SPF, DKIM and DMARC guide. Do not replace Microsoft's keys with HENNGE's key.

Configure SPF without replacing other senders

HENNGE's SPF procedure requires authorization before connecting Email DLP and for every custom domain used. Its documented mechanism is:

include:spf.mta.hdems.com

This is a mechanism to merge into an SPF policy, not a complete standalone TXT value. Publish SPF as TXT at the domain evaluated for SMTP MAIL FROM, not automatically at the visible From domain. SPF does not inherit from a parent domain. Reconcile every custom sending domain with the actual envelope identity used by the connection. HENNGE SPF procedure, SPF identity and record rules

For example, if a domain's only existing sender is Microsoft 365 and its approved policy already ends in ~all, the documented combined shape is:

v=spf1 include:spf.protection.outlook.com include:spf.mta.hdems.com ~all

For a Google Workspace-only domain with that same approved failure qualifier:

v=spf1 include:_spf.google.com include:spf.mta.hdems.com ~all

These are conditional examples, not replacement records for a domain with other senders. Read the existing TXT records first. Insert the authorized HENNGE mechanism before the terminal all, preserve other active senders and the existing ~all or -all choice, and leave unrelated TXT records intact. Do not add a second v=spf1 record at the same owner. Multiple quoted strings within one TXT record are not the same as multiple SPF records. HENNGE examples, RFC 7208

Evaluate the complete SPF policy for the sending path, including nested include and redirect dependencies. SPF limits evaluated DNS-dependent terms to ten; a, mx, ptr, exists, include and redirect consume that budget. ip4, ip6 and all do not. This is neither a ten-include allowance nor a count of raw DNS packets. Void DNS lookups have a separate recommended limit of two. Do not flatten the include into a static IP list without a maintained update process. SPF lookup limits

If an existing SPF policy uses redirect=, preserve its intended authorizations and final semantics through a reviewed merge. Any all mechanism causes redirect to be ignored, so appending a canned policy or an all without reviewing that dependency can change which senders are authorized. SPF redirect semantics.

If DLP routes to another outbound mail server

HENNGE's Routing to External Mail Servers feature requires activation through HENNGE Technical Support, or your implementation representative during onboarding. Once active, it routes all mail passing through Email DLP to the designated MTA. Existing DLP customers cannot trial it on only selected live messages: arrange HENNGE's separate test environment and prepare test Microsoft 365/Google Workspace and destination-service environments before production activation. Do not enable routing merely to configure authentication. External-MTA prerequisites and rollout

For a separately approved external-MTA deployment, compare the exact configured destination and test-recipient address with the authorized routing plan before testing or activation. A support-provided setup or connectivity success is not permission to forward all production mail to an unapproved host. Retain the approved processing boundary and verify both DLP and destination logs against that plan. Routing destination and activation sequence.

For that supported route, HENNGE recommends adding include:spf-outbound.mo.hdems.com as well as the default include because the designated next-hop MTA may check SPF on mail arriving from DLP. The final recipient instead evaluates the last connecting sender. Authorize that final MTA under its own supported instructions and verify the resulting envelope identity. Do not add this extra include indiscriminately to ordinary deployments. Any external-MTA test described below belongs in the separately arranged test environment for an existing DLP deployment. Route-specific SPF requirements

Generate and activate Email DLP DKIM

Create the selector and publish the public key

1. Open the Email DLP administration console and select Tenant Settings → DKIM Setup.
2. Choose + Add new selector. HENNGE supports one active selector, shared across the configured domains. If a selector is already active, use the add-domain procedure below instead of replacing it.
3. Enter a selector name starting with a lowercase letter. The documented allowed characters are lowercase a-z, digits 0-9, periods and hyphens, with a maximum length of 63 characters.
4. Choose 2048 bits, the provider's recommended key length. If the DNS editor appears unable to accept it, first ask the DNS operator about correctly storing a long TXT value rather than truncating the key or reflexively downgrading it.
5. When the generated record appears, clear Include Test Mode tag (t=y;) before copying. Capture the complete record name and public TXT value.
6. Publish the generated TXT at the selector owner for each target domain, including subdomains. Preserve existing upstream selectors. Never publish private-key material or copy the shortened public key shown in a help-page example.

These steps follow HENNGE's current tenant DKIM setup. Its English page is automatically translated; the Japanese original takes precedence if wording differs.

A TXT record may contain multiple DNS character strings, each no longer than 255 octets. They must form one record whose strings concatenate to the complete generated value. Do not insert unintended spaces into p=, remove characters to fit the editor, or publish two independent key records at the same selector. An empty p= revokes the key. DKIM key publication

Activate only after DNS is correct

Query the public TXT owner and compare the full assembled value with the generated record. Then return to Email DLP, select Activate, enter the intended domain names one per line, and select Activate again. For each domain, open Tenant Settings → DMARC Apply Status, select the domain and confirm its DKIM status is enabled. Other current help pages call the broader status screen DMARC Coverage Dashboard; match the relevant screen in your tenant, not a memorized label. Activation and status, coverage dashboard

If t=y; remains in public DNS, remove that tag only, retaining the complete key and other tags, and repeat the checks. The provider's generated display can still show a sample containing test mode; that does not mean the published record contains it. Older functionality-test pages describe disabling test mode after an initial test. The current setup page says to clear it before copying; in either case, final acceptance must use the non-test record and a new received message.

Add another domain without replacing the selector

Register the additional customer domain with HENNGE One first. In the Customer Portal, an added domain remains Pending Configuration until HENNGE finishes processing and its status becomes Configured. Allow approximately five business days after uploading the required domain-capture evidence; DNS publication and DKIM Apply do not perform this tenant registration. Domain-registration process

In Tenant Settings → DKIM, open Setup for the existing selector. Copy its public key record into the new domain's DNS, with the test-mode checkbox cleared. Confirm public resolution. Return to Setup for the selector in use, enter the additional domains one per line, preserve the domains already in use, and select Apply. Check the status and a received message for each added domain. Add a domain to existing DKIM

HENNGE also documents a customer-managed alternative: publish the key as TXT under one customer-controlled primary domain and point other customer domains' selector owners to it with CNAMEs. A CNAME pointing to an Email DLP-owned domain is not supported. This is different from provider-hosted DKIM delegation. It centralizes a dependency, so protect the primary key owner and plan rotation across every dependent domain. Direct TXT publication is simpler when that dependency is unnecessary. HENNGE multiple-domain key references

Map DNS names to the authoritative zone

Use the exact generated selector. The following owner map uses fictional hennge2026 and example.com; neither is an issued value:

Some editors require the FQDN instead of a relative name. Check the published owner for a doubled suffix. If _domainkey.example.com itself is delegated, its zone uses only hennge2026 for the root-domain selector. Follow actual NS delegations rather than placing an ineffective record in a parent zone.

For the optional customer-to-customer CNAME method, keep the alias DNS-only. Where available, set the record's Flatten control to off and inspect any zone-wide flatten-all setting that could still conceal the alias. Coordinate with the DNS owner before changing shared settings; other applications may depend on them. Preserve legitimate child-zone and _domainkey NS delegations and publish in the zone that actually controls the owner. A CNAME cannot coexist with a TXT key or other ordinary record at the same owner. Do not remove an existing integration or delegation to resolve a collision. DNS alias constraints, Cloudflare verification and proxy guidance, flattening settings

Keep the required literal authentication CNAME answer visible, not just DNS-only. On Cloudflare, apex CNAMEs are flattened by default and same-zone targets are flattened regardless of the setting; whole-zone flatten-all cannot be overridden per record. If mandatory behavior or shared configuration cannot preserve the required alias, stop and agree a supported arrangement with the DNS administrator instead of removing NS delegation or blindly disabling shared features. Cloudflare flattening limits.

Preserve DMARC policy and verify alignment

DMARC evaluates the visible From domain. It passes when either SPF passes with an aligned MAIL FROM domain, or DKIM passes with an aligned d= domain. Relaxed alignment compares organizational domains; strict aspf=s or adkim=s requires exact domain equality. A Reply-To address, successful DLP inspection or unrelated DKIM pass does not establish alignment. Current DMARC standard, RFC 9989

For example, From billing@example.com with a valid final DLP signature using d=example.com satisfies even strict DKIM alignment. From billing@mail.example.com with d=example.com can satisfy relaxed alignment, but not strict alignment. These are protocol examples, not measured HENNGE defaults.

Before editing DMARC, inspect the existing policy at the exact From domain and any applicable inherited policy discovered through DMARC's DNS tree walk. Preserve existing enforcement, alignment and reporting. A missing child record does not mean no policy applies: adding p=none there can weaken inherited protection. Do not publish a second DMARC record or replace an established policy with a tutorial example. Policy discovery

Only when no established applicable policy exists and a monitored first deployment is approved, a starting TXT policy at _dmarc.example.com can have this shape:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the illustrative reporting mailbox with an approved, monitored destination. At the root zone the relative owner is _dmarc, not @. HENNGE's starter guide also offers DMARC through its separate Domain Protection service; that is optional, not a prerequisite for this direct-DNS route. p=none requests no DMARC-specific enforcement and does not guarantee delivery. RFC 9989 removes the old pct tag; plan enforcement by reviewed domain scope rather than promising percentage sampling. HENNGE DMARC options, RFC 9989

An aggregate-report destination requires external-destination authorization when its organizational domain differs from the organizational domain where the DMARC policy was found, not merely because the two exact hostnames differ. For a policy domain example.com sending to reports.vendor.example, the report recipient normally authorizes it at example.com._report._dmarc.reports.vendor.example. Use the receiving service's exact instructions; do not create that owner in your own zone and assume it authorizes the vendor. Review report access and retention, and do not casually enable message-level failure reports. Aggregate reporting and external destinations

Compare the Organizational Domain of the aggregate-report URI host with the Organizational Domain of the domain where the DMARC policy was found, not automatically the visible From domain. If they differ, the report-generating receiver must check the destination’s DNS authorization. A destination in the same Organizational Domain as that policy domain is excepted, even when its hostname differs. This protocol check does not replace the domain owner’s separate approval to share report data with that recipient. RFC 9990 section 4.

Validate DNS and the delivered message

Read-only DNS checks

Replace every example with the actual domain, generated selector and authoritative server. Run the trace separately for each relevant owner to discover the responsible zone; do not assume one server hosts every domain.

dig +trace hennge2026._domainkey.example.com TXT
dig @ns1.example.net hennge2026._domainkey.example.com TXT +noall +answer
dig hennge2026._domainkey.example.com TXT +noall +answer
dig @ns1.example.net example.com TXT +noall +answer
dig example.com TXT +noall +answer
dig @ns1.example.net _dmarc.example.com TXT +noall +answer
dig _dmarc.example.com TXT +noall +answer

For an alias-based configuration, also query CNAME and then TXT at the issued customer-controlled target. Acceptance requires the exact expected owner and key, no t=y, one valid SPF policy at the actual envelope owner, and the intended applicable DMARC policy. Compare authoritative and recursive answers after cache expiry. Blank short output does not distinguish a missing record from SERVFAIL, a timeout or a delegation problem; repeat without display filters and inspect the DNS status.

Confirm the actual DLP route

Use authorized test mail with synthetic content and controlled internal/external recipients. For Microsoft 365, inspect Exchange admin center → Mail flow → Message trace. HENNGE's standard test expects the external message to use the HENNGE Email DLP connector and the internal message not to use it. For Google Workspace, inspect Reporting → Email Log Search → Recipient Details → Matched Rules for the corresponding routing evidence. Investigate deviations against your approved topology rather than disabling controls to make a test pass. Microsoft 365 operation test, Google Workspace functionality test

In Email DLP, open History → History, locate the external test message and inspect the applied filter, rule and action. Repeat with plain mail, attachments, every enabled ZIP/Secure Download transformation, added domains and any external-MTA route. An internal message that bypasses DLP cannot prove DLP signing works.

Apply a stronger commissioning check than a green dashboard

Preserve the raw message as received and record:

• Test time, sender route, DLP history entry and transformation applied.
• Visible From, Return-Path, receiver-evaluated smtp.mailfrom, connecting IP and SPF result.
• Every DKIM signature's d= and s=, with the receiver's corresponding result.
• The receiver's DMARC result and the policy/alignment mode used.

Use the receiving mailbox's own authenticated diagnostics, or have its administrator establish which Authentication-Results field the receiver generated and how externally supplied fields are removed or separated. A familiar authserv-id or a header's location alone is not proof of provenance. Do not upload real business messages to a third-party analyzer without authorization. Authentication-Results trust boundary

Commission each intended route only when the HENNGE-applied branded DKIM signature passes and aligns, and the receiver reports dmarc=pass. Also require a passing SPF result on a normal direct DLP route with a customer-controlled envelope domain, or resolve any documented route-specific exception. DMARC can pass through SPF alone, but that would not prove the DKIM work succeeded. Conversely, a DKIM-based DMARC pass does not excuse an actual SPF fail, softfail, permerror or temperror: investigate and resolve the cause, or document a justified route-specific exception, before sign-off. A passing but unaligned SPF identity is different from a failing SPF evaluation. An upstream DKIM failure after a documented DLP transformation must be distinguished from failure of the final DLP signature.

Troubleshoot and recover safely

The provider distinguishes unavailable dashboard retrieval from a noncompliant configuration. Use that distinction alongside real-message evidence. Coverage-status interpretation, SPF result definitions

If acceptance fails, pause expansion, preserve logs and compare the last known-good DNS, selector/domain list and route. Repair the narrow failing layer. An approved rollback must preserve the organization's DLP obligations and an aligned authentication path; do not bypass DLP, disable the sole working signer or lower domain-wide DMARC as an improvised delivery fix. Retain old public keys while messages signed with them may still be queued and follow a supported rotation plan, especially with one active selector covering several domains. Authentication success does not guarantee inbox placement.