Enhance security for forged spam (DMARC)

Turn on DMARC

Manage suspicious emails with DMARC

Turn on Domain-based Message Authentication, Reporting, and Conformance (DMARC) by adding a DMARC policy to your domain's DNS records. The policy is in the form of a DNS TXT record, and defines how your domain handles suspicious emails.

A DMARC policy supports three ways to handle suspicious emails:

  • Take no action on the message and log it in a daily report.
  • Mark the message as spam. Gmail puts these messages in the recipient's spam folder.
  • Tell the receiving server to reject the message. This also causes an SMTP bounce to the sender.

Example DMARC policies

These are some example policies. 

Important: The domain used in these examples is an example domain. Replace solarmora.com with your own domain.

The values in these examples are defined in DMARC TXT record values.

Actions to take for failed DMARC check TXT record contents
Take no action on messages that fail the DMARC check. Email a daily report to dmarc@solarmora.com. v=DMARC1; p=none; rua=mailto:dmarc@solarmora.com

Put 5% of the messages that fail the DMARC check in recipients' spam folders. Email a daily report to dmarc@solarmora.com.

v=DMARC1; p=quarantine; pct=5; rua=mailto:dmarc@solarmora.com

Reject 100% of messages that fail the DMARC check. Email a daily report to two addresses: postmaster@solarmora.com and dmarc@solarmora.com. 

Failed messages cause an SMTP bounce to the sender.

v=DMARC1; p=reject; rua=mailto:postmaster@solarmora.com, mailto:dmarc@solarmora.com

Add a TXT record to turn on DMARC

To turn on DMARC, update your domain settings with a DNS TXT record.

About TXT records

A TXT record is a DNS record that contains text information used by sources outside of your domain. Add TXT records to your domain settings at your domain host, not in your Google Admin console.

Learn more about working with TXT records in Tips for updating DNS TXT records.

Add a DMARC TXT record

Follow these steps to add a DMARC TXT record for your domain.

Important:

  • The domain used in these examples is an example domain. Replace solarmora.com with your own domain. 
  • Replace the example values with values for your domain's DMARC policy.
  1. Sign in to the management console for your domain provider.
  2. Locate the page where you update DNS records.

    Subdomains: If your domain host doesn't support updating subdomain DNS records, add the record to the parent domain. Learn how to update DNS records for a subdomain.

  3. Add a DNS record at _dmarc

    TXT record name: In the first field, under DNS Host name, enter:
    _dmarc.solarmora.com

    TXT record value: In the second field, enter the values that define your DMARC policy, for example:
    v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@solarmora.com; pct=90; sp=none

  4. Save your changes.

DMARC TXT record values

Note: Gmail does not support the DMARC ruf tag, used to send failure (forensic) reports.

Tag Name Required Description and values

v

Required Protocol version. Must be DMARC1.

p

Required

Defines how your domain handles suspicious messages:

  • none: Take no action on the message. Log suspicious messages in the daily report.
  • quarantine: Mark the messages as spam and move to recipient's Gmail spam folder. Recipients can use Gmail to review their spam messages.
  • reject: Tell receiving servers to reject the message. When this happens, the receiving server should send a bounce to the sending server.

pct

Optional

Sets the percent of suspicious messages that the DMARC policy applies to. Suspicious messages are messages that fail the DMARC check.

Must be a whole number between 1 and 100. The default is 100

rua

Optional

Email address to receive reports about DMARC activity for your domain. Use your own email address or create a new email address to receive reports.

The email address must include mailto:, for example: mailto:dmarc-reports@solarmora.com

To send the report to more than one email address, separate emails with a comma.

sp

Optional

Sets the policy for messages from subdomains of your main domain. Use this option if you want to use a different DMARC policy for your subdomains.

  • none: Take no action on the message. Log suspicious messages in the daily report.
  • quarantine: Mark the messages as spam and hold it for more processing.
  • reject: Instruct receiving servers to reject the message.
adkim Optional

Sets the Alignment mode for DKIM, which defines how exactly message information must match DKIM signatures.

  • s: Strict. The sender domain name must exactly match the corresponding d=name in the DKIM mail headers.
  • r: Relaxed (default). Allows partial matches. Any valid subdomain of d=domain in the DKIM mail headers is accepted.

aspf

Optional

Sets the Alignment mode for SPF (ASPF), which defines how exactly message information must match SPF signatures.

  • s: Strict. The message from: header must exactly match the domain.name in the SMTP MAIL FROM command
  • r: Relaxed (default). Allows partial matches. Any valid subdomain of domain.name is accepted.

Deploy DMARC slowly

Use the policy (p) and percent (pct) options together to gradually and slowly deploy DMARC in Gmail.

Use the policy (p) option. Set and change the policy option using the p tag value in the TXT record. Start with a quarantine policy so you can inspect suspicious messages. Then gradually modify the policy based on what you learn from quarantined messages and daily reports.

  1. p=none: Monitor email traffic and look for issues in the daily reports, but let all message through. Watch for spoofed messages and messages not signed with DKIM or SPF.
  2. p=quarantine: When you're familiar with email patterns you see in the daily reports, change the policy to quarantine. Continue to review the daily reports and view the messages that are being set aside (quarantined) as spam.
  3. p=reject: When you're sure all messages from your domain are signed, change the policy reject to start filtering spam messages. Continue to review daily reports to check that you're filtering out spam and sending valid email to recipients.

Use the percent (pct) option. The percent option specifies what percentage of suspicious messages have the DMARC policy applied. Suspicious messages are messages that fail the DMARC check. The default is 100% (all suspicious messages). Set the percent option to fewer messages at first, increasing the percentage every few days as you refine your DMARC policy. For example, set the percent option to 20 to filter 20% of rejected or quarantined messages to start with. The following week, change the value from 20 to 50 to filter 50% of the messages.

Example deployment: Here is an example of how to use the p and pct options to gradually deploy a DMARC policy. Update your DMARC policy over time with these values:

  1. p=none pct=100
  2. p=quarantine pct=1
  3. p=quarantine pct=5
  4. p=quarantine pct=10
  5. p=quarantine pct=25
  6. p=quarantine pct=50
  7. p=quarantine pct=100
  8. p=reject pct=1
  9. p=reject pct=5
  10. p=reject pct=10
  11. p=reject pct=25
  12. p=reject pct=50
  13. p=reject pct=100

Daily DMARC reports

DMARC daily reports are in XML format and have information about email flow. Use the reports to:

  • Verify outbound email sources are authenticated
  • Verify the email servers sending messages from your domain are legitimate
  • Respond if a new server is online, or an existing server has configuration issues
Example DMARC report

Below is part of a report that shows results for messages sent from a two IP addresses. One message was sent directly and the other message was forwarded. Both messages passed DMARC checks.


<record>
<row>
<source_ip>207.126.144.129</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
</policy_evaluated>
</row>
<identities>
<header_from>stefanomail.com</header_from>
</identities>
<auth_results>
<dkim>
<domain>stefanomail.com</domain>
<result>pass</result>
<human_result></human_result>
</dkim>
<spf>
<domain>stefanomail.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
<record>
<row>
<source_ip>207.126.144.131</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
<reason>
<type>forwarded</type>
<comment></comment>
</reason>
</policy_evaluated>
</row>
<identities>
<header_from>stefanomail.com</header_from>
</identities>
<auth_results>
<dkim>
<domain>stefanomail.com</domain>
<result>pass</result>
<human_result></human_result>
</dkim>
<spf>
<domain>stefanomail.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>

Was this helpful?
How can we improve it?