Email authentication (SPF, DKIM, & DMARC)

SPF

SPF stands for “Sender Policy Framework.” It is an email authentication protocol designed to prevent email spoofing and phishing by verifying that the sender of an email message is authorized to send messages on behalf of a particular domain or subdomain. SPF is the standard procedure for all senders using the Blueshift platform. Upon onboarding with Blueshift, DNS records in TXT or CNAME are provided for SPF implementation.

View the SPF specification (RFC 7208)

DKIM

DKIM, or DomainKeys Identified Mail, is an email authentication method that helps verify the authenticity of an email message. It involves using cryptographic signatures attached to outgoing emails, which the recipient’s email server can verify. DKIM enhances email security by confirming that the sender’s domain is legitimate and that the email content has not been altered in transit. DKIM is a standard procedure for all senders using the Blueshift platform. Upon onboarding with Blueshift, DNS records in TXT or CNAME are provided for DKIM implementation.

View the DKIM specification (RFC 6376)

DMARC

DMARC, or Domain-based Message Authentication, Reporting, and Conformance, is an email authentication and reporting protocol. It helps prevent phishing and spoofing by allowing domain owners to specify how email messages from their domain should be handled if they fail SPF or DKIM authentication checks. To determine how an email is handled, the DMARC record must include a policy.

DMARC policy

There are three DMARC policy types:

• None (p=none): This is a basic monitoring or observation mode where the domain owner is not requesting any specific action for emails that fail authentication. The purpose is to collect data through DMARC reports without impacting the delivery of emails. This mode is often used initially to assess the impact on legitimate email traffic.
• Quarantine (p=quarantine): In this mode, the domain owner requests that receiving mail servers treat emails that fail authentication with caution. A quarantined email will be accepted and reported as delivered. However, a quarantine policy will request that this mail be sent to the spam or quarantine folder of the inbox. This policy allows domain owners to gradually assess the impact on legitimate emails before moving to the strictest policy.
• Reject (p=reject): This is the strictest DMARC policy where the domain owner instructs receiving servers to reject emails that fail authentication outright. Unlike the quarantine policy, the mail server does not accept these emails and will not show as delivered. These emails will often show as having been bounced due to the sender’s DMARC policy. The “reject” policy protects against phishing and email spoofing.

What DMARC policy should my organization use?

If your sending domain is new or has recently migrated to a new sending platform, it is a good idea to begin with a p=none policy. The ultimate goal is to move toward a reject policy, but this process should be done incrementally. Starting in p=none observation mode allows the sender to ensure that configurations are correct and that no individuals using the sending domain are inadvertently quarantined or rejected.

Generally, a sender should remain in p=none throughout the entire IP warming period. Once regular sending is established and a positive foundational reputation has been attained for the domain and IP(s), the policy can move to quarantine with a pct tag to designate the percentage of emails the stricter policy should enforce. The following are sample progression schedules:

Quarantine policy progression
Week 1	p=quarantine; pct=10
Week 2	p=quarantine; pct=25
Week 3	p=quarantine; pct=50
Week 4	p=quarantine; pct=75
Week 5	p=quarantine; pct=100

* Removing the pct tag and using only p=quarantine is functionally the same as pct=100.

Reject policy progression
Week 1	p=reject; pct=10
Week 2	p=reject; pct=25
Week 3	p=reject; pct=50
Week 4	p=reject; pct=75
Week 5	p=reject; pct=100

* Removing the pct tag and using only p=reject is functionally the same as pct=100.

DMARC reports

To receive DMARC reports, additional tags must be included in the DMARC TXT DNS record. There are two types of DMARC reports: Aggregate (RUA) and Forensic (RUF) reports. While these reports can be sent to any email inbox, using a third-party platform to convert them into a more human-readable format is highly recommended.

Aggregate (RUA) reports

Aggregate reports provide a combined overview of email authentication activity across the domain. These reports are sent daily to the email address specified in the DMARC record. Each report is delivered in XML format and includes timestamps, domain and IP information, SPF/DKIM results, and the applied DMARC policy. No personally identifiable information (PII) is included in aggregate reports.

Sample tag: rua=mailto:example@blueshift.com

Forensic (RUF) reports

Forensic reports contain detailed information about individual email messages that fail DMARC authentication. These are sent in real time to the email address specified in the DMARC record. Forensic reports are delivered in plain text format and include similar data to aggregate reports and additional message identifiers that may contain PII. Because of this, some ISPs—such as Gmail—do not support this tag. If your organization handles sensitive data (e.g., in finance, healthcare, or education), be sure to review applicable privacy policies before enabling forensic reporting.

Sample tag: ruf=mailto:example@blueshift.com

View the DMARC specification (RFC 7489)

DMARC record examples

Basic DMARC
v=DMARC1; p=none;
This record meets the basic sender requirements for Gmail, Yahoo, and Microsoft, but does not enable additional security or reporting.
Basic DMARC with reporting enabled
v=DMARC1; p=none; rua=mailto:example@blueshift.com;
Same as the basic record, but includes a reporting address for aggregate reports.
Progressing to quarantine policy
v=DMARC1; p=quarantine; rua=mailto:example@blueshift.com; pct=10;
This record transitions from observation (p=none) to a quarantine policy by applying it to 10% of mail.

Common DMARC tags

Tag name	Purpose	Sample tag
v	Protocol version	v=DMARC1
pct	Percentage of messages subjected to filtering	pct=10
ruf	Reporting URI for forensic reports	ruf=mailto:example@blueshift.com
rua	Reporting URI for aggregate reports	rua=mailto:example@blueshift.com
p	Organizational domain policy	p=quarantine
sp	Subdomain policy for the organizational domain	sp=reject
adkim	Alignment mode for DKIM	adkim=s
aspf	Alignment mode for SPF	aspf=r