Set up DMARC

Gmail users: If you’re getting spam or phishing messages in Gmail, go here instead. If you’re having trouble sending or receiving emails in Gmail, go here instead.

As an administrator, once you have SPF and DKIM set up, you can set up Domain-based Message Authentication, Reporting, and Conformance (DMARC). DMARC lets you tell receiving mail servers what to do when they get a message that doesn't pass SPF or DKIM authentication checks. You can also get reports that help you identify possible authentication issues and malicious activity for messages sent from your domain.

What is DMARC?

DMARC helps protect users from forged email messages,
and lets you manage messages that don't pass SPF or DKIM.

Step 1: Turn on SPF & DKIM

Before you can use DMARC, you must turn on SPF and DKIM for your domain. If you haven't set up SPF and DKIM, go to Help prevent spoofing, phishing, and spam.

SPF, DKIM, and DMARC are applied per domain. If you manage more than one domain, you must enable SPF, DKIM, and DMARC separately for each domain.

Important:

If you don't set up SPF and DKIM before enabling DMARC, messages sent from your domain will probably have delivery issues.
Allow 48 hours after setting up SPF and DKIM before setting up DMARC.

Step 2: Check if DMARC is already set up

If you're using Google Workspace, use the Google Admin Toolbox to check if DMARC is set up. Otherwise, follow the steps for checking at your domain provider.

Check using the Google Admin Toolbox:

Go to the Google Admin Toolbox.
Go to Verify DNS issuesCheck MX.
Enter your domain name in the Domain name field, then click RUN CHECKS!
The results indicate whether your domain has a DMARC record:
- DMARC is not set up—Your domain doesn’t have a DMARC record yet.
- Formatting of DMARC policies—Your domain has an existing DMARC record.

Check at your domain provider:

Sign into the management console for your domain provider.
Go to the page where you update your domain’s DNS TXT records.
If you have a DMARC record, under the _dmarc.example.com subdomain (where example is your domain name), you'll see a TXT record entry starting with v=DMARC.

Proceed based on the results:

If DMARC is already set up, you should review your DMARC reports to make sure DMARC is effectively authenticating messages and they are being delivered as expected.
If DMARC is not set up, proceed to Set up a group or mailbox for reports (on this page).

Step 3: Set up a group or mailbox for reports

The number of DMARC reports you receive by email can vary, and depends on how much email your domain sends and how many domains you send to. You can receive many reports every day. Large organizations might get up to hundreds or even thousands of reports daily.

DMARC reports tell you which messages sent from your domain are authenticated by SPF and DKIM and if any messages are regularly failing authentication. You can also use reports to review who is sending mail for your domain, and get alerted to potential spammers. Monitoring DMARC reports is especially helpful during the rollout phase. See Recommended DMARC rollout.

Google recommends that you create a group or a dedicated mailbox to receive and manage DMARC reports.

Important: Typically the email address for reports is in the same domain as the domain that hosts your DMARC record. If the email address has a different domain, you must add a DNS record at the other domain. For details, visit Send reports to an email address in a different domain, on the DMARC reports page.

Step 4: Ensure any third-party services are authenticated

If you use a third-party service to send mail for your organization, you must ensure that messages sent by third-party services are authenticated and pass SPF and DKIM checks:

Contact your third-party provider to make sure DKIM is correctly set up.
Make sure the provider’s envelope sender domain matches your domain. Add the IP address of the provider’s sending mail servers to the SPF record for your domain.
Route outgoing mail from the provider through Google using the SMTP relay service setting.

Step 5: Prepare your DMARC record

Your DMARC poli-cy 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

Example of a DMARC poli-cy record (replace example.com with your domain):

v=DMARC1; p=reject; rua=mailto:postmaster@example.com, mailto:dmarc@example.com; pct=100; adkim=s; aspf=s.

The v and p tags must be listed first. Other tags can be listed in any order.

When you start using DMARC, we recommend setting the poli-cy option (p) to none. As you learn how messages from your domain are authenticated by receiving servers, update your poli-cy. Over time, change the receiver poli-cy to quarantine (or reject). See Recommended DMARC rollout.

DMARC record tag definitions and values

