DMarc and How to Set it Up

Enhance security for forged spam (DMARC)

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

* 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:

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:

  1. Take no action on the message and log it in the daily report.
  2. Mark the message as spam and hold it for more processing (quarantine).
  3. 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.

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.

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"

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"

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

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>

Share this post:

Facebook
Twitter
Pinterest
LinkedIn
On Key

Related Posts

Progressive Web App deep dive to understand what they are and how they can benefit your business

Progressive Web Apps

Progressive Web Apps (PWAs) are web applications that offer a native app-like experience to users, combining the best of both worlds – the reach and