| 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:dmarc-reports@solarmora.com
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:dmarc-reports@solarmora.com, mailto:dmarc-admin@solarmora.com
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 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.
| | |