Define your DMARC record

Your Domain-based Message Authentication, Reporting, and Conformance (DMARC) policy is defined in a line of text values, called a DMARC record. The record defines:

• How strictly DMARC should check messages
• Recommended actions for the receiving server, when it gets messages that fail authentication checks

DMARC policy options

Your DMARC policy recommends to the receiving mail server the action to take when a message from your domain doesn’t pass DMARC authentication.

This is an example of a DMARC policy record. The v and p tags must be listed first, other tags can be in any order:

v=DMARC1; p=reject; rua=mailto:[e-mail], mailto:[e-mail]; pct=100; adkim=s; aspf=s

DMARC record tag definitions and values

Tag	Description and values
v	DMARC version. Must be DMARC1. This tag is required.
p	Instructs the receiving mail server what to do with messages that don’t pass authentication. none—Take no action on the message and deliver it to the intended recipient. Log messages in a daily report. The report is sent to the email address specified with the rua option in the record. quarantine—Mark the messages as spam and send it to the recipient's spam folder. Recipients can review spam messages to identify legitimate messages. reject—Reject the message. With this option, the receiving server usually sends a bounce message  to the sending server. This tag is required. BIMI note: If your domain uses BIMI, the DMARC p option must be set to quarantine or reject. BIMI doesn't support DMARC policies with the p option set to none.
pct	Specifies the percent of unauthenticated messages that are subject to the DMARC policy. When you gradually deploy DMARC, you might start with a small percentage of your messages. As more messages from your domain pass authentication with receiving servers, update your record with a higher percentage, until you reach 100 percent. Must be a whole number from 1 to 100. If you don’t use this option in the record, your DMARC policy applies to 100% of messages sent from your domain. This tag is optional. BIMI note: If your domain uses BIMI, your DMARC policy must have a pct value of 100. BIMI doesn't support DMARC policies with the pct value set to less than 100.
rua	Email address to receive reports about DMARC activity for your domain. The email address must include mailto: For example: mailto:[e-mail] To send DMARC reports to multiple emails, separate each email address with a comma and add the mailto: prefix before each address. For example: mailto:[e-mail], mailto:[e-mail] This option can potentially result in a high volume of report emails. We don’t recommend using your own email address. Instead, consider using a dedicated mailbox, a group, or a third-party service that specializes in DMARC reports. This tag is optional.
ruf	Not supported. Gmail doesn’t support the ruf tag, which is used to send failure reports. Failure reports are also called forensic reports.
sp	Sets the policy for messages from subdomains of your primary domain. Use this option if you want to use a different DMARC policy for your subdomains. none—Take no action on the message and deliver it to the intended recipient. Log messages in a daily report. The report is sent to the email address specified with the rua option in the policy. quarantine—Mark the messages as spam and send it to the recipient's spam folder. Recipients can review spam messages to identify legitimate messages. reject—Reject the message. With this option, the receiving server should send a bounce message  to the sending server If you don’t use this option in the record, subdomains inherit the DMARC policy set for the parent domain. This tag is optional.
adkim	Sets the alignment policy for DKIM, which defines how strictly message information must match DKIM signatures. Learn how alignment works. s—Strict alignment. The sender domain name must exactly match the corresponding d=domainname in the DKIM mail headers. r—Relaxed alignment (default). Allows partial matches. Any valid subdomain of d=domain in the DKIM mail headers is accepted. This tag is optional.
aspf	Sets the alignment policy for SPF, which specifies how strictly message information must match SPF signatures. Learn how alignment works. s—Strict alignment. The message From: header must exactly match the domain name in the SMTP MAIL FROM command r—Relaxed alignment (default). Allows partial matches. Any valid subdomain of domain name is accepted. This tag is optional.

When you start using DMARC, we recommend a policy with enforcement set to none. As you learn how messages from your domain are authenticated by receiving servers, update your policy. Over time, change the receiver policy to quarantine, and finally to reject. To see an example DMARC policy that is updated during a DMARC rollout, go to Tutorial: Recommended DMARC rollout.

