Enhance security for forged spam (DMARC)

Add a DMARC record

Define how your domain handles suspicious emails

Set up Domain-based Message Authentication, Reporting, and Conformance (DMARC) by adding policies to your domain's DNS records. Policies define how your domain handles suspicious emails. Policies are defined in the form of a TXT record.

There are three possible DMARC policies for how your domain responds to suspicious emails:

  • Take no action on the message and log it in the daily report.
  • Mark the message as spam and hold it for more processing (quarantine).
  • Cancel the message so that it is not sent to the recipient.

Set the DMARC policy with the p tag in the TXT record, as described in the Common tags used in DMARC records table below.

Set up SPF and DKIM first

We recommend setting up Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) before you set up DMARC. DMARC uses SPF and DKIM to verify messages are authentic. A message that does not pass SPF or DKIM checks triggers the DMARC policy.

Create a DMARC record

Create a TXT record with tag names and values that define the policies you want used in your domain.

The TXT record name must be in this format, where your_domain.com is the name of your domain:
 _dmarc.your_domain.com 

Tips for creating a DMARC TXT record

These articles have detailed information for creating a DMARC record:

Common tags used in DMARC TXT records

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

Tag Name Required Description and values Example

v

required Protocol version. This value must be DMARC1. v=DMARC1

p

required

Sets 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 hold it for more processing.
  • reject: Cancel the message so that it is not sent to the recipient.
p=quarantine

pct

optional

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

pct=20

rua

optional

Reporting Uniform Resource Identifier (URI) for aggregate reports. To get reports about DMARC activity for your domain, use this option with your own email address.

rua=mailto:aggrep@example.com

sp

optional

Sets the policy for messages from subdomains of your main domain. Use this option if you want a different DMARC policy for your subdomains. The possible values are the same as for the p tag.

 

sp=reject

aspf

optional

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

r: Relaxed allows partial matches, for example subdomains within a domain.

s: Strict requires an exact match.

aspf=r

 

Deploy DMARC slowly

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

How to gradually deploy your DMARC policy

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=quarantine pct=5
  2. p=quarantine pct=10
  3. p=quarantine pct=25
  4. p=quarantine pct=50
  5. p=quarantine pct=100
  6. p=reject pct=1
  7. p=reject pct=5
  8. p=reject pct=10
  9. p=reject pct=25
  10. p=reject pct=50
  11. p=reject pct=100
  12. p=none pct=100
  13. p=quarantine pct=1

Example TXT records

Here are some example DMARC TXT records you can modify for your own use. Copy these records and replace "your_domain.com" and "postmaster@your_domain.com" with your own domain and email address.

Use the daily report to change the policy and percentage values if needed.

Example TXT record: "No action taken"

Take no action on messages that appear to be from your domain.com but don't pass DMARC checks. Send the daily report to "postmaster@your_domain.com."

"v=DMARC1; p=none; rua=mailto:postmaster@your_domain.com"

Example TXT record: "Quarantine message"

Quarantine 5% of the messages that appear to be from your domain.com but don't pass DMARC checks. Send the daily report to "postmaster@your_domain.com."

"v=DMARC1; p=quarantine; pct=5; rua=mailto:postmaster@your_domain.com"

Example TXT record: "Reject message"

Reject 100% of messages that appear to be from your domain but don't pass DMARC checks. Send the daily report to "postmaster@your_domain.com" and "dmarc@your_domain.com."

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

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 article helpful?
How can we improve it?