SPF, DKIM and DMARC for medical practices

A patient says your recall email went to spam. A newsletter that used to arrive now bounces with a code nobody in the office recognizes. Or a patient forwards a message that looks like it came from your billing address and asks for a card number, and your office never sent it. All three trace back to the same few lines in your domain’s DNS: the SPF, DKIM and DMARC records that tell receiving mail systems which servers may send as your practice and what to do with mail that fails the check.

This guide is the technical companion to related ones. What a marketing email must contain under CAN-SPAM and when HIPAA treats it as marketing is in our guide to email marketing for practices, choosing an email or fax vendor under HIPAA is in practice email and fax under HIPAA, and what patient data can go into a mailing platform is in CRM and marketing automation for practices. This one is about proving that mail from your domain is really yours.

This is general information, not legal or IT security advice. Sources cited were checked on October 31, 2026: Google’s Email sender guidelines and Email sender guidelines FAQ; Yahoo’s Sender Requirements and Recommendations and Sender FAQs; Microsoft’s announcement of Outlook requirements for high-volume senders (posted April 2, 2025, updated April 30, 2025); RFC 7208 (SPF); RFC 6376 (DKIM); RFC 9989, RFC 9990 and RFC 9991 (DMARC, published May 2026, which obsolete RFC 7489); RFC 8058 (one-click unsubscribe); 15 USC 7704(a)(1), (a)(3) and (a)(4); 16 CFR 316.5; 45 CFR 164.312(e); and the HHS Office for Civil Rights FAQ on email with patients. Mailbox provider requirements are company policies, not law, and they change; read the current pages before you rely on a date or threshold here. We found no federal rule or agency guidance that requires a medical practice to publish SPF, DKIM or DMARC records as such. State law differs, so have a health care attorney review how your practice emails patients.

The short version

SPF lists the servers allowed to send mail for your domain (RFC 7208). DKIM adds a signature that a receiver checks against a public key in your DNS (RFC 6376). DMARC tells receivers what you want done with mail that uses your domain in the From line but does not pass an aligned SPF or DKIM check, and where to send reports (RFC 9989).
Google requires each sender to personal Gmail accounts to have SPF or DKIM, valid forward and reverse DNS, a TLS connection and a spam rate below 0.3 percent. Senders of 5,000 or more messages a day need SPF and DKIM, a DMARC record (p=none is accepted), From domain alignment and one-click unsubscribe for marketing messages.
Yahoo has the same structure without a published volume threshold for bulk senders. Microsoft announced SPF, DKIM and DMARC requirements for domains sending over 5,000 messages a day to Outlook, with enforcement from May 5, 2025.
One-click unsubscribe (RFC 8058) is a mailbox provider requirement. CAN-SPAM’s own rule is separate: a working opt-out mechanism and no commercial email to that address more than 10 business days after the request (15 USC 7704(a)(3), (a)(4)).
None of these records encrypts a message. HIPAA’s transmission security standard at 45 CFR 164.312(e) is a separate question, answered by how the mail is carried and stored, not by DNS records.
DMARC failure reports can contain message content and addresses (RFC 9991). We recommend aggregate reports only for a practice domain.

What each record does

SPF. A Sender Policy Framework record is a TXT record at your domain that lists the hosts allowed to send mail using that domain in the envelope sender, the address a bounce returns to. It ends with a rule for hosts not on the list, for example “-all” for an explicit fail. RFC 7208 sets two limits that trip up practices that use more than one sending service. A domain may publish only one SPF record: if a receiver finds more than one, the check returns “permerror” (section 4.5). And the terms that require a DNS lookup, such as “include”, “a” and “mx”, are capped at 10 per evaluation; past that the result is also “permerror” (section 4.6.4). Each “include” a vendor asks you to add counts toward that cap.

DKIM. DomainKeys Identified Mail lets a domain claim responsibility for a message with a cryptographic signature carried in a header field. The receiver retrieves the public key from DNS under the signing domain and checks the signature (RFC 6376, section 1). Each sending service gets its own selector and key, so the office mailbox, the newsletter platform and the reminder system can each sign as your domain. Google requires a key of at least 1024 bits for mail to personal Gmail accounts and recommends 2048 bits where your provider supports it; Yahoo states the same 1024-bit minimum.

DMARC. A DMARC record is a TXT record at _dmarc under your domain. Its “p” tag states your preference for mail that fails: “none” offers no preference, “quarantine” marks such mail as suspicious, and “reject” says the use of your domain was not valid (RFC 9989, section 4.7). The “rua” tag asks receivers to send aggregate reports to an address you name; without it, receivers must not send them. To pass, a message needs SPF or DKIM to pass for a domain that aligns with the domain in the visible From line. Alignment is relaxed by default, meaning the organizational domain must match, and can be set to strict with the “adkim” and “aspf” tags.