Enforcement policy	Action recommended	More information
none	No action is taken on messages that don’t pass the DMARC checks by the receiving server. Messages are delivered normally to the recipient.	We recommend using this option when you first set up DMARC. With the none option, messages from your domain are delivered normally. While your policy is set to none, review DMARC reports regularly to learn how your mail is being authenticated and delivered. DMARC reports sent to you by receiving servers have details about messages that SPF and DKIM can’t authenticate. If you find a significant number of messages from your domain are sent to spam, check your SPF and DKIM configuration. Read more about Troubleshooting DMARC. Don’t change your policy enforcement option to quarantine or reject until you understand which messages aren’t authenticated by receiving servers. BIMI note: If your domain uses BIMI, your DMARC enforcement policy (p) must be set to quarantine or reject. BIMI doesn't support DMARC policies with the p option set to none.
quarantine	Messages that aren’t authenticated with DMARC by the receiving server are sent to the recipient’s spam folder. If the receiving mail server has a quarantine configured, messages might be sent to quarantine, not directly to the recipient’s spam folder.	You continue to get DMARC reports with this option.
reject	Messages that aren’t authenticated with DMARC by the receiving server are rejected, and never delivered to the recipient. The receiving server usually sends a bounce message to the sender.	We recommend reject as the eventual, permanent option for all DMARC policies. You continue to get DMARC reports with this option. Update your policy to this option when DMARC reports show that valid messages are authenticated and delivered normally. Rejecting unauthenticated messages helps protect recipients from spam, spoofing, and phishing.

DMARC alignment options

DMARC passes or fails a message based on how closely the message From: header matches the sending domain specified by either SPF or DKIM. This is called alignment.

You can choose from two alignment modes: strict and relaxed. Set the alignment mode for SPF and DKIM in the DMARC record. The aspf and adkim DMARC record tags set the alignment mode.

In the following cases, we recommend you consider changing to strict alignment for increased protection against spoofing:

• Mail is sent for your domain from a subdomain outside your control
• You have subdomains that are managed by another entity

To pass DMARC, a message must pass at least one of these checks:

• SPF authentication and SPF alignment
• DKIM authentication and DKIM alignment

A message fails the DMARC check if the message fails both:

• SPF (or SPF alignment)
• DKIM (or DKIM alignment)

Important: Relaxed alignment typically provides sufficient spoofing protection. Strict alignment can result in messages from associated subdomains to be rejected or sent to spam.

Authentication method	Strict alignment	Relaxed alignment
SPF	An exact match between the SPF authenticated domain, and the domain in the header From: address.	The domain in the header From: address must match or be a subdomain of the SPF authenticated domain.
DKIM	An exact match between the relevant DKIM domain, and the domain in the header From: address.	The domain in the header From: address must match or be a subdomain of the domain specified in the DKIM signature d= tag.

Understand envelope sender and From: addresses

Email messages have two types of addresses that indicate the sender. It’s important to understand the difference between these addresses when setting up SPF, DKIM, and DMARC.

The envelope sender address and the From: address for a message can be different or the same.

Envelope sender address—The email address that indicates where the message came from. Undeliverable message notices, or bounces, are sent to this address. The Envelope-Sender address is also referred to as the Return-Path address or the bounce address. Message recipients don’t see the envelope sender address.

SPF typically uses the message envelope sender address for authentication.

From: address—The email address in the message header. Messages have two parts: the message header and the message body. The header has information about the message, including: sender name and email address, message subject, and the sending date. The From: header includes the email address, and usually the name of the person who sent the message.

DKIM uses the message From: address for authentication.

SPF alignment example

With SPF, alignment compares the domain authenticated by SPF (usually the envelope sender address) to the domain in the message header From: address. Here are some alignment examples with their SPF check results.

Envelope sender address	Header From: address	Strict alignment	Relaxed alignment
[e-mail]	[e-mail]	Pass	Pass
[e-mail]	[e-mail]	Fail	Pass
[e-mail]	[e-mail]	Fail	Fail

DKIM alignment example

With DKIM, alignment compares the value in the DKIM-signature domain field (d=) in the message header to the domain in the message From: header.

Here are some alignment examples with their DKIM check results:

From: header	DKIM d=domain	Strict alignment	Relaxed alignment
[e-mail]	solarmora.com	Pass	Pass
[e-mail]	solarmora.com	Fail	Pass
[e-mail]	solarmora.com	Fail	Fail

DMARC report options

You can set up DMARC to request regular reports from email servers that get email from your domain.

DMARC reports tell you:

• What servers or third-party senders are sending mail for your domain
• What percent of messages from your domain pass DMARC
• Which servers or services are sending messages that fail DMARC
• What DMARC actions the receiving server takes on unauthenticated messages from your domain: none, quarantine, or reject.

To start getting DMARC reports, use the rua DMARC record tag in your DMARC record.

Learn more about DMARC reports.