DMARC Email Authentication

Email spoofing is still one of the fastest paths into a healthcare environment because it targets people, not systems. HICP Practice 1.2 is direct: publish and operate SPF, DKIM, and DMARC so receiving mail systems can verify whether a message claiming to be from your domain is authorized. The practical challenge for a CCO or GRC lead is that DMARC is partly technical (DNS, mail headers, cryptographic signing) and partly operational (inventorying senders, coordinating with third parties, controlling changes, and proving ongoing monitoring).

This page translates the requirement into an operator-ready implementation plan: what domains and systems are in scope, how to roll out DMARC without breaking legitimate email, what evidence auditors ask for, and where teams commonly get stuck (especially with third-party senders and “lookalike” domains). You can hand this to your email administrator and still track it as a compliance control with clear acceptance criteria and durable artifacts.

Regulatory text

HICP Practice 1.2 requirement: “Implement Domain-based Message Authentication, Reporting, and Conformance (DMARC) along with SPF and DKIM to prevent email spoofing.” ¹

What the operator must do:

• SPF: Publish DNS records that declare which mail servers/services are permitted to send on behalf of each domain.
• DKIM: Configure authorized sending services to cryptographically sign outbound mail; publish DKIM public keys in DNS.
• DMARC: Publish a DMARC policy in DNS that tells receivers how to handle mail that fails authentication, and enable reporting so you can find unauthorized senders and misconfigurations. ¹

Plain-English interpretation

You need to make it hard for an attacker to send email that looks like it came from your organization. DMARC does not “block phishing” by itself; it gives recipient mail systems a reliable way to reject or quarantine messages that are not genuinely from your approved infrastructure. Operationally, success means:

• Every legitimate sender is authenticated (SPF and/or DKIM) and aligns with your “From:” domain.
• Spoofed mail using your domain fails DMARC and gets rejected or quarantined by recipients according to your policy.
• You continuously monitor DMARC reports and keep sender configurations current as the business adds tools and third parties. ¹

Who it applies to (entity and operational context)

Entity types in scope: Healthcare organizations and health IT vendors. ¹

Operational contexts that are typically in scope:

• Corporate email domains used by staff (for example, yourhealth.org).
• Subdomains that send email (for example, billing.yourhealth.org, notifications.yourhealth.org).
• Domains used for marketing or patient communications.
• Domains used by third parties to send on your behalf (EHR portals, payment processors, appointment reminders, surveys, fundraising platforms, managed service providers).
• Newly acquired brands/domains and legacy domains that still forward or send mail.

Clear scope rule you can adopt: If a domain appears in a visible “From:” header in email sent to patients, workforce members, payers, regulators, or business partners, it must have SPF, DKIM, and DMARC correctly configured and monitored.

What you actually need to do (step-by-step)

1) Build the sending-domain and sender inventory

Create one list that answers two questions:

• Which domains do we send from? Include primary domains, subdomains, and brand domains.
• What systems send mail claiming to be those domains? Include your core mail platform and every application or third party that sends email (marketing, ticketing, HR, ERP, clinical apps, patient comms, contractors).

Practical tip: Inventory by reviewing outbound mail logs, application lists, and DNS (existing SPF/DKIM selectors). Most DMARC failures come from “unknown” senders that were never documented.

2) Implement/repair SPF for each sending domain

Actions your technical team should take:

• Publish or correct an SPF TXT record for each domain used in “From:”.
• Ensure the SPF record includes all authorized senders (mail platform and third parties).
• Prevent common SPF breakages: multiple SPF records, overly broad “allow” statements, and DNS lookup chain issues.

Control acceptance criteria (GRC-friendly):

• Each sending domain has exactly one SPF record.
• SPF authorizes only known senders tied to a business purpose.

3) Implement/repair DKIM signing for each sending source

Actions:

• Enable DKIM signing in your primary mail platform.
• For each third-party sender, enable DKIM and publish the required selector/key in DNS.
• Confirm the DKIM d= domain aligns with the visible “From:” domain where possible, because DMARC evaluates alignment, not just “pass/fail.”

What “done” looks like:

• Messages from each sender show DKIM=pass in headers and align to the organizational domain used in “From:”.

4) Publish DMARC in monitoring mode first (with reporting)

Start with a DMARC TXT record at _dmarc.<domain> that:

• Sets policy to monitoring (commonly p=none).
• Enables aggregate reporting (rua=) to a mailbox or a DMARC reporting service.
• Sets alignment modes consistent with your mail architecture.

Why: Monitoring exposes unknown senders and misalignment without interrupting legitimate mail flow. ¹

5) Triage DMARC reports and fix alignment

Work through report findings methodically:

• Authorized sender, failing SPF: add/include correct SPF mechanisms or fix sender configuration.
• Authorized sender, failing DKIM: enable DKIM in that system, publish keys, fix selector rotation issues.
• Passes SPF/DKIM but fails alignment: adjust sending configuration so the authenticated domain aligns with the “From:” domain, or change the “From:” domain strategy (for example, use a subdomain dedicated to the third party).
• Unauthorized sources: confirm they are not yours; then move toward enforcement to cause rejection/quarantine.

Operational habit: Tie each fix to a ticket with owner, change record, and evidence (screenshots + headers).

6) Move DMARC to enforcement

Once legitimate sources are consistently passing and aligned, advance policy:

• Set p=quarantine to reduce spoofing impact while watching for residual false positives.
• Progress to p=reject to stop spoofed mail from being accepted by receivers that honor DMARC. ¹

CCO/GRC control language: Enforcement is achieved when the organizational domain publishes a DMARC policy that directs receivers to quarantine or reject messages that fail DMARC, and the organization reviews DMARC reporting on an ongoing basis.

7) Operationalize ongoing control (change management + third parties)

