Manage suspicious emails with DMARC
Spammers can forge the “From” address on email messages to make messages appear to come from someone in your domain. If spammers use your domain to send spam or junk email, your domain quality is negatively affected. People who get the forged emails can mark them as spam or junk, which can impact authentic messages sent from your domain.
Gmail supports Domain-based Message Authentication, Reporting, and Conformance (DMARC) as a way to prevent this type of spam. Use DMARC to define the policy for how Gmail handles spam emails that appear to be sent from your domain.
What is DMARC?
DMARC, which stands for “Domain-based Message Authentication, Reporting & Conformance”, is an email authentication, policy, and reporting protocol. It builds on the widely deployed SPF and DKIM protocols, adding linkage to the author (“From:”) domain name, published policies for recipient handling of authentication failures, and reporting from receivers to senders, to improve and monitor protection of the domain from fraudulent email.
Handy Links
These are helpful links, we use regularly to check MX records, SPF, DKIM and a DMarc generator
- DMarc Generator
- DMarc Checker
- Check MX, SPF, DKIM Records (this one is Google specific)
- DMarcian * (this is an excellent facility, really handy tools)
* Adding DMarc is one thing, applying the correct policy and reviewing it is another. DMarcian is an excellent facility which allows you to verify the correct set-up and view reports on processed mail, forwarded mail and failures. Well worth a look!
How DMARC works
DMARC helps email senders and receivers verify messages. DMARC also defines the action to take on suspicious incoming messages. When an incoming message does not pass the DomainKeys Identified Mail (DKIM) check, DMARC defines what happens to these messages. There are three options:
- Take no action on the message.
- 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 up DMARC after SPF and DKIM
Before you set up DMARC, we recommend setting up Sender Policy Framework (SPF) and DKIM. DMARC uses SPF and DKIM to verify messages are authentic. A message that does not pass SPF or DKIM checks triggers the DMARC policy.
DMARC and third-party email providers
For DMARC to effectively manage suspicious messages, all messages should be sent from your own domain. Messages sent from third-party email providers for your organization can appear invalid and be rejected, depending on the DMARC policy.
To prevent messages from third-party email providers from being marked invalid:
- Share your DKIM key with the provider so the key is added to outgoing messages.
- Ask the provider to send messages through your network.
DMARC filtering examples
To see example messages and how DMARC filters spam messages, see the SPF and DKIM sections of the DMARC specification.
Tips for using DMARC
Here are some tips for using DMARC:
- You can set up DMARC to send you a daily report from all participating email providers. The report shows:
- How often messages are authenticated
- How often invalid messages are seen
- DMARC policy actions that occur
- You can update your DMARC policy based on what you learn from the daily reports. For example, you can change your policy from monitor (“none”) to “quarantine” to “reject” if you see that valid messages are being authenticated.
- Your policy can be strict or relaxed. For example, eBay and PayPal policies require all messages from their domains be authenticated to appear in someone’s inbox. To meet their policies, Google rejects all messages from eBay or PayPal that aren’t authenticated.
- Recipients don’t have to do anything, because Gmail conducts the DMARC check for you.
For more tips, see the DMARC Overview.
Start using DMARC
To start using DMARC, go to Add a DMARC record.
Related articles
See these related articles for more information about email security:
- Control unauthenticated mail from your domain
- Email authentication
- SPF records
- Authenticate email with a domain key
Add a DMARC record
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:
- Create a TXT record using correct tag names and values
- How to create a TXT record for popular domain hosts
- Some limitations of popular domain hosts
- All available tags in the DMARC Tag Registry
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:
|
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
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 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>