Improve email deliverability with these authentication protocols
Setting up SPF, DKIM, and DMARC is critical for any new practice that relies on email for patient communication, marketing, or administrative purposes. These email authentication protocols help verify that your practice’s emails are legitimate and not sent by malicious actors, protecting both your domain’s reputation and your patients’ trust.
Without these safeguards, emails from your practice are more likely to end up in spam folders or be blocked entirely, which can disrupt communication with patients and impact your ability to grow. Implementing SPF, DKIM, and DMARC early ensures that your emails reach their intended recipients, fostering better engagement and helping your practice establish credibility from the start.
This article focuses on understanding the purpose and setup of each protocol. Each email provider has a slightly different recommendation for how to set up these email authentication protocols, so search for something like “set up {email provider} {email authentication protocol}” for each item we go over below for detailed, provider-specific setup instructions.
If you’re new to the world of domain and email setup, we recommend checking out the following brief overview of the domain name system (DNS) as well as DNS records before jumping in.
Sender Policy Framework (SPF)
SPF allows domain owners to specify which mail servers are authorized to send emails on behalf of their domain. It helps prevent email spoofing by verifying the sender's IP address against the authorized list in the SPF record.
How it works
Domain owners publish an SPF record in their DNS.
Receiving mail servers check the sender's IP address against the SPF record.
If the IP address is listed, the email passes the SPF check; otherwise, it fails.
Example
TXT DNS record with host value “@” and data value “v=spf1 include:_spf.google.com -all”
v=spf1
v: This specifies the version of SPF being used. Currently, SPF1 is the only version in use.
spf1: Indicates that the record adheres to the SPF version 1 specification.
include:_spf.google.com
include: This tells the receiving mail server to include and check the SPF record of another domain.
_spf.google.com: This is the domain whose SPF record should be included. Google publishes SPF records under this subdomain for its email services. When the receiving server encounters this include mechanism, it will fetch and evaluate the SPF record for _spf.google.com and apply those rules as if they were part of the original domain's SPF record.
-all
-all: The "all" mechanism matches any IP address. The “-” qualifier before it determines what to do if none of the previous mechanisms match. In this case, -all means that any IP address not specifically included in the SPF record should be considered unauthorized and the email should be rejected. Below are the qualifiers that can be in SPF records:
+ (Pass): The default if no qualifier is specified. The IP is authorized to send mail for the domain.
- (Fail): The IP is explicitly not authorized to send mail for the domain.
~ (SoftFail): The IP is not authorized but the receiver should accept the mail but mark it as suspicious.
? (Neutral): No policy; explicitly in effect as "I don't know"
DomainKeys Identified Mail (DKIM)
DKIM verifies that an email's content has not been altered during the sending process and that the email is actually being sent from the domain origin it says it’s being sent from. It does this by allowing domain owners to sign their emails with a cryptographic signature.
How it works
Domain owners generate a pair of cryptographic keys (public and private).
The private key is used to sign outgoing emails by adding a DKIM signature header.
The public key is published in the DNS.
Receiving mail servers use the public key to verify the DKIM signature and confirm the email's integrity and authenticity.
Example
TXT record with host value “@” and data value “v=DKIM1; k=rsa; p={public key}”
v=DKIM1
v: This specifies the version of DKIM being used.
DKIM1: Indicates that the record adheres to the DKIM version 1 specification.
k=rsa
k: This specifies the key type used for the DKIM signature.
rsa: Indicates that the key type is RSA, which is the most commonly used encryption algorithm for DKIM.
p={public key}
p: This specifies the public key that will be used to verify the DKIM signature.
{public key}: This is the actual public key, encoded in Base64. It is a long string of characters that represents the public half of the RSA key pair.
Domain-based Message Authentication, Reporting, and Conformance (DMARC)
DMARC builds on SPF and DKIM by adding a layer of policy and reporting. It prevents email spoofing by ensuring that both SPF and DKIM align with the domain in the email's "From" header. It also allows domain owners to specify how to handle emails that fail SPF or DKIM checks (e.g., none, quarantine, or reject). Finally, it provides a feedback mechanism through reports, helping domain owners monitor email authentication and detect unauthorized usage of their domain.
How it works
Domain owners publish a DMARC record in their DNS.
Receiving mail servers check the DMARC policy and apply the specified action if an email fails SPF and DKIM checks.
Aggregate and forensic reports are sent to the domain owner for analysis.
Example
TXT record with host value “_dmarc” and data value “v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-reports@yourdomain.com; adkim=s; aspf=s”
v=DMARC1
v: This specifies the version of DMARC being used.
DMARC1: Indicates that the record adheres to the DMARC version 1 specification.
p=quarantine
p: This specifies the policy for handling emails that fail DMARC checks. There are three policy options here:
none: This option instructs email receivers to take no specific action when a DMARC check fails. Instead, it just provides feedback reports to the domain owner, allowing them to monitor email traffic and policy violations without blocking or rejecting emails. This is an appropriate setting to start a new domain on before moving up to the other two options.
quarantine: Instructs email receivers to deliver messages that fail DMARC checks to the recipient's spam or junk folder, marking them as suspicious rather than fully blocking them. This allows the emails to be reviewed but not placed in the inbox.
reject: This is the most stringent policy. It instructs email receivers to reject all messages that fail the DMARC check outright. The email is completely blocked and not delivered to the recipient.
rua: This specifies the address to which aggregate reports should be sent.
mailto@yourdomain.com: The email address where aggregate DMARC reports will be sent. These reports provide summary information about the emails that passed and failed DMARC checks.
ruf: This specifies the address to which forensic (detailed) reports should be sent.
mailto@yourdomain.com: The email address where forensic DMARC reports will be sent. These reports contain detailed information about individual emails that failed DMARC checks.
adkim=s
adkim=s: This specifies the alignment mode for DKIM. There are two alignment options:
s: Strict alignment. The s setting means that the domain in the DKIM signature must exactly match the domain in the "From" address.
r: Relaxed alignment. This allows the "From" domain to be a subdomain of the domain in the DKIM signature, providing more flexibility in the alignment check.
aspf=s
aspf=s: This specifies the alignment mode for SPF. There are two alignment options:
s: Strict alignment. This requires the domain in the "Return-Path" (envelope sender) to exactly match the domain in the "From" header of the email.
r: Relaxed alignment. This allows the domain in the "Return-Path" to be a subdomain of the domain in the "From" header, providing more flexibility in SPF alignment.
Closing thoughts
The technical setup of a practice can feel daunting, but it is less challenging as long as