DMARC fails quietly when the business adds new senders. Put these guardrails in place:

• Email sender onboarding: Any new system or third party that will send email must go through a lightweight security review that confirms SPF/DKIM/DMARC alignment.
• DNS change control: SPF/DKIM/DMARC record changes require peer review and documented testing.
• Periodic review: Review DMARC reports and sender inventory on a set cadence aligned to your risk management program.
• Third-party contracts/SOWs: Require third parties to support DKIM signing and provide documentation for your DNS records when they send as your domain.

Where Daydream fits naturally: Many teams use Daydream to track third-party onboarding steps, store the evidence packet (headers, DNS records, approvals), and keep an auditable trail of “who approved this sender and why” across IT and compliance.

Required evidence and artifacts to retain

Retain artifacts that prove both deployment and operation:

Technical configuration evidence

• SPF, DKIM, and DMARC DNS record exports (or screenshots from DNS management) for each sending domain.
• Mail headers from test messages demonstrating SPF/DKIM pass and DMARC pass for each sending source.
• DKIM selector/key management documentation (who rotates keys, how, and when).

Operational evidence

• Sender inventory (domains, senders, business owner, technical owner, third party involved, purpose).
• DMARC report access proof (mailbox or service configuration) and examples of reports reviewed.
• Tickets/changes showing remediation of failures (alignment fixes, SPF updates, DKIM enablement).
• Written procedure for onboarding new senders and approving DNS changes.
• Third-party communications showing DKIM/SPF requirements and the configuration they supplied.

Common exam/audit questions and hangups

Expect questions framed like these:

• “Which domains are covered, and how do you know you didn’t miss any?”
• “Show me the DMARC record for your primary domain and explain the policy.”
• “Do third parties send email as your domain? Show how you control that.”
• “How do you detect unauthorized sending or misconfiguration over time?”
• “Prove enforcement: demonstrate that spoofed mail would be rejected or quarantined.” ¹

Common hangup: teams can show a DMARC record but cannot show that it is effective because they do not review reports or cannot account for all senders.

Frequent implementation mistakes (and how to avoid them)

1. Publishing DMARC before fixing SPF/DKIM for third-party senders
   Avoidance: run monitoring, inventory senders, then remediate and enforce.

2. Only covering the primary domain and ignoring subdomains/brand domains
   Avoidance: include all domains that appear in “From:” and adopt a standard for subdomain policies.

3. Misalignment between authenticated domain and visible “From:”
   Avoidance: require aligned “From:” domains for third-party senders, often by using dedicated subdomains.

4. SPF sprawl that becomes unmaintainable
   Avoidance: assign an owner for SPF hygiene, remove obsolete include mechanisms, and tie changes to a documented sender inventory.

5. No operational trigger for new senders
   Avoidance: make “email sending as our domain” a mandatory checkbox in procurement/intake workflows for applications and third parties.

Enforcement context and risk implications

HICP Practice 1.2 is a framework requirement, not a case law program in the material provided here. Your risk is still concrete: without enforced DMARC, attackers can spoof your domain to target workforce members and patients, which can lead to credential theft, fraudulent payment instructions, and unauthorized access pathways. DMARC also reduces brand harm by making your domain harder to impersonate, and it improves your ability to investigate email abuse using DMARC reporting. ¹

Practical 30/60/90-day execution plan

First 30 days (Immediate stabilization)

• Identify all domains that send email and assign a technical owner per domain.
• Inventory all sending sources, including third parties.
• Fix SPF to a single correct record per domain.
• Enable DKIM signing for your core mail platform and high-volume senders.
• Publish DMARC in monitoring mode with aggregate reporting enabled. ¹

Days 31–60 (Remediation and alignment)

• Review DMARC reports and reconcile every legitimate sender.
• For each third-party sender, implement DKIM and alignment (or move them to an approved subdomain approach).
• Document the standard: how new senders request approval, required tests, and required evidence.

Days 61–90 (Enforcement and operationalization)

• Advance DMARC policy to quarantine, then reject when false positives are resolved.
• Implement change management controls for DNS and sender onboarding.
• Produce an “audit packet” per domain: DNS records, test headers, sender inventory, and report review evidence. ¹

Frequently Asked Questions

Do we need DMARC on every domain we own, or only the one we email from?

Apply SPF/DKIM/DMARC to every domain that appears in the visible “From:” address. If a domain is parked and never used, you can still publish DMARC to reduce spoofing risk, but prioritize active sending domains first.

Can we meet the requirement with DMARC set to p=none?

Monitoring mode shows progress, but it does not instruct receivers to block spoofed mail. To “prevent email spoofing” as stated in HICP Practice 1.2, plan to move to quarantine or reject after you validate legitimate senders. ¹

What if a third party says they can’t support DKIM?

Treat that as a security exception with documented risk acceptance, compensating controls, and a roadmap to remediation. In practice, you often solve this by changing the “From:” domain to a subdomain they can authenticate and align correctly.

Who should own DMARC: IT, Security, or Compliance?

IT usually owns mail infrastructure and DNS changes; Security owns phishing risk reduction and monitoring; Compliance tracks the control, evidence, and exceptions. Assign one accountable owner and make cross-functional responsibilities explicit.

How do we prove DMARC is working to an auditor?

Show the DNS records (SPF/DKIM/DMARC), test email headers demonstrating pass/alignment, and evidence that you review DMARC reports and resolve failures through tickets and controlled changes.

What evidence should we request from third parties that send email as us?

Require their sending IPs/mechanisms for SPF, their DKIM selector/public key instructions, proof they can sign with aligned domains, and a contact path for troubleshooting. Keep their documentation attached to your change record.

Footnotes

1. HICP 2023 - 405(d) Health Industry Cybersecurity Practices