The current DMARC specification is RFC 9989, published in May 2026 as an Internet Standards Track document. It obsoletes RFC 7489, which was an informational RFC, and moves reporting into RFC 9990 (aggregate) and RFC 9991 (failure). It also removes the old “pct” tag, which applied a policy to a percentage of messages, and adds a “t” tag for test mode (Appendix C.5). If a vendor’s setup guide still uses “pct”, read it against RFC 9989.

What Gmail, Yahoo and Outlook require

These are company policies for mail sent to their users. They are not statutes, but they decide whether your recall reminders and newsletters arrive.

Gmail. Google’s Email sender guidelines apply to mail sent to personal Gmail accounts, those ending in gmail.com or googlemail.com. All senders must set up SPF or DKIM, have valid forward and reverse DNS for their sending IPs, use TLS, keep the spam rate reported in Postmaster Tools below 0.3 percent, and format messages under RFC 5322. Senders of 5,000 or more messages a day must also have SPF and DKIM, a DMARC record whose policy can be none, a From domain aligned with the SPF or DKIM domain, and one-click unsubscribe plus a visible unsubscribe link in marketing and subscribed messages. Google’s FAQ says mail from the same primary domain counts together toward the 5,000, that a domain that crosses it once is a bulk sender permanently, that the guidelines do not apply to mail sent to Google Workspace accounts, and that from November 2025 Gmail is ramping up enforcement, including temporary and permanent rejections.

Yahoo. Yahoo’s Sender Requirements list SPF or DKIM, a spam rate below 0.3 percent, valid forward and reverse DNS and RFC 5321 and 5322 formatting for all senders. Bulk senders must also implement SPF and DKIM, publish a DMARC policy of at least p=none that passes, align the From domain, support one-click unsubscribe (Yahoo highly recommends the RFC 8058 POST method and accepts mailto), show a visible unsubscribe link and honor unsubscribes within 2 days. Yahoo’s FAQ says it will not specify a volume threshold for a bulk sender.

Outlook. Microsoft announced on April 2, 2025 that domains sending over 5,000 emails a day to Outlook must pass SPF and DKIM and publish DMARC of at least p=none aligned with SPF or DKIM. The announcement, updated April 30, 2025, says enforcement starts May 5, 2025, describes mail that fails going to Junk and rejection with the code 550 5.7.515, and recommends a valid From or Reply-To address and a working unsubscribe link.

A practice that sends a few hundred appointment reminders a day may sit under each threshold. The authentication records are still worth the hour. Google recommends SPF, DKIM and DMARC for each domain and warns that unauthenticated mail may be marked as spam or rejected with a 5.7.26 error. Yahoo urges each sender to publish DMARC and says a sender with a spoofing problem should implement an enforcement policy, quarantine or reject, regardless.

Setting it up for a practice domain

The work starts with an inventory. Before you touch DNS, list each system that sends mail using your domain in the From line. For a practice that list can include the office mailbox, the patient reminder or recall system, the website contact form, the newsletter platform, the online booking tool, billing statements and the phone system’s voicemail to email. RFC 9989 section 5.1 lists the steps for a domain owner in order: publish SPF and DKIM for aligned domains, set up a mailbox for aggregate reports, publish DMARC, then read the reports and fix what they show.

One SPF record. Merge each vendor’s instruction into a single TXT record. Count the lookup terms, including those nested inside each “include”, and keep the total at 10 or fewer.
DKIM per service. Ask each vendor to sign with your domain, not its own, using a selector you publish. Google’s guidelines tell senders who use an email service provider to confirm the provider authenticates your domain with SPF and DKIM.
A reports mailbox. Aggregate reports are XML files meant for machine parsing (RFC 9989, section 5.1.5). Decide who reads them and with what tool before you publish the address.
DMARC at p=none with rua. RFC 9989 calls this monitoring mode and explains the reason for starting there: a domain owner can overlook a server or a third-party sender, and the reports show it.
Move to enforcement when the reports are clean. The RFC says this can take months of reports, and warns in section 7.4 that p=reject can break indirect mail flows such as forwarding addresses and mailing lists. A practice whose staff forward the shared inbox to personal accounts should test that first.

If you are moving the website or changing domains at the same time, the mail records move with the domain; our guide to a practice website domain change covers the website side. The website contact form deserves its own check, because form mail is a sending stream that is easy to forget; see website contact forms under HIPAA for what the form itself should collect.

