Source review dated 8 November 2026. This is documentary guidance; account, DNS and received-message acceptance tests below have not been executed.
Separate domain authentication from mailbox migration
This guide is for a Hushmail account using an organization’s own domain. Begin by identifying the domain administrator, Hushmail administrator and person responsible for incoming mail. Record whether this is a new mailbox migration or an authentication repair for an existing service. Those are different changes. Replacing MX records can move incoming correspondence, whereas publishing a signing record establishes how recipients verify outgoing messages.
Hushmail’s custom-domain guide lists the SPF authorization include:_spf.hushmail.com and a DKIM CNAME at hush._domainkey pointing to _dkim.hushmail.com. It explicitly says to combine SPF authorizations into a single policy when one already exists. Its example containing Mailgun illustrates a second legitimate service; it does not mean every Hushmail customer should authorize Mailgun. Obtain the current instructions before publishing. Hushmail domain records
Publish records at the authoritative host
The registrar and DNS provider may be different organizations. Confirm the delegated nameservers and edit the zone they serve. Save the existing SPF, DKIM, DMARC and MX answers before making changes. For each proposed record, document the full owner, type, value and dependency. If the DNS interface appends the domain automatically, enter hush._domainkey as the relative label rather than duplicating the domain suffix.
Use a CNAME for the documented Hushmail selector, not a TXT record containing the target hostname. Inspect any existing data at that owner before replacement; a CNAME cannot coexist with ordinary TXT data at the same owner. Preserve other selectors because another application can legitimately sign under the same organization’s domain using a different selector.
Maintain one SPF policy at its owner and evaluate the total DNS lookup path. Adding Hushmail should not silently remove authorization for staff systems that remain in service. Conversely, an old provider should not remain authorized forever after its final use. Retire obsolete authorization through a separate verified change once mailbox migration and queued messages have been considered.
Review the domain policy independently
Hushmail’s DKIM and DMARC article supplies the same CNAME and a quarantine DMARC example. Treat that enforcement example as an input to the domain owner’s decision, not an instruction to overwrite an established policy. Inventory all legitimate senders before introducing enforcement. Hushmail DKIM and DMARC instructions
DMARC evaluates the visible From domain against a passing aligned SPF or DKIM identity. It does not require both methods to align. Domain authentication also does not establish message confidentiality or certify a workflow’s regulatory compliance. An encrypted-message feature and a valid signature solve different problems, so assess each against the organization’s requirements rather than presenting either as a complete security guarantee.
Verify the actual messages recipients receive
Original acceptance plan: use controlled accounts and synthetic content to send a normal outbound message, then exercise any secure-message notification flow used by the organization. Inspect each resulting email separately. Capture the visible From address, envelope domain, DKIM signing domain and selector, trusted authentication results and receipt time. Never use a real patient record, confidential attachment or client exchange simply to test delivery.
If this is also a mailbox migration, run an independent inbound test and a reply test. Outbound DKIM success does not prove that incoming mail reaches the correct inbox. Hushmail’s DNS checking tool is a useful configuration check, but received-message results show the signing and routing behavior actually exercised.
Illustrative failure: ordinary email verifies, but a workflow notification uses a different From domain. Identify that notification’s real sender and authentication path before editing the organization’s root policy. Do not infer that every mail generated around a secure workflow shares the same envelope or signing identity.
Recover and document ownership
If a DNS change fails, compare authoritative answers first, then allow for caching. Restore the last approved relevant record when necessary, without disturbing unrelated mailbox routing. Keep a record of who owns the Hushmail selector and when its dependency should be reviewed. Repeat controlled tests after a DNS migration or change in sending workflow.
Documentation was reviewed on 8 November 2026. No Hushmail account, customer DNS zone or received message was tested. The acceptance sequence and failure example are original illustrative guidance.