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
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:email@example.com, mailto:firstname.lastname@example.org; pct=100; adkim=s; aspf=s
To see definitions and allowed values for these tags, go to DMARC record tags.
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 rejecting 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 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)
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|
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|
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.