DMARC reports and patient information

DMARC defines two report types. Aggregate reports (RFC 9990) summarize authentication results by source. Failure reports (RFC 9991) describe individual messages that failed, and RFC 9991 section 7.1 says they may include personal and non-public information, since they may contain message content and trace header fields and can expose sender and recipient addresses. The same document says large providers limit or disable failure reports and that aggregate reports remain the recommended way to see authentication results.

For a practice, a failure report about a forwarded or misrouted message could carry a patient’s address or part of a message about their care. Failure reports go wherever the “ruf” tag in your record points, which can be a third-party reporting service. No federal rule we found addresses DMARC reports as such. We recommend publishing “rua” only, leaving out “ruf”, and treating the reporting service like any other vendor that may receive patient information: if it creates, receives, maintains or transmits protected health information for you, the business associate rules discussed in our email and fax guide apply.

One-click unsubscribe and CAN-SPAM

Two different rules govern unsubscribes, and meeting one does not meet the other.

The mailbox rule. RFC 8058 defines one-click unsubscribe with two header fields, List-Unsubscribe with an HTTPS address and List-Unsubscribe-Post with the value List-Unsubscribe=One-Click. The receiver’s mail system sends a POST to that address when the patient clicks unsubscribe in their mail app. The RFC requires a valid DKIM signature that covers both headers, says the POST must not carry cookies or other context, and says the address should contain a hard-to-forge identifier. Google requires one-click unsubscribe for marketing and subscribed messages from senders of 5,000 or more a day and says transactional messages, such as reservation and form submission confirmations, are excluded. Google’s FAQ recommends honoring requests within 48 hours; Yahoo requires 2 days.

The law. CAN-SPAM requires a commercial email to include a functioning return address or other internet-based mechanism, clearly and conspicuously displayed, that the recipient can use to opt out, and that keeps working for at least 30 days after the message is sent (15 USC 7704(a)(3)). After a request, the sender may not send commercial email within the scope of the request more than 10 business days later (15 USC 7704(a)(4)). Under 16 CFR 316.5, you may not make the recipient pay a fee, give information beyond their email address and opt-out preferences, or take steps beyond replying to an email or visiting a single web page. Separately, 15 USC 7704(a)(1) bars materially false or misleading header information in commercial and transactional or relationship messages.

The mailbox deadlines are shorter than the statute’s. We recommend building your opt-out process to the shorter one, so a single process meets both. Text message opt-outs follow different rules again; see our guide to text message appointment reminders.

What authentication does not do

SPF, DKIM and DMARC say who sent a message. They do not hide what it says. SPF checks a sending host against a list; DKIM signs headers and body so a receiver can tell whether the signed parts changed; DMARC ties those results to the From line and states a policy. None of the three encrypts message content.

HIPAA’s Security Rule treats transmission separately. 45 CFR 164.312(e)(1) requires technical measures to guard against unauthorized access to electronic protected health information transmitted over a network, with integrity controls and encryption as addressable implementation specifications in 164.312(e)(2). The HHS Office for Civil Rights FAQ on email says the Privacy Rule allows providers to email patients with reasonable safeguards, does not prohibit unencrypted email for treatment communications, and says other safeguards, such as limiting what the email contains, should apply. It also notes a patient’s right under 45 CFR 164.522(b) to ask for confidential communications by other means.

Google’s TLS requirement covers the connection between mail servers. It is a condition for delivery to Gmail, not a HIPAA determination. Whether your setup meets 164.312(e) depends on your risk analysis, how each system stores and carries messages, and your agreements with vendors that handle patient information.

Questions to ask your email platform or IT vendor

Which domains and IP addresses do you send from for our account, and what exactly should we add to our SPF record?
What is the count of DNS lookups your SPF include adds, counting nested includes?
Will you sign our mail with DKIM using our domain and a selector we publish, and what key length do you use?
Does the From domain align with the SPF or DKIM domain on mail you send for us?
Do our marketing messages carry List-Unsubscribe and List-Unsubscribe-Post headers covered by the DKIM signature?
How fast is an unsubscribe applied across each list we send from, including lists synced from other systems?
Where do DMARC reports go if we use your reporting tool, and do you request failure reports?
Will any patient information pass through your service, and if so, will you sign a business associate agreement that covers it?

Use and avoid

