Notification

Duet AI is now Gemini for Google Workspace. Learn more

Add your DMARC record

Protect against spoofing & phishing, and help prevent messages from being marked as spam

You define Domain-based Message Authentication, Reporting, and Conformance (DMARC) functionality by entering a DMARC record in your domain’s DNS settings.

After preparing the text of your DMARC record, add or update the DNS TXT record at your domain provider. To update a DNS TXT record, enter the line of text that defines your DMARC policy record in the management console for your domain provider.

Every time you change your DMARC policy and update your record, you must update the DNS TXT record at your domain provider.

Subdomains & additional domains

If you have more than one domain, take the steps below for each domain. Each domain can have a different policy, and different report options (defined in the record).

If you don’t create DMARC policies for subdomains, they inherit the parent domain’s DMARC policy. To define a DMARC policy for subdomains, use the sp policy tag in the DMARC record for the parent domain.

Add or update your record

Important:

  • Configure DomainKeys Identified Mail (DKIM) and Sender Policy Framework (SPF) before configuring DMARC. DKIM and SPF should be authenticating messages for at least 48 hours before turning on DMARC.
  • The domains used in the steps below are examples only. Replace these example domains with your own domains.

Do these steps in the management console for your domain host, not in the Admin console. Who is my domain host?

  1. Have the text file or line that represents your policy record ready.
  2. Sign in to the management console for your domain host.
  3.  Locate the page where you update DNS records.
  4. Add a DNS TXT record, or modify an existing record, by entering your record in the TXT record for  _dmarc:
    1. TXT record name: In the first field, under the DNS Host name, enter: _dmarc.solarmora.com

      Important: Some domain hosts automatically add the domain name after _dmarc. After you add the TXT record, you can verify the DMARC TXT record name to make sure it's formatted correctly.

    2. TXT record value: In the second field, enter the text for your DMARC record, for example:

      v=DMARC1; p=none; rua=mailto:dmarc-reports@solarmora.com

      The field names might be different for your provider. DNS TXT record field names can vary slightly from provider to provider. The domain used here is an example domain. Replace solarmora.com with your own domain.

  5. Save your changes. 

Turning off DMARC

We don’t recommend turning off DMARC for your organization or domain. Without DMARC, hackers and other malicious users can impersonate messages, making them appear to come from your organization or domain. Turning off DMARC puts your users and your contacts at risk for spam, spoofing, and phishing. If you must turn off DMARC, follow these steps.

Verify the DMARC TXT record name (optional)

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, entered in step 4a of Add or update your record. This can cause the DMARC TXT record name to be incorrectly formatted.

For example, if you enter _dmarc.solarmora.com and your domain host automatically adds your domain name, the TXT record name will be incorrectly formatted as _dmarc.solarmora.com.solarmora.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.

You can use the Dig feature in the Google Admin Toolbox to see and verify your DMARC TXT record:

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

DMARC record format

Important: The example DMARC policy in this section uses example domains. Replace example domains with your own domains.

The DMARC record is in the form of a line of plain text. The text is a list of DMARC tags and values, separated by semicolons. Some tags are required and some are optional.

A DMARC policy tells receiving servers what action to take on unauthenticated messages they get from your domain. The action to take is specified with the policy (p) tag when you define your DMARC record.

This is an example of a DMARC policy record. Tags are separated by semicolons ( ; ). The v and p tags must be listed first, other tags can be in any order. If you use the the rua tag to email DMARC reports, you must use the mailto: prefix before each email address, as shown in this example:

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

DMARC record tags

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.
  • noneTake 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.

  • quarantineMark the messages as spam and send it to the recipient's spam folder. Recipients can review spam messages to identify legitimate messages.
  • rejectReject 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.
  • sStrict alignment. The sender domain name must exactly match the corresponding d=domainname in the DKIM mail headers.
  • rRelaxed 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.
  • sStrict alignment. The message From: header must exactly match the domain name in the SMTP MAIL FROM command
  • rRelaxed alignment (default). Allows partial matches. Any valid subdomain of domain name is accepted.

This tag is optional.

Was this helpful?

How can we improve it?
Search
Clear search
Close search
Main menu
3333062251788764031
true
Search Help Center
true
true
true
true
true
73010
false
false