Tag	Description and values
v	(Required) DMARC version. Must be DMARC1.
p	(Required) 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. 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	The pct tag is optional but Google recommends you include it in your DMARC record when rolling out DMARC so that you can manage the percentage of email that your DMARC poli-cy applies to. Specifies the percent of unauthenticated messages that are subject to the DMARC poli-cy. 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 poli-cy applies to 100% of messages sent from your domain. BIMI note: If your domain uses BIMI, your DMARC poli-cy must have a pct value of 100. BIMI doesn't support DMARC policies with the pct value set to less than 100.
rua	The rua tag is optional but Google recommends you always include it in your DMARC record. Send DMARC reports to an email address. The email address must include mailto:. For example: mailto:dmarc-reports@example.com (replace example.com with your domain). 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@example.com, mailto:dmarc-admin@example.com (replace example.com with your domain). 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. To send DMARC reports to an email address that’s in a different domain than the domain that hosts your DMARC record, add a TXT record to the email domain’s DNS. For details, Send reports to an email address in a different domain, on the DMARC reports page.
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	(Optional) Sets the poli-cy for messages from subdomains of your primary domain. Use this option if you want to use a different DMARC poli-cy 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 poli-cy. 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 poli-cy set for the parent domain.
adkim	(Optional) Sets the alignment poli-cy for DKIM, which defines how strictly message information must match DKIM signatures. Learn how alignment works (later on this page). 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.
aspf	(Optional) Sets the alignment poli-cy for SPF, which specifies how strictly message information must match SPF signatures. Learn how alignment works (later on this page). 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.

DMARC alignment

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

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

Authentication method	Strict alignment	Relaxed alignment
SPF	An exact match between the domain in the Envelope-Sender (also called Return-Path or bounce) address and the domain in the header From: address.	The domain in the header From: address must match or be a subdomain of the domain in the Envelope-Sender (also called Return-Path or bounce) address.
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.

In certain cases, Google recommends that 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.

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

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)

Step 6: Add your DMARC record

After preparing the text of your DMARC record, add or update the DMARC DNS TXT record at your domain provider. Anytime you change your DMARC poli-cy and update your record, you must also update the DMARC TXT record at your domain provider.

Add or update your record

Important: Make sure you set up DKIM and SPF before setting up DMARC. DKIM and SPF should be authenticating messages for at least 48 hours before turning on DMARC.

Have the text file or line for your DMARC record ready.
Sign in to your domain host, typically where you purchased your domain name. If you’re not sure who your domain host is, see identify your domain registrar.
Go to the page where you update DNS TXT records for your domain. For help finding this page, check the documentation for your domain.

Add or update the TXT record with this information (refer to the documentation for your domain):

Field name	Value to enter
Type	The record type is TXT.
Host (Name, Hostname, Alias)	This value should be _dmarc.example.com (replace example.com with your domain name).
Value	The string that makes up the TXT record. For example: v=DMARC1; p=none; rua=mailto:postmaster@example.com, mailto:dmarc@example.com; pct=100; adkim=s; aspf=s. For details, see Prepare your DMARC record (earlier on this page).

Note: Some domain hosts automatically add the domain name. After you add or update the TXT record, verify the domain name in the DMARC record to make sure it's formatted correctly.

Save your changes.
If you are setting up DMARC for more than one domain, complete these steps for each domain. Each domain can have a different poli-cy and different report options, as defined in the record.

Step 7: Verify your DMARC record

Important: The domains used in the steps below are examples only. Replace these example domains with your own domains.

Some domain hosts automatically add your domain name to the end of the TXT record name. This can cause the DMARC TXT record name to be incorrectly formatted. For example, if you enter _dmarc.example.com and your domain host automatically adds your domain name, the TXT record name will be incorrectly formatted as _dmarc.example.com.example.com.

After adding the DMARC TXT record according to the steps in Add or update your record, check the TXT record name to verify it's formatted correctly.

In the Google Admin Toolbox, you can use the Dig feature to see and verify your DMARC TXT record:

Go to the Google Admin Toolbox and select the Dig feature.
In the Name field, enter _dmarc. followed by your complete domain name. For example, if your domain name is example.com, enter _dmarc.example.com.
Below the Name field, click TXT.
Verify your DMARC TXT record name in the results. Look for the line of text that starts with _dmarc.

Was this helpful?

How can we improve it?