Use: one SPF record that lists each sending service, kept within 10 lookups.
Avoid: adding a second SPF record for a new vendor. Receivers return a permanent error when they find two.
Use: DKIM signing with your own domain on each service that sends as you.
Avoid: a newsletter or reminder tool that sends from your address but signs only with its own domain, which fails alignment.
Use: DMARC at p=none with an rua address, then quarantine or reject once the reports show only your own services.
Avoid: a ruf address pointed at a service you have not vetted for patient information.
Use: one-click unsubscribe headers and a visible unsubscribe link in each marketing email, honored within the shortest deadline that applies.
Avoid: describing DKIM, DMARC or TLS to patients as making email secure or private. They do not encrypt the message on its way or at rest.

An illustration

This example is invented. [Practice name] is a two-location practice. Its office manager hears from three patients in one week that the monthly newsletter landed in spam, and a fourth patient forwards a message, sent from what looks like the practice’s billing address, asking them to pay a balance through a link.

The manager lists each system that sends as the practice: the office mailbox, the reminder system in the practice management software, the newsletter platform, the website form and the phone system’s voicemail to email. The domain has two SPF records, one added years ago and one added for the newsletter platform, so receivers get a permanent error. The newsletter platform signs with its own domain, not the practice’s. There is no DMARC record.

Their IT contractor merges the SPF records into one, counts [number] lookups, and replaces one include with the vendor’s narrower option to stay within 10. Each vendor publishes a DKIM selector for the practice’s domain. The practice publishes DMARC at p=none with an rua address and no ruf, and the contractor reads the first [number] weeks of aggregate reports. They show one forgotten sender, an old online payment page, which the practice either authenticates or retires. Once the reports show only known services passing, the practice moves to p=quarantine and plans a later move to p=reject after testing the staff forwarding rules. The fake billing email is reported to the practice’s counsel and IT contractor as a possible security incident, separately from the DNS work.

Checklist

List each system that sends mail with your domain in the From line.
Publish one SPF record covering them, with 10 or fewer lookup terms.
Turn on DKIM with your domain for each sending service; 2048-bit keys where supported.
Set up a mailbox or tool to read DMARC aggregate reports.
Publish DMARC at p=none with rua and without ruf.
Read the reports, fix or retire each unknown or failing sender, then move to quarantine and later reject.
Test forwarding and shared inbox rules before p=reject.
Add one-click unsubscribe headers and a visible link to marketing email; honor requests within 2 days.
Check that the CAN-SPAM opt-out mechanism works for 30 days after each send and asks only for an email address and preferences.
Keep transmission security and vendor agreements under your HIPAA risk analysis, separate from authentication.
Recheck the Google, Yahoo and Microsoft sender pages when you change platforms or volume.

How we help

We build websites, local and organic search, Google Ads and lead generation and an AI front desk for independent practices. For email, that means website forms, booking confirmations and follow-ups that send from a properly authenticated domain, and a check with you of which systems send as your practice before we add another one. Our tools are built with HIPAA in mind. We confirm in writing what a BAA covers before any patient information flows through a tool, and if it is not covered, we do not route patient information through it. We are not a healthcare provider and we do not give legal or medical advice. For the wider rules, see our healthcare marketing rules guide.

Do we need DMARC if we send only a few hundred emails a day?

Google and Microsoft require DMARC only above 5,000 messages a day, and Yahoo does not publish its bulk threshold. Google recommends SPF, DKIM and DMARC for each domain, and Yahoo urges each sender to publish DMARC. No federal rule we found requires it. We recommend it, because it is the record that lets receivers act on mail that spoofs your domain.

Is p=none enough?

It meets the Gmail, Yahoo and Outlook minimums. It asks receivers to take no action on failing mail, so it does not stop spoofing on its own. RFC 9989 describes p=none as monitoring mode, the step before deciding whether to move to quarantine or reject.

Does DKIM or DMARC make our email HIPAA secure?

No. They authenticate the sender and detect changes to signed content. They do not encrypt messages. Transmission security under 45 CFR 164.312(e) and the safeguards in the HHS email FAQ are separate questions.

Do appointment reminders need one-click unsubscribe?

Google requires one-click unsubscribe for marketing and subscribed messages and excludes transactional ones such as confirmations. How a reminder is classified under CAN-SPAM depends on its primary purpose; our email marketing guide covers that. A reminder that also promotes a service may be treated as marketing.

How fast do we have to process an unsubscribe?

CAN-SPAM allows up to 10 business days (15 USC 7704(a)(4)). Yahoo requires bulk senders to honor unsubscribes within 2 days, and Google recommends 48 hours. We recommend meeting the shortest one.

Sources

More in Practice websites, privacy and tracking

Email authentication for medical practices: SPF, DKIM, DMARC and the mailbox sender rules